Re: [util-linux] Re: magic device renumbering was -- Re: Linux 2.4.2ac20
Andreas Dilger writes: > Andries writes: > > > I've implemented a patch for util-linux-2.11a > > > which adds LABEL support to mkswap(8) and swapon/swapoff(8). > > > > But I would prefer a somewhat more ambitious approach. > > > > My first thought was: why label individual swap partitions? > > I almost never want to distinguish swap partitions, and just do > > "swapon -a". In case one wants to guard against changing device names, > > why not add an option -A so that "swapon -A" does swapon on each > > partition with a swap signature? > > > > However, that would greatly increase the risk that exists already > > today: someone has a swap partition, and does mkfs.foo, and > > it so happens that foofs does not use the sector with the swapsignature. > > Now this foofs partition has a swap signature, but we would be very > > unhappy if it were used as swap space. > > I think the LABEL is a good intermediate step for people not using LVM. > It basically allows your /etc/fstab to not have _any_ device names in it. Exactly. IMO, it doesn't really help having LABEL= on your ext2 partitions in /etc/fstab if you cannot also do the same on swap partitions. My LABEL= patch for mkswap/swapon may not be as sexy as a brand new partition table format [which arguably is the better solution in the long run], but it does provide a useful improvement NOW with minimal implementation cost and full compatibility with existing 2.2/2.4 kernels. > I'm not sure I would be happy with auto-mounting swap partitions, > especially because this would overwrite any data in the partition. Bad. Me too. I can easily add Andries' "swapon -A" to my patch, but I really don't think that semantics should be the default. Cheers, /Mikael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [util-linux] Re: magic device renumbering was -- Re: Linux 2.4.2ac20
Andreas Dilger writes: Andries writes: I've implemented a patch for util-linux-2.11a which adds LABEL support to mkswap(8) and swapon/swapoff(8). But I would prefer a somewhat more ambitious approach. My first thought was: why label individual swap partitions? I almost never want to distinguish swap partitions, and just do "swapon -a". In case one wants to guard against changing device names, why not add an option -A so that "swapon -A" does swapon on each partition with a swap signature? However, that would greatly increase the risk that exists already today: someone has a swap partition, and does mkfs.foo, and it so happens that foofs does not use the sector with the swapsignature. Now this foofs partition has a swap signature, but we would be very unhappy if it were used as swap space. I think the LABEL is a good intermediate step for people not using LVM. It basically allows your /etc/fstab to not have _any_ device names in it. Exactly. IMO, it doesn't really help having LABEL= on your ext2 partitions in /etc/fstab if you cannot also do the same on swap partitions. My LABEL= patch for mkswap/swapon may not be as sexy as a brand new partition table format [which arguably is the better solution in the long run], but it does provide a useful improvement NOW with minimal implementation cost and full compatibility with existing 2.2/2.4 kernels. I'm not sure I would be happy with auto-mounting swap partitions, especially because this would overwrite any data in the partition. Bad. Me too. I can easily add Andries' "swapon -A" to my patch, but I really don't think that semantics should be the default. Cheers, /Mikael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [util-linux] Re: magic device renumbering was -- Re: Linux 2.4.2ac20
In article <[EMAIL PROTECTED]> you wrote: > The real problem is that our disks usually do not have a volume label. > Outside of all file systems. > The "signatures" that we rely on today are located in different places, > so that a filesystem can have several valid signatures at the same time. > And we first know where to look when we know the type already. > > Design a Linux partition table format, where a partition descriptor > has fields start, end, fstype, fslabel, and the whole disk has a vollabel. > Put it in sector 0-N for an all-Linux disk, and in sectors pointed at > by a classical DOS-type partition table entry when the disk is shared. I don't understand that. Do you propose something like *BSD or Solaris disklabels? In that case a whole new set of user utilities would be needed to create your new tables as well as maintaining the old style partition tables. The process of copying or moving fs around disks seems to be quite common as tools like partition magic or parted suggest. Your idea would make that process more difficult and less user-friendly. It should imho always be simple to backup an fs to tape from a dying disk and restore it to a new one without losing the label etc. Perhaps putting this kind of information into a generalized start sector for all Linux fs would be a better idea (is that what you meant?). Copying an fs would again be as easy as using dd or cp. Of course this means that most Linux fs types including swap partitions should leave this start sector alone. A common mkfs would create that leading block after the mkfs. successfully created the fs meta-contents. It would be optimal imho if the partition table entry contains the start sector and size only, and all other information like type, uuid, label etc. is within the fs disk space. No out-of-band fs information anymore. The disk volume label should be located outside all fs as you mentioned but separated from the actual fs labels. -- Michail Brzitwa <[EMAIL PROTECTED]>+49-511-343215 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [util-linux] Re: magic device renumbering was -- Re: Linux 2.4.2ac20
Andries writes: > > I've implemented a patch for util-linux-2.11a > > which adds LABEL support to mkswap(8) and swapon/swapoff(8). > > But I would prefer a somewhat more ambitious approach. > > My first thought was: why label individual swap partitions? > I almost never want to distinguish swap partitions, and just do > "swapon -a". In case one wants to guard against changing device names, > why not add an option -A so that "swapon -A" does swapon on each > partition with a swap signature? > > However, that would greatly increase the risk that exists already > today: someone has a swap partition, and does mkfs.foo, and > it so happens that foofs does not use the sector with the swapsignature. > Now this foofs partition has a swap signature, but we would be very > unhappy if it were used as swap space. I think the LABEL is a good intermediate step for people not using LVM. It basically allows your /etc/fstab to not have _any_ device names in it. I'm not sure I would be happy with auto-mounting swap partitions, especially because this would overwrite any data in the partition. Bad. > The real problem is that our disks usually do not have a volume label. > Outside of all file systems. > The "signatures" that we rely on today are located in different places, > so that a filesystem can have several valid signatures at the same time. > And we first know where to look when we know the type already. > > Design a Linux partition table format, where a partition descriptor > has fields start, end, fstype, fslabel, and the whole disk has a vollabel. > Put it in sector 0-N for an all-Linux disk, and in sectors pointed at > by a classical DOS-type partition table entry when the disk is shared. > > (Maybe I already did that once - it sounds so familiar now that I write > this. Then why was it not pursued? Maybe LVM already does these things?) LVM will handle the disk and "partition" naming and size issues. It does NOT currently handle the fstype names, but this _could_ be determined via magic numbers, as now. In the "(struct dentry *)->vfsmnt" thread, I was trying to work out a way to get mountpoint information for LVM. In the end, I think I will store most of the /etc/fstab line into a field in the LV header, so it is easily retrievable. This would also include the fstype, and mount/dump/fsck options. It would _not_ store the device name. The proposed solution would be to have mount(8) write the mount info to the disk (for logical volumes only, of course) at mount time. I suppose the fs type, options, mountpoint could come from either /etc/fstab or from the command-line, since mount(8) is already parsing all of this info. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [util-linux] Re: magic device renumbering was -- Re: Linux 2.4.2ac20
> I've implemented a patch for util-linux-2.11a > which adds LABEL support to mkswap(8) and swapon/swapoff(8). Yes, maybe a reasonable idea. But I would prefer a somewhat more ambitious approach. My first thought was: why label individual swap partitions? I almost never want to distinguish swap partitions, and just do "swapon -a". In case one wants to guard against changing device names, why not add an option -A so that "swapon -A" does swapon on each partition with a swap signature? However, that would greatly increase the risk that exists already today: someone has a swap partition, and does mkfs.foo, and it so happens that foofs does not use the sector with the swapsignature. Now this foofs partition has a swap signature, but we would be very unhappy if it were used as swap space. The real problem is that our disks usually do not have a volume label. Outside of all file systems. The "signatures" that we rely on today are located in different places, so that a filesystem can have several valid signatures at the same time. And we first know where to look when we know the type already. Design a Linux partition table format, where a partition descriptor has fields start, end, fstype, fslabel, and the whole disk has a vollabel. Put it in sector 0-N for an all-Linux disk, and in sectors pointed at by a classical DOS-type partition table entry when the disk is shared. (Maybe I already did that once - it sounds so familiar now that I write this. Then why was it not pursued? Maybe LVM already does these things?) Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [util-linux] Re: magic device renumbering was -- Re: Linux 2.4.2ac20
I've implemented a patch for util-linux-2.11a which adds LABEL support to mkswap(8) and swapon/swapoff(8). Yes, maybe a reasonable idea. But I would prefer a somewhat more ambitious approach. My first thought was: why label individual swap partitions? I almost never want to distinguish swap partitions, and just do "swapon -a". In case one wants to guard against changing device names, why not add an option -A so that "swapon -A" does swapon on each partition with a swap signature? However, that would greatly increase the risk that exists already today: someone has a swap partition, and does mkfs.foo, and it so happens that foofs does not use the sector with the swapsignature. Now this foofs partition has a swap signature, but we would be very unhappy if it were used as swap space. The real problem is that our disks usually do not have a volume label. Outside of all file systems. The "signatures" that we rely on today are located in different places, so that a filesystem can have several valid signatures at the same time. And we first know where to look when we know the type already. Design a Linux partition table format, where a partition descriptor has fields start, end, fstype, fslabel, and the whole disk has a vollabel. Put it in sector 0-N for an all-Linux disk, and in sectors pointed at by a classical DOS-type partition table entry when the disk is shared. (Maybe I already did that once - it sounds so familiar now that I write this. Then why was it not pursued? Maybe LVM already does these things?) Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [util-linux] Re: magic device renumbering was -- Re: Linux 2.4.2ac20
Andries writes: I've implemented a patch for util-linux-2.11a which adds LABEL support to mkswap(8) and swapon/swapoff(8). But I would prefer a somewhat more ambitious approach. My first thought was: why label individual swap partitions? I almost never want to distinguish swap partitions, and just do "swapon -a". In case one wants to guard against changing device names, why not add an option -A so that "swapon -A" does swapon on each partition with a swap signature? However, that would greatly increase the risk that exists already today: someone has a swap partition, and does mkfs.foo, and it so happens that foofs does not use the sector with the swapsignature. Now this foofs partition has a swap signature, but we would be very unhappy if it were used as swap space. I think the LABEL is a good intermediate step for people not using LVM. It basically allows your /etc/fstab to not have _any_ device names in it. I'm not sure I would be happy with auto-mounting swap partitions, especially because this would overwrite any data in the partition. Bad. The real problem is that our disks usually do not have a volume label. Outside of all file systems. The "signatures" that we rely on today are located in different places, so that a filesystem can have several valid signatures at the same time. And we first know where to look when we know the type already. Design a Linux partition table format, where a partition descriptor has fields start, end, fstype, fslabel, and the whole disk has a vollabel. Put it in sector 0-N for an all-Linux disk, and in sectors pointed at by a classical DOS-type partition table entry when the disk is shared. (Maybe I already did that once - it sounds so familiar now that I write this. Then why was it not pursued? Maybe LVM already does these things?) LVM will handle the disk and "partition" naming and size issues. It does NOT currently handle the fstype names, but this _could_ be determined via magic numbers, as now. In the "(struct dentry *)-vfsmnt" thread, I was trying to work out a way to get mountpoint information for LVM. In the end, I think I will store most of the /etc/fstab line into a field in the LV header, so it is easily retrievable. This would also include the fstype, and mount/dump/fsck options. It would _not_ store the device name. The proposed solution would be to have mount(8) write the mount info to the disk (for logical volumes only, of course) at mount time. I suppose the fs type, options, mountpoint could come from either /etc/fstab or from the command-line, since mount(8) is already parsing all of this info. Cheers, Andreas -- Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto, \ would they cancel out, leaving him still hungry?" http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [util-linux] Re: magic device renumbering was -- Re: Linux 2.4.2ac20
In article [EMAIL PROTECTED] you wrote: The real problem is that our disks usually do not have a volume label. Outside of all file systems. The "signatures" that we rely on today are located in different places, so that a filesystem can have several valid signatures at the same time. And we first know where to look when we know the type already. Design a Linux partition table format, where a partition descriptor has fields start, end, fstype, fslabel, and the whole disk has a vollabel. Put it in sector 0-N for an all-Linux disk, and in sectors pointed at by a classical DOS-type partition table entry when the disk is shared. I don't understand that. Do you propose something like *BSD or Solaris disklabels? In that case a whole new set of user utilities would be needed to create your new tables as well as maintaining the old style partition tables. The process of copying or moving fs around disks seems to be quite common as tools like partition magic or parted suggest. Your idea would make that process more difficult and less user-friendly. It should imho always be simple to backup an fs to tape from a dying disk and restore it to a new one without losing the label etc. Perhaps putting this kind of information into a generalized start sector for all Linux fs would be a better idea (is that what you meant?). Copying an fs would again be as easy as using dd or cp. Of course this means that most Linux fs types including swap partitions should leave this start sector alone. A common mkfs would create that leading block after the mkfs.fs type successfully created the fs meta-contents. It would be optimal imho if the partition table entry contains the start sector and size only, and all other information like type, uuid, label etc. is within the fs disk space. No out-of-band fs information anymore. The disk volume label should be located outside all fs as you mentioned but separated from the actual fs labels. -- Michail Brzitwa [EMAIL PROTECTED]+49-511-343215 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
