Re: [klibc] Re: Exporting which partitions to md-configure
On Tue, Feb 07, 2006 at 08:55:21AM -0800, H. Peter Anvin wrote: Luca Berra wrote: making it harder for the user is a good thing, but please not at the expense of usability What's the usability problem? if we fail to support all partitioning schemes and we do not support non partitioned devices. if we manage to support all this without too much code bloat i'll shut up. L. -- Luca Berra -- [EMAIL PROTECTED] Communication Media & Services S.r.l. /"\ \ / ASCII RIBBON CAMPAIGN XAGAINST HTML MAIL / \ - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [klibc] Re: Exporting which partitions to md-configure
Luca Berra wrote: making it harder for the user is a good thing, but please not at the expense of usability What's the usability problem? -hpa - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [klibc] Re: Exporting which partitions to md-configure
On Tue, Feb 07, 2006 at 07:46:59AM -0800, H. Peter Anvin wrote: Luca Berra wrote: I don't like using partition type as a qualifier, there is people who do not wish to partition their drives, there are systems not supporting msdos like partitions, heck even m$ is migrating away from those. That's why we're talking about non-msdos partitioning schemes. this still leaves whole disks If the user wants to reutilize a device that was previously a member of an md array he/she should use mdadm --zero-superblock to remove the superblock. I see no point in having a system that tries to compensate for users not following correct procedures. sorry. You don't? That surprises me... making it harder for the user to have accidental data loss sounds like a very good thing to me. making it harder for the user is a good thing, but please not at the expense of usability the only way i see a user can have data loss is if - a md array is stopped - two different filesystems are created on the component devices - these filesystems are filled with data, but not to the point of damaging the superblock - then the array is started again. if only one device is removed using mdadm the event counter would prevent the array from being assembled again. there are a lot of easier ways for shooting yourself in the feet :) if we really want to be paranoid we should modify mkXXXfs to refuse creating a filesystem if the device has an md superblock on it. (lvm2 tools are already able to ignore devices with md superblocks on them, no clue about EVMS) L. -- Luca Berra -- [EMAIL PROTECTED] Communication Media & Services S.r.l. /"\ \ / ASCII RIBBON CAMPAIGN XAGAINST HTML MAIL / \ - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [klibc] Re: Exporting which partitions to md-configure
Luca Berra wrote: This, in fact is *EXACTLY* what we're talking about; it does require autoassemble. Why do we care about the partition types at all? The reason is that since the md superblock is at the end, it doesn't get automatically wiped if the partition is used as a raw filesystem, and so it's important that there is a qualifier for it. I don't like using partition type as a qualifier, there is people who do not wish to partition their drives, there are systems not supporting msdos like partitions, heck even m$ is migrating away from those. That's why we're talking about non-msdos partitioning schemes. In any case if that has to be done it should be done into mdadm, not in a different scrip that is going to call mdadm (behaviour should be consistent between mdadm invoked by initramfs and mdadm invoked on a running system). Agreed. mdadm is the best place for it. If the user wants to reutilize a device that was previously a member of an md array he/she should use mdadm --zero-superblock to remove the superblock. I see no point in having a system that tries to compensate for users not following correct procedures. sorry. You don't? That surprises me... making it harder for the user to have accidental data loss sounds like a very good thing to me. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [klibc] Re: Exporting which partitions to md-configure
On Mon, Feb 06, 2006 at 06:47:54PM -0800, H. Peter Anvin wrote: Neil Brown wrote: Requiring that mdadm.conf describes the actual state of all volumes would be an enormous step in the wrong direction. Right now, the Linux md system can handle some very oddball hardware changes (such as on hera.kernel.org, when the disks not just completely changed names due to a controller change, but changed from hd* to sd*!) DEVICE partitions ARRAY /dev/md0 UUID=xxyy:zzyy:aabb:ccdd would catch that Dynamicity is a good thing, although it needs to be harnessed. > kernel parameter md_root_uuid=xxyy:zzyy:aabb:ccdd... >This could be interpreted by an initramfs script to run mdadm >to find and assemble the array with that uuid. The uuid of >each array is reasonably unique. I could change mdassemble to allow accepting an uuid on the command line and assemble a /dev/md0 with the specified uuid (at the moment it only accepts a configuration file, which i tought was enough for initrd/initramfs. This, in fact is *EXACTLY* what we're talking about; it does require autoassemble. Why do we care about the partition types at all? The reason is that since the md superblock is at the end, it doesn't get automatically wiped if the partition is used as a raw filesystem, and so it's important that there is a qualifier for it. I don't like using partition type as a qualifier, there is people who do not wish to partition their drives, there are systems not supporting msdos like partitions, heck even m$ is migrating away from those. In any case if that has to be done it should be done into mdadm, not in a different scrip that is going to call mdadm (behaviour should be consistent between mdadm invoked by initramfs and mdadm invoked on a running system). If the user wants to reutilize a device that was previously a member of an md array he/she should use mdadm --zero-superblock to remove the superblock. I see no point in having a system that tries to compensate for users not following correct procedures. sorry. L. -- Luca Berra -- [EMAIL PROTECTED] Communication Media & Services S.r.l. /"\ \ / ASCII RIBBON CAMPAIGN XAGAINST HTML MAIL / \ - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [klibc] Re: Exporting which partitions to md-configure
On Monday February 6, [EMAIL PROTECTED] wrote: > Neil Brown wrote: > > > > Just as there is a direct unambiguous causal path from something > > present at early boot to the root filesystem that is mounted (and the > > root filesystem specifies all other filesystems through fstab) > > similarly there should be an unambiguous causal path from something > > present at early boot to the array which holds the root filesystem - > > and the root filesystem should describe all other arrays via > > mdadm.conf > > > > Does that make sense? > > > > It makes sense, but I disagree. I believe you are correct in that the > current "preferred minor" bit causes an invalid assumption that, e.g. > /dev/md3 is always a certain thing, but since each array has a UUID, and > one should be able to mount by either filesystem UUID or array UUID, > there should be no need for such a conflict if one allows for dynamic md > numbers. > > Requiring that mdadm.conf describes the actual state of all volumes > would be an enormous step in the wrong direction. Right now, the Linux > md system can handle some very oddball hardware changes (such as on > hera.kernel.org, when the disks not just completely changed names due to > a controller change, but changed from hd* to sd*!) mdadm.conf doesn't need to, and normally shouldn't, list the devices that compose an array (though it can if you want it to). A typical mdadm.conf should look something like: DEVICES /dev/hd* /dev/sd* ARRAY /dev/md0 UUID=some:long:uuid ARRAY /dev/md1 UUID=some:other:long:uuid So I think we are actually in agreement. > > Dynamicity is a good thing, although it needs to be harnessed. > > > kernel parameter md_root_uuid=xxyy:zzyy:aabb:ccdd... > >This could be interpreted by an initramfs script to run mdadm > >to find and assemble the array with that uuid. The uuid of > >each array is reasonably unique. > > This, in fact is *EXACTLY* what we're talking about; it does require > autoassemble. Why do we care about the partition types at all? The > reason is that since the md superblock is at the end, it doesn't get > automatically wiped if the partition is used as a raw filesystem, and so > it's important that there is a qualifier for it. Maybe I should be explicit about what I am against. I am against the practice of choosing devices to assemble into arrays based simply on a partition type - and assembling them into whatever arrays they appear to comprise. A device should not be able to say "pick me, pick me!". Something *outside* the array should say "pick all devices matching X", where X is some arbitrary predicate, that could involve partition type information if you like, but importantly should be precise enough not to choose wrongly in any but very exceptional circumstances. I am *not* against 'autoassemble' in the sense that some process hunts through available devices trying to find the components for a give md array: It was primarily to achieve this that I wrote mdadm. I just want the 'autoassemble' to be driven by some external description of the array(s) - e.g. uuid. I don't accept your argument that partition types are of interest because array components could still have their superblock after being retargeted. This is because - running "mdadm --zero-superblock" is as easy as changing the partition type, and equally, both are easy to forget to do. - If you have retargeted devices in an array, you presumably don't put the UUID of that array anywhere that would encourage mdadm to assemble it. So the fact that the UUID won't be recognised is just as good at stopping the array from being assembled as that fact that the partition type has been changed. This doesn't mean I am violently against partition types (and for legacy support, we need to use them). I just don't see a lot of value in using them. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [klibc] Re: Exporting which partitions to md-configure
Neil Brown wrote: What constitutes 'a piece of data'? A bit? a byte? I would say that msdos:fd is one piece of data. The 'fd' is useless without the 'msdos'. The 'msdos' is, I guess, not completely useless with the fd. I would lean towards the composite, but I wouldn't fight a separation. Well, the two pieces come from different sources. Just as there is a direct unambiguous causal path from something present at early boot to the root filesystem that is mounted (and the root filesystem specifies all other filesystems through fstab) similarly there should be an unambiguous causal path from something present at early boot to the array which holds the root filesystem - and the root filesystem should describe all other arrays via mdadm.conf Does that make sense? It makes sense, but I disagree. I believe you are correct in that the current "preferred minor" bit causes an invalid assumption that, e.g. /dev/md3 is always a certain thing, but since each array has a UUID, and one should be able to mount by either filesystem UUID or array UUID, there should be no need for such a conflict if one allows for dynamic md numbers. Requiring that mdadm.conf describes the actual state of all volumes would be an enormous step in the wrong direction. Right now, the Linux md system can handle some very oddball hardware changes (such as on hera.kernel.org, when the disks not just completely changed names due to a controller change, but changed from hd* to sd*!) Dynamicity is a good thing, although it needs to be harnessed. > kernel parameter md_root_uuid=xxyy:zzyy:aabb:ccdd... >This could be interpreted by an initramfs script to run mdadm >to find and assemble the array with that uuid. The uuid of >each array is reasonably unique. This, in fact is *EXACTLY* what we're talking about; it does require autoassemble. Why do we care about the partition types at all? The reason is that since the md superblock is at the end, it doesn't get automatically wiped if the partition is used as a raw filesystem, and so it's important that there is a qualifier for it. -hpa - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [klibc] Re: Exporting which partitions to md-configure
On Mon, Jan 30, 2006 at 05:42:45PM -0800, H. Peter Anvin wrote: > What about non-DOS partitions? Is something like libblkid suitable as a starting point of something you can cut-down-to-size? textdata bss dec hex filename 249782272 12 272626a7e /lib/libblkid.so.1 - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
