On Thu, 2007-11-01 at 14:02 -0700, H. Peter Anvin wrote:
Doug Ledford wrote:
I would argue that ext[234] should be clearing those 512 bytes. Why
aren't they cleared
Actually, I didn't think msdos used the first 512 bytes for the same
reason ext3 doesn't: space for a boot sector.
Neil Brown wrote:
On Friday October 26, [EMAIL PROTECTED] wrote:
Perhaps you could have called them 1.start, 1.end, and 1.4k in the
beginning? Isn't hindsight wonderful?
Those names seem good to me. I wonder if it is safe to generate them
in -Eb output
If you agree that
On Tue, 2007-10-30 at 07:55 +0100, Luca Berra wrote:
Well it might be a matter of personal preference, but i would prefer
an initrd doing just the minumum necessary to mount the root filesystem
(and/or activating resume from a swap device), and leaving all the rest
to initscripts, then an
On Sun, Oct 28, 2007 at 01:47:55PM -0400, Doug Ledford wrote:
On Sun, 2007-10-28 at 15:13 +0100, Luca Berra wrote:
On Sat, Oct 27, 2007 at 08:26:00PM -0400, Doug Ledford wrote:
It was only because I wasn't using mdadm in the initrd and specifying
uuids that it found the right devices to start
On Mon, 2007-10-29 at 09:41 +0100, Luca Berra wrote:
Remaking the initrd installs the new mdadm.conf file, which would have
then contained the whole disk devices and it's UUID. There in would
have been the problem.
yes, i read the patch, i don't like that code, as i don't like most of
what
On Mon, Oct 29, 2007 at 11:30:53AM -0400, Doug Ledford wrote:
On Mon, 2007-10-29 at 09:41 +0100, Luca Berra wrote:
Remaking the initrd installs the new mdadm.conf file, which would have
then contained the whole disk devices and it's UUID. There in would
have been the problem.
yes, i read the
On Mon, 2007-10-29 at 22:44 +0100, Luca Berra wrote:
On Mon, Oct 29, 2007 at 11:30:53AM -0400, Doug Ledford wrote:
On Mon, 2007-10-29 at 09:41 +0100, Luca Berra wrote:
Remaking the initrd installs the new mdadm.conf file, which would have
then contained the whole disk devices and it's
On Friday October 26, [EMAIL PROTECTED] wrote:
Perhaps you could have called them 1.start, 1.end, and 1.4k in the
beginning? Isn't hindsight wonderful?
Those names seem good to me. I wonder if it is safe to generate them
in -Eb output
Maybe the key confusion here is between version
On Mon, Oct 29, 2007 at 07:05:42PM -0400, Doug Ledford wrote:
And I agree -D has less chance of finding a stale superblock, but it's
also true that it has no chance of finding non-stale superblocks on
Well it might be a matter of personal preference, but i would prefer
an initrd doing just the
On Sat, Oct 27, 2007 at 04:09:03PM -0400, Doug Ledford wrote:
On Sat, 2007-10-27 at 10:00 +0200, Luca Berra wrote:
On Fri, Oct 26, 2007 at 02:52:59PM -0400, Doug Ledford wrote:
On Fri, 2007-10-26 at 11:54 +0200, Luca Berra wrote:
On Sat, Oct 20, 2007 at 09:11:57AM -0400, Doug Ledford wrote:
On Sat, Oct 27, 2007 at 08:26:00PM -0400, Doug Ledford wrote:
On Sat, 2007-10-27 at 00:30 +0200, Gabor Gombas wrote:
On Fri, Oct 26, 2007 at 02:52:59PM -0400, Doug Ledford wrote:
In fact, no you can't. I know, because I've created a device that had
both but wasn't a raid device. And it's
On Sun, 2007-10-28 at 15:13 +0100, Luca Berra wrote:
On Sat, Oct 27, 2007 at 08:26:00PM -0400, Doug Ledford wrote:
On Sat, 2007-10-27 at 00:30 +0200, Gabor Gombas wrote:
On Fri, Oct 26, 2007 at 02:52:59PM -0400, Doug Ledford wrote:
In fact, no you can't. I know, because I've created a
Doug Ledford wrote:
On Fri, 2007-10-26 at 14:41 -0400, Doug Ledford wrote:
Actually, after doing some research, here's what I've found:
I should note that both the lvm code and raid code are simplistic at the
moment. For example, the raid5 mapping only supports the default raid5
On Fri, Oct 26, 2007 at 02:52:59PM -0400, Doug Ledford wrote:
On Fri, 2007-10-26 at 11:54 +0200, Luca Berra wrote:
On Sat, Oct 20, 2007 at 09:11:57AM -0400, Doug Ledford wrote:
just apply some rules, so if you find a partition table _AND_ an md
superblock at the end, read both and you can tell
On Fri, Oct 26, 2007 at 07:06:46PM +0200, Gabor Gombas wrote:
On Fri, Oct 26, 2007 at 06:22:27PM +0200, Gabor Gombas wrote:
You got the ordering wrong. You should get userspace support ready and
accepted _first_, and then you can start the
flamew^H^H^H^H^H^Hdiscussion to make the in-kernel
On Sat, Oct 27, 2007 at 12:20:12AM +0200, Gabor Gombas wrote:
On Fri, Oct 26, 2007 at 02:41:56PM -0400, Doug Ledford wrote:
* When using lilo to boot from a raid device, it automatically installs
itself to the mbr, not to the partition. This can not be changed. Only
0.90 and 1.0 superblock
Doug Ledford wrote:
On Fri, 2007-10-26 at 10:18 -0400, Bill Davidsen wrote:
[___snip___]
Actually, after doing some research, here's what I've found:
* When using lilo to boot from a raid device, it automatically installs
itself to the mbr, not to the partition. This can not be
On Sat, 2007-10-27 at 10:00 +0200, Luca Berra wrote:
On Fri, Oct 26, 2007 at 02:52:59PM -0400, Doug Ledford wrote:
On Fri, 2007-10-26 at 11:54 +0200, Luca Berra wrote:
On Sat, Oct 20, 2007 at 09:11:57AM -0400, Doug Ledford wrote:
just apply some rules, so if you find a partition table _AND_
On Fri, 2007-10-26 at 14:41 -0400, Doug Ledford wrote:
Actually, after doing some research, here's what I've found:
* When using grub2, there is supposedly already support for raid/lvm
devices. However, I do not know if this includes version 1.0, 1.1, or
1.2 superblocks. I intend to find
On Sat, 2007-10-27 at 11:20 -0400, Bill Davidsen wrote:
* When using lilo to boot from a raid device, it automatically installs
itself to the mbr, not to the partition. This can not be changed. Only
0.90 and 1.0 superblock types are supported because lilo doesn't
understand the offset to
On Sat, 2007-10-27 at 00:30 +0200, Gabor Gombas wrote:
On Fri, Oct 26, 2007 at 02:52:59PM -0400, Doug Ledford wrote:
In fact, no you can't. I know, because I've created a device that had
both but wasn't a raid device. And it's matching partner still existed
too. What you are talking
On Thursday October 25, [EMAIL PROTECTED] wrote:
I didn't get a reply to my suggestion of separating the data and location...
No. Sorry.
ie not talking about superblock versions 0.9, 1.0, 1.1, 1.2 etc but a data
format (0.9 vs 1.0) and a location (end,start,offset4k)?
This would
On Sat, Oct 20, 2007 at 09:11:57AM -0400, Doug Ledford wrote:
On Sat, 2007-10-20 at 09:53 +0200, Iustin Pop wrote:
Honestly, I don't see how a properly configured system would start
looking at the physical device by mistake. I suppose it's possible, but
I didn't have this issue.
Mount by
Neil Brown wrote:
On Thursday October 25, [EMAIL PROTECTED] wrote:
I didn't get a reply to my suggestion of separating the data and location...
No. Sorry.
ie not talking about superblock versions 0.9, 1.0, 1.1, 1.2 etc but a data
format (0.9 vs 1.0) and a location
On Fri, Oct 26, 2007 at 11:54:18AM +0200, Luca Berra wrote:
but the fix is easy.
remove the partition detection code from the kernel and start working on
a smart userspace replacement for device detection. we already have
vol_id from udev and blkid from ext3 which support detection of many
On Fri, Oct 26, 2007 at 06:22:27PM +0200, Gabor Gombas wrote:
You got the ordering wrong. You should get userspace support ready and
accepted _first_, and then you can start the
flamew^H^H^H^H^H^Hdiscussion to make the in-kernel partitioning code
configurable.
Oh wait that is possible even
On Fri, 2007-10-26 at 10:18 -0400, Bill Davidsen wrote:
Neil Brown wrote:
On Thursday October 25, [EMAIL PROTECTED] wrote:
I didn't get a reply to my suggestion of separating the data and
location...
No. Sorry.
ie not talking about superblock versions 0.9, 1.0,
On Fri, 2007-10-26 at 11:54 +0200, Luca Berra wrote:
On Sat, Oct 20, 2007 at 09:11:57AM -0400, Doug Ledford wrote:
just apply some rules, so if you find a partition table _AND_ an md
superblock at the end, read both and you can tell if it is an md on a
partition or a partitioned md raid1
On Fri, Oct 26, 2007 at 02:41:56PM -0400, Doug Ledford wrote:
* When using lilo to boot from a raid device, it automatically installs
itself to the mbr, not to the partition. This can not be changed. Only
0.90 and 1.0 superblock types are supported because lilo doesn't
understand the offset
On Fri, Oct 26, 2007 at 02:52:59PM -0400, Doug Ledford wrote:
In fact, no you can't. I know, because I've created a device that had
both but wasn't a raid device. And it's matching partner still existed
too. What you are talking about would have misrecognized this
situation, guaranteed.
On Thu, 2007-10-25 at 09:55 +1000, Neil Brown wrote:
As for where the metadata should be placed, it is interesting to
observe that the SNIA's DDFv1.2 puts it at the end of the device.
And as DDF is an industry standard sponsored by multiple companies it
must be ..
Sorry. I had intended
Jeff Garzik wrote:
Neil Brown wrote:
As for where the metadata should be placed, it is interesting to
observe that the SNIA's DDFv1.2 puts it at the end of the device.
And as DDF is an industry standard sponsored by multiple companies it
must be ..
Sorry. I had intended to say correct,
Neil Brown wrote:
I certainly accept that the documentation is probably less that
perfect (by a large margin). I am more than happy to accept patches
or concrete suggestions on how to improve that. I always think it is
best if a non-developer writes documentation (and a developer reviews
it)
Bill Davidsen wrote:
Neil Brown wrote:
I certainly accept that the documentation is probably less that
perfect (by a large margin). I am more than happy to accept patches
or concrete suggestions on how to improve that. I always think it is
best if a non-developer writes documentation (and a
On Wed, 2007-10-24 at 16:22 -0400, Bill Davidsen wrote:
Doug Ledford wrote:
On Mon, 2007-10-22 at 16:39 -0400, John Stoffel wrote:
I don't agree completely. I think the superblock location is a key
issue, because if you have a superblock location which moves depending
the
On Thursday October 25, [EMAIL PROTECTED] wrote:
Neil Brown wrote:
I certainly accept that the documentation is probably less that
perfect (by a large margin). I am more than happy to accept patches
or concrete suggestions on how to improve that. I always think it is
best if a
Doug Ledford wrote:
On Mon, 2007-10-22 at 16:39 -0400, John Stoffel wrote:
I don't agree completely. I think the superblock location is a key
issue, because if you have a superblock location which moves depending
the filesystem or LVM you use to look at the partition (or full disk)
then
Bill == Bill Davidsen [EMAIL PROTECTED] writes:
Bill John Stoffel wrote:
Why do we have three different positions for storing the superblock?
Bill Why do you suggest changing anything until you get the answer to
Bill this question? If you don't understand why there are three
Bill locations,
On 10/24/07, John Stoffel [EMAIL PROTECTED] wrote:
Bill == Bill Davidsen [EMAIL PROTECTED] writes:
Bill John Stoffel wrote:
Why do we have three different positions for storing the superblock?
Bill Why do you suggest changing anything until you get the answer to
Bill this question? If you
John Stoffel wrote:
Bill == Bill Davidsen [EMAIL PROTECTED] writes:
Bill John Stoffel wrote:
Why do we have three different positions for storing the superblock?
Bill Why do you suggest changing anything until you get the answer to
Bill this question? If you don't
Doug Ledford wrote:
On Mon, 2007-10-22 at 16:39 -0400, John Stoffel wrote:
I don't agree completely. I think the superblock location is a key
issue, because if you have a superblock location which moves depending
the filesystem or LVM you use to look at the partition (or full disk)
then
On Tuesday October 23, [EMAIL PROTECTED] wrote:
On Tue, 2007-10-23 at 19:03 -0400, Bill Davidsen wrote:
John Stoffel wrote:
Why do we have three different positions for storing the superblock?
Why do you suggest changing anything until you get the answer to this
question? If you
Neil Brown wrote:
On Tuesday October 23, [EMAIL PROTECTED] wrote:
As for where the metadata should be placed, it is interesting to
observe that the SNIA's DDFv1.2 puts it at the end of the device.
And as DDF is an industry standard sponsored by multiple companies it
must be ..
Sorry. I had
John Stoffel wrote:
Why do we have three different positions for storing the superblock?
Why do you suggest changing anything until you get the answer to this
question? If you don't understand why there are three locations, perhaps
that would be a good initial investigation.
Clearly the
Doug Ledford wrote:
On Fri, 2007-10-19 at 23:23 +0200, Iustin Pop wrote:
On Fri, Oct 19, 2007 at 02:39:47PM -0400, John Stoffel wrote:
And if putting the superblock at the end is problematic, why is it the
default? Shouldn't version 1.1 be the default?
In my opinion, having
John Stoffel wrote:
Michael == Michael Tokarev [EMAIL PROTECTED] writes:
Michael Doug Ledford wrote:
Michael []
1.0, 1.1, and 1.2 are the same format, just in different positions on
the disk. Of the three, the 1.1 format is the safest to use since it
won't allow you to
Justin Piszcz wrote:
On Fri, 19 Oct 2007, John Stoffel wrote:
Justin == Justin Piszcz [EMAIL PROTECTED] writes:
Justin On Fri, 19 Oct 2007, John Stoffel wrote:
So,
Is it time to start thinking about deprecating the old 0.9, 1.0 and
1.1 formats to just standardize on the 1.2 format?
On Tue, 2007-10-23 at 19:03 -0400, Bill Davidsen wrote:
John Stoffel wrote:
Why do we have three different positions for storing the superblock?
Why do you suggest changing anything until you get the answer to this
question? If you don't understand why there are three locations,
On Tue, 2007-10-23 at 21:21 +0200, Michal Soltys wrote:
Doug Ledford wrote:
Well, first I was thinking of files in the few hundreds of megabytes
each to gigabytes each, and when they are streamed, they are streamed at
a rate much lower than the full speed of the array, but still at a
On Sat, 2007-10-20 at 22:24 +0400, Michael Tokarev wrote:
John Stoffel wrote:
Michael == Michael Tokarev [EMAIL PROTECTED] writes:
As Doug says, and I agree strongly, you DO NOT want to have the
possibility of confusion and data loss, especially on bootup. And
There are different point
On Mon, 2007-10-22 at 16:39 -0400, John Stoffel wrote:
I don't agree completely. I think the superblock location is a key
issue, because if you have a superblock location which moves depending
the filesystem or LVM you use to look at the partition (or full disk)
then you need to be even more
[ I was going to reply to this earlier, but the Red Sox and good
weather got into the way this weekend. ;-]
Michael == Michael Tokarev [EMAIL PROTECTED] writes:
Michael I'm doing a sysadmin work for about 15 or 20 years.
Welcome to the club! It's a fun career, always something new to
learn.
John Stoffel wrote:
Michael == Michael Tokarev [EMAIL PROTECTED] writes:
If you are going to mirror an existing filesystem, then by definition
you have a second disk or partition available for the purpose. So you
would merely setup the new RAID1, in degraded mode, using the new
partition
On Sat, 2007-10-20 at 09:53 +0200, Iustin Pop wrote:
Honestly, I don't see how a properly configured system would start
looking at the physical device by mistake. I suppose it's possible, but
I didn't have this issue.
Mount by label support scans all devices in /proc/partitions looking for
On Sat, 2007-10-20 at 00:43 +0200, Michal Soltys wrote:
Doug Ledford wrote:
course, this comes at the expense of peak throughput on the device.
Let's say you were building a mondo movie server, where you were
streaming out digital movie files. In that case, you very well may care
more
Doug Ledford wrote:
[]
1.0, 1.1, and 1.2 are the same format, just in different positions on
the disk. Of the three, the 1.1 format is the safest to use since it
won't allow you to accidentally have some sort of metadata between the
beginning of the disk and the raid superblock (such as an
Michael == Michael Tokarev [EMAIL PROTECTED] writes:
Michael Doug Ledford wrote:
Michael []
1.0, 1.1, and 1.2 are the same format, just in different positions on
the disk. Of the three, the 1.1 format is the safest to use since it
won't allow you to accidentally have some sort of metadata
On Sat, Oct 20, 2007 at 10:52:39AM -0400, John Stoffel wrote:
Michael Well, I strongly, completely disagree. You described a
Michael real-world situation, and that's unfortunate, BUT: for at
Michael least raid1, there ARE cases, pretty valid ones, when one
Michael NEEDS to mount the
On Sat, 2007-10-20 at 17:07 +0200, Iustin Pop wrote:
On Sat, Oct 20, 2007 at 10:52:39AM -0400, John Stoffel wrote:
Michael Well, I strongly, completely disagree. You described a
Michael real-world situation, and that's unfortunate, BUT: for at
Michael least raid1, there ARE cases, pretty
John Stoffel wrote:
Michael == Michael Tokarev [EMAIL PROTECTED] writes:
[]
Michael Well, I strongly, completely disagree. You described a
Michael real-world situation, and that's unfortunate, BUT: for at
Michael least raid1, there ARE cases, pretty valid ones, when one
Michael NEEDS to
Justin Piszcz wrote:
On Fri, 19 Oct 2007, Doug Ledford wrote:
On Fri, 2007-10-19 at 13:05 -0400, Justin Piszcz wrote:
[]
Got it, so for RAID1 it would make sense if LILO supported it (the
later versions of the md superblock)
Lilo doesn't know anything about the superblock format,
On Sat, 2007-10-20 at 22:38 +0400, Michael Tokarev wrote:
Justin Piszcz wrote:
On Fri, 19 Oct 2007, Doug Ledford wrote:
On Fri, 2007-10-19 at 13:05 -0400, Justin Piszcz wrote:
[]
Got it, so for RAID1 it would make sense if LILO supported it (the
later versions of the md superblock)
So,
Is it time to start thinking about deprecating the old 0.9, 1.0 and
1.1 formats to just standardize on the 1.2 format? What are the
issues surrounding this?
It's certainly easy enough to change mdadm to default to the 1.2
format and to require a --force switch to allow use of the older
On Fri, 19 Oct 2007, Doug Ledford wrote:
On Fri, 2007-10-19 at 13:05 -0400, Justin Piszcz wrote:
I'm sure an internal bitmap would. On RAID1 arrays, reads/writes are
never split up by a chunk size for stripes. A 2mb read is a single
read, where as on a raid4/5/6 array, a 2mb read will end
On Fri, Oct 19, 2007 at 02:39:47PM -0400, John Stoffel wrote:
And if putting the superblock at the end is problematic, why is it the
default? Shouldn't version 1.1 be the default?
In my opinion, having the superblock *only* at the end (e.g. the 0.90
format) is the best option.
It allows one
On Fri, 2007-10-19 at 23:23 +0200, Iustin Pop wrote:
On Fri, Oct 19, 2007 at 02:39:47PM -0400, John Stoffel wrote:
And if putting the superblock at the end is problematic, why is it the
default? Shouldn't version 1.1 be the default?
In my opinion, having the superblock *only* at the end
On Fri, 2007-10-19 at 12:38 -0400, John Stoffel wrote:
1, 1.0, 1.1, 1.2
Use the new version-1 format superblock. This has few restrictions.
The different sub-versions store the superblock at different locations
on the device, either at the end (for 1.0), at the start
On Fri, 19 Oct 2007, Doug Ledford wrote:
On Fri, 2007-10-19 at 12:45 -0400, Justin Piszcz wrote:
On Fri, 19 Oct 2007, John Stoffel wrote:
Justin == Justin Piszcz [EMAIL PROTECTED] writes:
Justin Is a bitmap created by default with 1.x? I remember seeing
Justin reports of 15-30%
Justin == Justin Piszcz [EMAIL PROTECTED] writes:
Justin Is a bitmap created by default with 1.x? I remember seeing
Justin reports of 15-30% performance degradation using a bitmap on a
Justin RAID5 with 1.x.
Not according to the mdadm man page. I'd probably give up that
performance if it
On Fri, 19 Oct 2007, John Stoffel wrote:
Doug == Doug Ledford [EMAIL PROTECTED] writes:
Doug On Fri, 2007-10-19 at 11:46 -0400, John Stoffel wrote:
Justin == Justin Piszcz [EMAIL PROTECTED] writes:
Justin On Fri, 19 Oct 2007, John Stoffel wrote:
So,
Is it time to start thinking
On Fri, 19 Oct 2007, Doug Ledford wrote:
On Fri, 2007-10-19 at 11:46 -0400, John Stoffel wrote:
Justin == Justin Piszcz [EMAIL PROTECTED] writes:
Justin On Fri, 19 Oct 2007, John Stoffel wrote:
So,
Is it time to start thinking about deprecating the old 0.9, 1.0 and
1.1 formats to just
On Fri, 19 Oct 2007, John Stoffel wrote:
Justin == Justin Piszcz [EMAIL PROTECTED] writes:
Justin On Fri, 19 Oct 2007, John Stoffel wrote:
So,
Is it time to start thinking about deprecating the old 0.9, 1.0 and
1.1 formats to just standardize on the 1.2 format? What are the
issues
Justin == Justin Piszcz [EMAIL PROTECTED] writes:
Justin On Fri, 19 Oct 2007, John Stoffel wrote:
So,
Is it time to start thinking about deprecating the old 0.9, 1.0 and
1.1 formats to just standardize on the 1.2 format? What are the
issues surrounding this?
It's certainly easy
On Fri, 19 Oct 2007, John Stoffel wrote:
So,
Is it time to start thinking about deprecating the old 0.9, 1.0 and
1.1 formats to just standardize on the 1.2 format? What are the
issues surrounding this?
It's certainly easy enough to change mdadm to default to the 1.2
format and to require
Doug == Doug Ledford [EMAIL PROTECTED] writes:
Doug On Fri, 2007-10-19 at 12:38 -0400, John Stoffel wrote:
1, 1.0, 1.1, 1.2
Use the new version-1 format superblock. This has few restrictions.
The different sub-versions store the superblock at different locations
on the device, either at
On Fri, 19 Oct 2007, John Stoffel wrote:
Justin == Justin Piszcz [EMAIL PROTECTED] writes:
Justin Is a bitmap created by default with 1.x? I remember seeing
Justin reports of 15-30% performance degradation using a bitmap on a
Justin RAID5 with 1.x.
Not according to the mdadm man page.
Doug == Doug Ledford [EMAIL PROTECTED] writes:
Doug On Fri, 2007-10-19 at 11:46 -0400, John Stoffel wrote:
Justin == Justin Piszcz [EMAIL PROTECTED] writes:
Justin On Fri, 19 Oct 2007, John Stoffel wrote:
So,
Is it time to start thinking about deprecating the old 0.9, 1.0 and
On Fri, 2007-10-19 at 11:46 -0400, John Stoffel wrote:
Justin == Justin Piszcz [EMAIL PROTECTED] writes:
Justin On Fri, 19 Oct 2007, John Stoffel wrote:
So,
Is it time to start thinking about deprecating the old 0.9, 1.0 and
1.1 formats to just standardize on the 1.2 format?
Doug Ledford wrote:
course, this comes at the expense of peak throughput on the device.
Let's say you were building a mondo movie server, where you were
streaming out digital movie files. In that case, you very well may care
more about throughput than seek performance since I suspect you
79 matches
Mail list logo
