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: magic device renumbering was -- Re: Linux 2.4.2ac20
Hi, On Wed, Mar 14, 2001 at 02:11:57PM -0500, Lars Kellogg-Stedman wrote: > > Put LABEL= in you fstab in place of the device name. > > Which is great, for filesystems that support labels. Unfortunately, > this isn't universally available -- for instance, you cannot mount > a swap partition by label or uuid, so it is not possible to completely > isolate yourself from the problems of disk device renumbering. It's not convenient, but it is certainly possible: use a single-partition raid0 logical device with raid autostart, and you get a logical /dev/md* device which corresponds to a single partition and which has a fixed name which is detected by the kernel at runtime and mapped to the correct disk, wherever the disk may be. The IBM EVMS folks are looking to generalise this sort of probing, but for now there is at least one solution to this problem. LVM works too to some extent, but it currently lacks the automatic boot-time/ device-detect-time kernel probing step that the software raid code has. Cheers, Stephen - 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: magic device renumbering was -- Re: Linux 2.4.2ac20
Hi, On Wed, Mar 14, 2001 at 02:11:57PM -0500, Lars Kellogg-Stedman wrote: Put LABEL=label set with e2label in you fstab in place of the device name. Which is great, for filesystems that support labels. Unfortunately, this isn't universally available -- for instance, you cannot mount a swap partition by label or uuid, so it is not possible to completely isolate yourself from the problems of disk device renumbering. It's not convenient, but it is certainly possible: use a single-partition raid0 logical device with raid autostart, and you get a logical /dev/md* device which corresponds to a single partition and which has a fixed name which is detected by the kernel at runtime and mapped to the correct disk, wherever the disk may be. The IBM EVMS folks are looking to generalise this sort of probing, but for now there is at least one solution to this problem. LVM works too to some extent, but it currently lacks the automatic boot-time/ device-detect-time kernel probing step that the software raid code has. Cheers, Stephen - 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: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, 14 Mar 2001 12:34:06 -0700 (MST), Andreas Dilger wrote in LKML: >Lars writes: >> > Put LABEL= in you fstab in place of the device name. >> >> Which is great, for filesystems that support labels. Unfortunately, >> this isn't universally available -- for instance, you cannot mount >> a swap partition by label or uuid, so it is not possible to completely >> isolate yourself from the problems of disk device renumbering. > >There is room for a LABEL and/or UUID in the swap superblock, if you >would want to implement support for this. Despair no more! I've implemented a patch for util-linux-2.11a which adds LABEL support to mkswap(8) and swapon/swapoff(8). - I shrunk the padding field in the new-style swap_header to make room for 16 bytes worth of volume label (same as ext2) - mkswap -L label also sets the volume label - swapon -L label looks for a swap partition with the given label (using a clone of mount(8)'s LABEL/UUID= support code) - swapon/swapoff -a also handles swap fstab entries where the device is specified as LABEL= The patch is available at http://www.csd.uu.se/~mikpe/linux/swap-label/ /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: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, 14 Mar 2001, Richard B. Johnson wrote: > This used to even be the way disks were located by the kernel > drivers. Now, these are found in some "random" order. > > If whatever is causing the "random" order was fixed, put back like > it used to be, etc., we wouldn't have these problems. Another alternative to path2inst or a database, I suppose, would be to use bus/pci slot information (like in /proc/pci?) to order multiple devices, so at least there's some consistency. You might have a serious headache, however, when adding a device, under that scheme. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, 14 Mar 2001, Richard B. Johnson wrote: This used to even be the way disks were located by the kernel drivers. Now, these are found in some "random" order. If whatever is causing the "random" order was fixed, put back like it used to be, etc., we wouldn't have these problems. Another alternative to path2inst or a database, I suppose, would be to use bus/pci slot information (like in /proc/pci?) to order multiple devices, so at least there's some consistency. You might have a serious headache, however, when adding a device, under that scheme. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, 14 Mar 2001 12:34:06 -0700 (MST), Andreas Dilger wrote in LKML: Lars writes: Put LABEL=label set with e2label in you fstab in place of the device name. Which is great, for filesystems that support labels. Unfortunately, this isn't universally available -- for instance, you cannot mount a swap partition by label or uuid, so it is not possible to completely isolate yourself from the problems of disk device renumbering. There is room for a LABEL and/or UUID in the swap superblock, if you would want to implement support for this. Despair no more! I've implemented a patch for util-linux-2.11a which adds LABEL support to mkswap(8) and swapon/swapoff(8). - I shrunk the padding field in the new-style swap_header to make room for 16 bytes worth of volume label (same as ext2) - mkswap -L label also sets the volume label - swapon -L label looks for a swap partition with the given label (using a clone of mount(8)'s LABEL/UUID= support code) - swapon/swapoff -a also handles swap fstab entries where the device is specified as LABEL=label The patch is available at http://www.csd.uu.se/~mikpe/linux/swap-label/ /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
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/
Re: magic device renumbering was -- Re: Linux 2.4.2ac20
Hi, The solution is not to go down the path2inst road, that is full of its own traps. You want volume labels via a volume manager (do lvm and raid already do this?) and/or filesystem labels (see e2fslabel). This won't solve all of the ills associated with device instance changes, but it will certainly address the biggest one. skd On Wed, Mar 14, 2001 at 10:36:40AM -0500, John Jasen wrote: > > The problem: > > drivers change their detection schemes; and changes in the kernel can > change the order in which devices are assigned names. > > For example, the DAC960(?) drivers changed their order of > detecting controllers, and I did _not_ have fun, given that the machine in > question had about 40 disks to deal with, spread across two controllers. > > This can create a lot of problems for people upgrading large, production > quality systems -- as, in the worst case, the system won't complete the > boot cycle; or in middle cases, the user/sysadmin is stuck rewriting X > amount of files and trying again; or in small cases, you find out that > your SMC and Intel ethernet cards are reversed, and have to go fix things > ... > > Possible solutions(?): > > Solaris uses an /etc/path_to_inst file, to keep track of device ordering, > et al. > > Maybe we should consider something similar, where a physical device to > logical device map is kept and used to keep things consistent on > kernel/driver changes; device addition/removal, and so forth ... > > I am, of course, open to better solutions. > > -- > -- John E. Jasen ([EMAIL PROTECTED]) > -- In theory, theory and practise are the same. In practise, they aren't. > > > - > 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/ - 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: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, Mar 14, 2001 at 05:53:16PM -0800, Tim Wright wrote: > Well, if it sounds useful, I can look into putting up the design documentation > (yes, shock, horror, there is some :-). It's pretty thorough and covers most > of the issues involved, and hence might be a good talking point, even if we > chose to implement quite differently. I'd be interested in seeing it, and I'm sure other developers would too. If you need a place to host it, I can offer a spot on the linux-hotplug sourceforge site for it. thanks, greg k-h -- greg@(kroah|wirex).com - 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: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, Mar 14, 2001 at 10:15:26AM -0800, Greg KH wrote: [My ramblings on device naming database deleted] > This comes up a lot with regards to USB devices too. One of the > usb-serial drivers (the edgeport driver) did something like this by > looking at the topology of the USB bus and where a specific device was > (it was also helped by unique serial numbers) and allowed the devices to > be assigned device nodes based on the topology and a small user space > program. I'm going to try to do this for all usb-serial devices in 2.5 > > I can see a scheme like this being very useful for all USB, FireWire, > scsi, etc type of devices. > > And no, I don't think that having some type of device naming "database" > is overkill and will eventually make it into parts of the kernel (the > "database" living outside of the kernel of course...) > Well, if it sounds useful, I can look into putting up the design documentation (yes, shock, horror, there is some :-). It's pretty thorough and covers most of the issues involved, and hence might be a good talking point, even if we chose to implement quite differently. Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - 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: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, 14 Mar 2001, Christoph Hellwig wrote: > In article <[EMAIL PROTECTED]> you >wrote: > > > The problem: > > > drivers change their detection schemes; and changes in the kernel can > > change the order in which devices are assigned names. > > > > For example, the DAC960(?) drivers changed their order of > > detecting controllers, and I did _not_ have fun, given that the machine in > > question had about 40 disks to deal with, spread across two controllers. > > Put LABEL= in you fstab in place of the device name. It solves the example, but not necessarily the problem. We're still left with partitions that don't do labels, attached tape devices, scsi controllers, NICs, and so forth. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, Mar 14, 2001 at 02:11:57PM -0500, Lars Kellogg-Stedman wrote: > > Put LABEL= in you fstab in place of the device name. > > Which is great, for filesystems that support labels. Unfortunately, > this isn't universally available -- for instance, you cannot mount > a swap partition by label or uuid, so it is not possible to completely > isolate yourself from the problems of disk device renumbering. True. Let's mark for 2.5 ToDO list: magic number for swap... Just because it does not work universally it doesn't have to be a bad idea... Christoph -- Of course it doesn't work. We've performed a software upgrade. - 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: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, 14 Mar 2001, Lars Kellogg-Stedman wrote: > > Put LABEL= in you fstab in place of the device name. > > Which is great, for filesystems that support labels. Unfortunately, > this isn't universally available -- for instance, you cannot mount > a swap partition by label or uuid, so it is not possible to completely > isolate yourself from the problems of disk device renumbering. > > -- Lars > > -- > Lars Kellogg-Stedman <[EMAIL PROTECTED]> > When my BIOS finds IDE disks, it starts at the lowest address of the port. It then looks for the first master, then the slave(s), etc. Then it tries the second, etc. When my SCSI BIOS finds disks, it starts at the first controller, the first LUN, the first drive, etc. This used to even be the way disks were located by the kernel drivers. Now, these are found in some "random" order. If whatever is causing the "random" order was fixed, put back like it used to be, etc., we wouldn't have these problems. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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: magic device renumbering was -- Re: Linux 2.4.2ac20
Lars writes: > > Put LABEL= in you fstab in place of the device name. > > Which is great, for filesystems that support labels. Unfortunately, > this isn't universally available -- for instance, you cannot mount > a swap partition by label or uuid, so it is not possible to completely > isolate yourself from the problems of disk device renumbering. There is room for a LABEL and/or UUID in the swap superblock, if you would want to implement support for this. I took a look once, and it should be possible to add in a compatible way. Of course, you can always put swap into LVM, which also makes it (along with filesystems other than ext2) immune from the nasty device name changes. 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: magic device renumbering was -- Re: Linux 2.4.2ac20
Christoph writes: > In article <[EMAIL PROTECTED]> you >wrote: > > drivers change their detection schemes; and changes in the kernel can > > change the order in which devices are assigned names. > > > > For example, the DAC960(?) drivers changed their order of > > detecting controllers, and I did _not_ have fun, given that the machine in > > question had about 40 disks to deal with, spread across two controllers. > > Put LABEL= in you fstab in place of the device name. > P.S. UUID= work, too - but I prefer a human-readable label... Works OK for ext2 only. I'm still waiting on the reiserfs folks to add a UUID and LABEL to their superblock. However, for raw partitions, you will need to use LVM to get rename-safe device labels. You probably want LVM anyways, if you have 40 disks... 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: magic device renumbering was -- Re: Linux 2.4.2ac20
> Put LABEL= in you fstab in place of the device name. Which is great, for filesystems that support labels. Unfortunately, this isn't universally available -- for instance, you cannot mount a swap partition by label or uuid, so it is not possible to completely isolate yourself from the problems of disk device renumbering. -- Lars -- Lars Kellogg-Stedman <[EMAIL PROTECTED]> - 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: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, 14 Mar 2001, Christoph Hellwig wrote: > Put LABEL= in you fstab in place of the device name. > > Christoph > > P.S. UUID= work, too - but I prefer a human-readable label... There are a lot of different devices besides disks, e.g. tape drives etc. I seem to remember from the last round this came up that modern FC fabrics have some dynamic properties that may require more intelligence in the kernel. Peter -- Peter Svensson ! Pgp key available by finger, fingerprint: <[EMAIL PROTECTED]>! 8A E9 20 98 C1 FF 43 E3 07 FD B9 0A 80 72 70 AF <[EMAIL PROTECTED]> ! Remember, Luke, your source will be with you... always... - 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: magic device renumbering was -- Re: Linux 2.4.2ac20
In article <[EMAIL PROTECTED]> you wrote: > The problem: > drivers change their detection schemes; and changes in the kernel can > change the order in which devices are assigned names. > > For example, the DAC960(?) drivers changed their order of > detecting controllers, and I did _not_ have fun, given that the machine in > question had about 40 disks to deal with, spread across two controllers. Put LABEL= in you fstab in place of the device name. Christoph P.S. UUID= work, too - but I prefer a human-readable label... -- Of course it doesn't work. We've performed a software upgrade. - 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: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, Mar 14, 2001 at 08:27:10AM -0800, Tim Wright wrote: > This would currently be massive overkill for Linux, but DYNIX/ptx avoids this > problem entirely by keeping a device naming database. This became necessary > when we added support for multi-path fibre-channel connected disks. Most > device-naming conventions rely on "physical" addresses i.e. this disk at the end > of this bus connected to this controller in this PCI slot is /dev/sdd. The > Solaris scheme mentioned above is no different in that respect. Unfortunately, > it doesn't work with multi-path FC-connected devices. > > Very briefly, devices that are "id-able" i.e. already have a unique id are > simply entered into the database (SCSI drives have a unique id that you can > read at autoconf time). For elements that are not "id-able", we establish > a derived id by recording their relation to "id-able" elements. At boot time, > we scan (in parallel) the system and compare what we find to the database. > That way, you get consistent naming for devices, and, at least in the case of > the SCSI (or FC) drives, the name doesn't change, even if you pull a drive > from one bus and plug it into a different bus entirely. This comes up a lot with regards to USB devices too. One of the usb-serial drivers (the edgeport driver) did something like this by looking at the topology of the USB bus and where a specific device was (it was also helped by unique serial numbers) and allowed the devices to be assigned device nodes based on the topology and a small user space program. I'm going to try to do this for all usb-serial devices in 2.5 I can see a scheme like this being very useful for all USB, FireWire, scsi, etc type of devices. And no, I don't think that having some type of device naming "database" is overkill and will eventually make it into parts of the kernel (the "database" living outside of the kernel of course...) greg k-h -- greg@(kroah|wirex).com - 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: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, Mar 14, 2001 at 10:36:40AM -0500, John Jasen wrote: > > The problem: > [ Device name slippage ] > > Possible solutions(?): > > Solaris uses an /etc/path_to_inst file, to keep track of device ordering, > et al. > > Maybe we should consider something similar, where a physical device to > logical device map is kept and used to keep things consistent on > kernel/driver changes; device addition/removal, and so forth ... > > I am, of course, open to better solutions. > This would currently be massive overkill for Linux, but DYNIX/ptx avoids this problem entirely by keeping a device naming database. This became necessary when we added support for multi-path fibre-channel connected disks. Most device-naming conventions rely on "physical" addresses i.e. this disk at the end of this bus connected to this controller in this PCI slot is /dev/sdd. The Solaris scheme mentioned above is no different in that respect. Unfortunately, it doesn't work with multi-path FC-connected devices. Very briefly, devices that are "id-able" i.e. already have a unique id are simply entered into the database (SCSI drives have a unique id that you can read at autoconf time). For elements that are not "id-able", we establish a derived id by recording their relation to "id-able" elements. At boot time, we scan (in parallel) the system and compare what we find to the database. That way, you get consistent naming for devices, and, at least in the case of the SCSI (or FC) drives, the name doesn't change, even if you pull a drive from one bus and plug it into a different bus entirely. As I say, this would be massive overkill for Linux, but it's a rather thorough solution :-) Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - 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/
magic device renumbering was -- Re: Linux 2.4.2ac20
The problem: drivers change their detection schemes; and changes in the kernel can change the order in which devices are assigned names. For example, the DAC960(?) drivers changed their order of detecting controllers, and I did _not_ have fun, given that the machine in question had about 40 disks to deal with, spread across two controllers. This can create a lot of problems for people upgrading large, production quality systems -- as, in the worst case, the system won't complete the boot cycle; or in middle cases, the user/sysadmin is stuck rewriting X amount of files and trying again; or in small cases, you find out that your SMC and Intel ethernet cards are reversed, and have to go fix things ... Possible solutions(?): Solaris uses an /etc/path_to_inst file, to keep track of device ordering, et al. Maybe we should consider something similar, where a physical device to logical device map is kept and used to keep things consistent on kernel/driver changes; device addition/removal, and so forth ... I am, of course, open to better solutions. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: Linux 2.4.2ac20
David Balazic wrote: > > Nathan Walp wrote: > > > > David Balazic wrote: > > > > > > Nathan Walp ([EMAIL PROTECTED]) wrote : > > > > > > > Also, sometime between ac7 and ac18 (spring break kept me from testing > > > > stuff inbetween), i assume during the new aic7xxx driver merge, the > > > > order of detection got changed, and now the ide-scsi virtual host is > > > > host0, and my 29160N is host1. Is this on purpose? It messed up a > > > > bunch of my stuff as far as /dev and such are concerned. > > > > > > SCSI adapters are enumerated randomly(*) , relying on certain numbering > > > will get you into trouble, sooner or later. > > > There is no commonly accepted solution, AFAIK. > > > The same thing can happent to disk enumeration ( sdb becomes sdc ) > > > or partition enumeration ( hda6 becomes hda5 ). > > > > > > * - theoreticaly no, but practicaly yes ( most of the time ) > > > > > > -- > > > David Balazic > > > -- > > > "Be excellent to each other." - Bill & Ted > > > - - - - - - - - - - - - - - - - - - - - - - > > > > SCSI adapters are given host numbers in a random order? Even with no > > hardware changes? Does this make less than sense to anyone else? Every > > kernel EVER up till now has had the real scsi cards (in some particular > > order) then ide-scsi. Have I just been lucky??? > > > > Nathan > > What I mean that too many factors are affecting the enumeration, > so that you can not rely on it : > > - kernel changes > - driver changes ( partly overlaps with the previous poit ) > - hardware changes > - something else ? > > There is no policy for this enumeration ( AFAIK ) , so there is > nothing to rely on , except luck :-) See, that all makes sense. You can't depend on hardware to detect in the same order, whether it's SCSI cards, network cards, or anything really. But the software psuedo-device that is ide-scsi, shouldn't that pick a spot before or after the hardware and stay there? That's my point, i guess. Nathan - 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: Linux 2.4.2ac20
Nathan Walp wrote: > > David Balazic wrote: > > > > Nathan Walp ([EMAIL PROTECTED]) wrote : > > > > > Also, sometime between ac7 and ac18 (spring break kept me from testing > > > stuff inbetween), i assume during the new aic7xxx driver merge, the > > > order of detection got changed, and now the ide-scsi virtual host is > > > host0, and my 29160N is host1. Is this on purpose? It messed up a > > > bunch of my stuff as far as /dev and such are concerned. > > > > SCSI adapters are enumerated randomly(*) , relying on certain numbering > > will get you into trouble, sooner or later. > > There is no commonly accepted solution, AFAIK. > > The same thing can happent to disk enumeration ( sdb becomes sdc ) > > or partition enumeration ( hda6 becomes hda5 ). > > > > * - theoreticaly no, but practicaly yes ( most of the time ) > > > > -- > > David Balazic > > -- > > "Be excellent to each other." - Bill & Ted > > - - - - - - - - - - - - - - - - - - - - - - > > SCSI adapters are given host numbers in a random order? Even with no > hardware changes? Does this make less than sense to anyone else? Every > kernel EVER up till now has had the real scsi cards (in some particular > order) then ide-scsi. Have I just been lucky??? > > Nathan What I mean that too many factors are affecting the enumeration, so that you can not rely on it : - kernel changes - driver changes ( partly overlaps with the previous poit ) - hardware changes - something else ? There is no policy for this enumeration ( AFAIK ) , so there is nothing to rely on , except luck :-) -- David Balazic -- "Be excellent to each other." - Bill & Ted - - - - - - - - - - - - - - - - - - - - - - - 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: Linux 2.4.2ac20
Nathan Walp wrote: David Balazic wrote: Nathan Walp ([EMAIL PROTECTED]) wrote : Also, sometime between ac7 and ac18 (spring break kept me from testing stuff inbetween), i assume during the new aic7xxx driver merge, the order of detection got changed, and now the ide-scsi virtual host is host0, and my 29160N is host1. Is this on purpose? It messed up a bunch of my stuff as far as /dev and such are concerned. SCSI adapters are enumerated randomly(*) , relying on certain numbering will get you into trouble, sooner or later. There is no commonly accepted solution, AFAIK. The same thing can happent to disk enumeration ( sdb becomes sdc ) or partition enumeration ( hda6 becomes hda5 ). * - theoreticaly no, but practicaly yes ( most of the time ) -- David Balazic -- "Be excellent to each other." - Bill Ted - - - - - - - - - - - - - - - - - - - - - - SCSI adapters are given host numbers in a random order? Even with no hardware changes? Does this make less than sense to anyone else? Every kernel EVER up till now has had the real scsi cards (in some particular order) then ide-scsi. Have I just been lucky??? Nathan What I mean that too many factors are affecting the enumeration, so that you can not rely on it : - kernel changes - driver changes ( partly overlaps with the previous poit ) - hardware changes - something else ? There is no policy for this enumeration ( AFAIK ) , so there is nothing to rely on , except luck :-) -- David Balazic -- "Be excellent to each other." - Bill Ted - - - - - - - - - - - - - - - - - - - - - - - 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: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, Mar 14, 2001 at 10:36:40AM -0500, John Jasen wrote: The problem: [ Device name slippage ] Possible solutions(?): Solaris uses an /etc/path_to_inst file, to keep track of device ordering, et al. Maybe we should consider something similar, where a physical device to logical device map is kept and used to keep things consistent on kernel/driver changes; device addition/removal, and so forth ... I am, of course, open to better solutions. This would currently be massive overkill for Linux, but DYNIX/ptx avoids this problem entirely by keeping a device naming database. This became necessary when we added support for multi-path fibre-channel connected disks. Most device-naming conventions rely on "physical" addresses i.e. this disk at the end of this bus connected to this controller in this PCI slot is /dev/sdd. The Solaris scheme mentioned above is no different in that respect. Unfortunately, it doesn't work with multi-path FC-connected devices. Very briefly, devices that are "id-able" i.e. already have a unique id are simply entered into the database (SCSI drives have a unique id that you can read at autoconf time). For elements that are not "id-able", we establish a derived id by recording their relation to "id-able" elements. At boot time, we scan (in parallel) the system and compare what we find to the database. That way, you get consistent naming for devices, and, at least in the case of the SCSI (or FC) drives, the name doesn't change, even if you pull a drive from one bus and plug it into a different bus entirely. As I say, this would be massive overkill for Linux, but it's a rather thorough solution :-) Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - 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: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, Mar 14, 2001 at 08:27:10AM -0800, Tim Wright wrote: This would currently be massive overkill for Linux, but DYNIX/ptx avoids this problem entirely by keeping a device naming database. This became necessary when we added support for multi-path fibre-channel connected disks. Most device-naming conventions rely on "physical" addresses i.e. this disk at the end of this bus connected to this controller in this PCI slot is /dev/sdd. The Solaris scheme mentioned above is no different in that respect. Unfortunately, it doesn't work with multi-path FC-connected devices. Very briefly, devices that are "id-able" i.e. already have a unique id are simply entered into the database (SCSI drives have a unique id that you can read at autoconf time). For elements that are not "id-able", we establish a derived id by recording their relation to "id-able" elements. At boot time, we scan (in parallel) the system and compare what we find to the database. That way, you get consistent naming for devices, and, at least in the case of the SCSI (or FC) drives, the name doesn't change, even if you pull a drive from one bus and plug it into a different bus entirely. This comes up a lot with regards to USB devices too. One of the usb-serial drivers (the edgeport driver) did something like this by looking at the topology of the USB bus and where a specific device was (it was also helped by unique serial numbers) and allowed the devices to be assigned device nodes based on the topology and a small user space program. I'm going to try to do this for all usb-serial devices in 2.5 I can see a scheme like this being very useful for all USB, FireWire, scsi, etc type of devices. And no, I don't think that having some type of device naming "database" is overkill and will eventually make it into parts of the kernel (the "database" living outside of the kernel of course...) greg k-h -- greg@(kroah|wirex).com - 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: magic device renumbering was -- Re: Linux 2.4.2ac20
In article [EMAIL PROTECTED] you wrote: The problem: drivers change their detection schemes; and changes in the kernel can change the order in which devices are assigned names. For example, the DAC960(?) drivers changed their order of detecting controllers, and I did _not_ have fun, given that the machine in question had about 40 disks to deal with, spread across two controllers. Put LABEL=label set with e2label in you fstab in place of the device name. Christoph P.S. UUID= work, too - but I prefer a human-readable label... -- Of course it doesn't work. We've performed a software upgrade. - 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: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, 14 Mar 2001, Christoph Hellwig wrote: Put LABEL=label set with e2label in you fstab in place of the device name. Christoph P.S. UUID= work, too - but I prefer a human-readable label... There are a lot of different devices besides disks, e.g. tape drives etc. I seem to remember from the last round this came up that modern FC fabrics have some dynamic properties that may require more intelligence in the kernel. Peter -- Peter Svensson ! Pgp key available by finger, fingerprint: [EMAIL PROTECTED]! 8A E9 20 98 C1 FF 43 E3 07 FD B9 0A 80 72 70 AF [EMAIL PROTECTED] ! Remember, Luke, your source will be with you... always... - 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: magic device renumbering was -- Re: Linux 2.4.2ac20
Put LABEL=label set with e2label in you fstab in place of the device name. Which is great, for filesystems that support labels. Unfortunately, this isn't universally available -- for instance, you cannot mount a swap partition by label or uuid, so it is not possible to completely isolate yourself from the problems of disk device renumbering. -- Lars -- Lars Kellogg-Stedman [EMAIL PROTECTED] - 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: magic device renumbering was -- Re: Linux 2.4.2ac20
Christoph writes: In article [EMAIL PROTECTED] you wrote: drivers change their detection schemes; and changes in the kernel can change the order in which devices are assigned names. For example, the DAC960(?) drivers changed their order of detecting controllers, and I did _not_ have fun, given that the machine in question had about 40 disks to deal with, spread across two controllers. Put LABEL=label set with e2label in you fstab in place of the device name. P.S. UUID= work, too - but I prefer a human-readable label... Works OK for ext2 only. I'm still waiting on the reiserfs folks to add a UUID and LABEL to their superblock. However, for raw partitions, you will need to use LVM to get rename-safe device labels. You probably want LVM anyways, if you have 40 disks... 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: magic device renumbering was -- Re: Linux 2.4.2ac20
Lars writes: Put LABEL=label set with e2label in you fstab in place of the device name. Which is great, for filesystems that support labels. Unfortunately, this isn't universally available -- for instance, you cannot mount a swap partition by label or uuid, so it is not possible to completely isolate yourself from the problems of disk device renumbering. There is room for a LABEL and/or UUID in the swap superblock, if you would want to implement support for this. I took a look once, and it should be possible to add in a compatible way. Of course, you can always put swap into LVM, which also makes it (along with filesystems other than ext2) immune from the nasty device name changes. 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: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, 14 Mar 2001, Lars Kellogg-Stedman wrote: Put LABEL=label set with e2label in you fstab in place of the device name. Which is great, for filesystems that support labels. Unfortunately, this isn't universally available -- for instance, you cannot mount a swap partition by label or uuid, so it is not possible to completely isolate yourself from the problems of disk device renumbering. -- Lars -- Lars Kellogg-Stedman [EMAIL PROTECTED] When my BIOS finds IDE disks, it starts at the lowest address of the port. It then looks for the first master, then the slave(s), etc. Then it tries the second, etc. When my SCSI BIOS finds disks, it starts at the first controller, the first LUN, the first drive, etc. This used to even be the way disks were located by the kernel drivers. Now, these are found in some "random" order. If whatever is causing the "random" order was fixed, put back like it used to be, etc., we wouldn't have these problems. Cheers, Dick Johnson Penguin : Linux version 2.4.1 on an i686 machine (799.53 BogoMips). "Memory is like gasoline. You use it up when you are running. Of course you get it all back when you reboot..."; Actual explanation obtained from the Micro$oft help desk. - 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: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, Mar 14, 2001 at 02:11:57PM -0500, Lars Kellogg-Stedman wrote: Put LABEL=label set with e2label in you fstab in place of the device name. Which is great, for filesystems that support labels. Unfortunately, this isn't universally available -- for instance, you cannot mount a swap partition by label or uuid, so it is not possible to completely isolate yourself from the problems of disk device renumbering. True. Let's mark for 2.5 ToDO list: magic number for swap... Just because it does not work universally it doesn't have to be a bad idea... Christoph -- Of course it doesn't work. We've performed a software upgrade. - 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: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, 14 Mar 2001, Christoph Hellwig wrote: In article [EMAIL PROTECTED] you wrote: The problem: drivers change their detection schemes; and changes in the kernel can change the order in which devices are assigned names. For example, the DAC960(?) drivers changed their order of detecting controllers, and I did _not_ have fun, given that the machine in question had about 40 disks to deal with, spread across two controllers. Put LABEL=label set with e2label in you fstab in place of the device name. It solves the example, but not necessarily the problem. We're still left with partitions that don't do labels, attached tape devices, scsi controllers, NICs, and so forth. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, Mar 14, 2001 at 10:15:26AM -0800, Greg KH wrote: [My ramblings on device naming database deleted] This comes up a lot with regards to USB devices too. One of the usb-serial drivers (the edgeport driver) did something like this by looking at the topology of the USB bus and where a specific device was (it was also helped by unique serial numbers) and allowed the devices to be assigned device nodes based on the topology and a small user space program. I'm going to try to do this for all usb-serial devices in 2.5 I can see a scheme like this being very useful for all USB, FireWire, scsi, etc type of devices. And no, I don't think that having some type of device naming "database" is overkill and will eventually make it into parts of the kernel (the "database" living outside of the kernel of course...) Well, if it sounds useful, I can look into putting up the design documentation (yes, shock, horror, there is some :-). It's pretty thorough and covers most of the issues involved, and hence might be a good talking point, even if we chose to implement quite differently. Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - 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: magic device renumbering was -- Re: Linux 2.4.2ac20
On Wed, Mar 14, 2001 at 05:53:16PM -0800, Tim Wright wrote: Well, if it sounds useful, I can look into putting up the design documentation (yes, shock, horror, there is some :-). It's pretty thorough and covers most of the issues involved, and hence might be a good talking point, even if we chose to implement quite differently. I'd be interested in seeing it, and I'm sure other developers would too. If you need a place to host it, I can offer a spot on the linux-hotplug sourceforge site for it. thanks, greg k-h -- greg@(kroah|wirex).com - 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: magic device renumbering was -- Re: Linux 2.4.2ac20
Hi, The solution is not to go down the path2inst road, that is full of its own traps. You want volume labels via a volume manager (do lvm and raid already do this?) and/or filesystem labels (see e2fslabel). This won't solve all of the ills associated with device instance changes, but it will certainly address the biggest one. skd On Wed, Mar 14, 2001 at 10:36:40AM -0500, John Jasen wrote: The problem: drivers change their detection schemes; and changes in the kernel can change the order in which devices are assigned names. For example, the DAC960(?) drivers changed their order of detecting controllers, and I did _not_ have fun, given that the machine in question had about 40 disks to deal with, spread across two controllers. This can create a lot of problems for people upgrading large, production quality systems -- as, in the worst case, the system won't complete the boot cycle; or in middle cases, the user/sysadmin is stuck rewriting X amount of files and trying again; or in small cases, you find out that your SMC and Intel ethernet cards are reversed, and have to go fix things ... Possible solutions(?): Solaris uses an /etc/path_to_inst file, to keep track of device ordering, et al. Maybe we should consider something similar, where a physical device to logical device map is kept and used to keep things consistent on kernel/driver changes; device addition/removal, and so forth ... I am, of course, open to better solutions. -- -- John E. Jasen ([EMAIL PROTECTED]) -- In theory, theory and practise are the same. In practise, they aren't. - 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/ - 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: Linux 2.4.2ac20
> David Balazic wrote: > > > > Nathan Walp ([EMAIL PROTECTED]) wrote : > > > > > Also, sometime between ac7 and ac18 (spring break kept me from testing > > > stuff inbetween), i assume during the new aic7xxx driver merge, the > > > order of detection got changed, and now the ide-scsi virtual host is > > > host0, and my 29160N is host1. Is this on purpose? It messed up a > > > bunch of my stuff as far as /dev and such are concerned. > > > > SCSI adapters are enumerated randomly(*) , relying on certain numbering > > will get you into trouble, sooner or later. > > There is no commonly accepted solution, AFAIK. > > The same thing can happent to disk enumeration ( sdb becomes sdc ) > > or partition enumeration ( hda6 becomes hda5 ). > > > > * - theoreticaly no, but practicaly yes ( most of the time ) > > SCSI adapters are given host numbers in a random order? Even with no > hardware changes? Does this make less than sense to anyone else? Every > kernel EVER up till now has had the real scsi cards (in some particular > order) then ide-scsi. Have I just been lucky??? Built in scsi adapter drivers are probed in the order in which they appear in drivers/scsi/Makefile (in the lk 2.4 series). Adapters can be assigned to host numbers using the "scsihosts" kernel boot option (but this will not differentiate between 2 adapters controlled by the same driver (e.g. 2 29160 cards)). Scsi buses are scanned for devices in ascending order. If you have lots of SCSI devices then devfs is your friend. Doug Gilbert - 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: Linux 2.4.2ac20
I've just noticed with 2.4.2-ac20 that /proc/sys/fs/binfmt_misc is no longer being created. I have CONFIG_BINFMT_MISC=y in my .config. This was working fine in 2.4.3-pre4. Wayne - 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: Linux 2.4.2ac20
Michal Jaegermann wrote: > > On Tue, Mar 13, 2001 at 04:36:18AM +, Alan Cox wrote: > ... > > > > 2.4.2-ac20 > ... > > o Fix Alpha build (Jeff Garzik) > > Now I see (at least on Alpha) a constant wailing: > > /linux-2.4.2ac/include/linux/binfmts.h:45: warning: `struct > mm_struct' declared inside parameter list > /linux-2.4.2ac/include/linux/binfmts.h:45: warning: its scope is > only this definition or declaration, which is probably not what you want > > Is this somehow related? Nope, I saw that before the patch. My patch was, in any case, to a single .c file, not a header file, so it wouldn't spew like that. It compiled and booted, I moved on :) So solve that warning you probably need to shuffle the delicate balance of includes around so that linux/sched.h, where mm_struct is defined, is included before binfmts.h. Or have binfmt.h include sched.h (which should work... but its all kinds of nested nastiness) -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - 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: Linux 2.4.2ac20
On Tue, Mar 13, 2001 at 04:36:18AM +, Alan Cox wrote: ... > > 2.4.2-ac20 ... > o Fix Alpha build (Jeff Garzik) Now I see (at least on Alpha) a constant wailing: /linux-2.4.2ac/include/linux/binfmts.h:45: warning: `struct mm_struct' declared inside parameter list /linux-2.4.2ac/include/linux/binfmts.h:45: warning: its scope is only this definition or declaration, which is probably not what you want Is this somehow related? Michal - 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: Linux 2.4.2ac20
On Tue, Mar 13, 2001 at 02:24:54PM -0500, Nathan Walp wrote: > David Balazic wrote: > > > > SCSI adapters are enumerated randomly(*) , relying on certain numbering > > will get you into trouble, sooner or later. > > There is no commonly accepted solution, AFAIK. > > The same thing can happent to disk enumeration ( sdb becomes sdc ) > > or partition enumeration ( hda6 becomes hda5 ). > > > > * - theoreticaly no, but practicaly yes ( most of the time ) > > SCSI adapters are given host numbers in a random order? Even with no > hardware changes? Does this make less than sense to anyone else? Every > kernel EVER up till now has had the real scsi cards (in some particular > order) then ide-scsi. Have I just been lucky??? > No, it's not truly random. That would be insane. And, no, if you don't change the kernel or the hardware, then they won't jump around. But, yes, if you change the hardware, or someone changes the probe order in the kernel, you can suffer from device name slippage. This is a minor problem on a small home system, and a massive PITA on a large server. You can at least mandate the probe order on a 2.4 system (see the scsihosts parameter). Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - 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: Linux 2.4.2ac20
David Balazic wrote: > > Nathan Walp ([EMAIL PROTECTED]) wrote : > > > Also, sometime between ac7 and ac18 (spring break kept me from testing > > stuff inbetween), i assume during the new aic7xxx driver merge, the > > order of detection got changed, and now the ide-scsi virtual host is > > host0, and my 29160N is host1. Is this on purpose? It messed up a > > bunch of my stuff as far as /dev and such are concerned. > > SCSI adapters are enumerated randomly(*) , relying on certain numbering > will get you into trouble, sooner or later. > There is no commonly accepted solution, AFAIK. > The same thing can happent to disk enumeration ( sdb becomes sdc ) > or partition enumeration ( hda6 becomes hda5 ). > > * - theoreticaly no, but practicaly yes ( most of the time ) > > -- > David Balazic > -- > "Be excellent to each other." - Bill & Ted > - - - - - - - - - - - - - - - - - - - - - - SCSI adapters are given host numbers in a random order? Even with no hardware changes? Does this make less than sense to anyone else? Every kernel EVER up till now has had the real scsi cards (in some particular order) then ide-scsi. Have I just been lucky??? Nathan - 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: Linux 2.4.2ac20
Nathan Walp ([EMAIL PROTECTED]) wrote : > Also, sometime between ac7 and ac18 (spring break kept me from testing > stuff inbetween), i assume during the new aic7xxx driver merge, the > order of detection got changed, and now the ide-scsi virtual host is > host0, and my 29160N is host1. Is this on purpose? It messed up a > bunch of my stuff as far as /dev and such are concerned. SCSI adapters are enumerated randomly(*) , relying on certain numbering will get you into trouble, sooner or later. There is no commonly accepted solution, AFAIK. The same thing can happent to disk enumeration ( sdb becomes sdc ) or partition enumeration ( hda6 becomes hda5 ). * - theoreticaly no, but practicaly yes ( most of the time ) -- David Balazic -- "Be excellent to each other." - Bill & Ted - - - - - - - - - - - - - - - - - - - - - - - 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: Linux 2.4.2ac20
Nathan Walp ([EMAIL PROTECTED]) wrote : Also, sometime between ac7 and ac18 (spring break kept me from testing stuff inbetween), i assume during the new aic7xxx driver merge, the order of detection got changed, and now the ide-scsi virtual host is host0, and my 29160N is host1. Is this on purpose? It messed up a bunch of my stuff as far as /dev and such are concerned. SCSI adapters are enumerated randomly(*) , relying on certain numbering will get you into trouble, sooner or later. There is no commonly accepted solution, AFAIK. The same thing can happent to disk enumeration ( sdb becomes sdc ) or partition enumeration ( hda6 becomes hda5 ). * - theoreticaly no, but practicaly yes ( most of the time ) -- David Balazic -- "Be excellent to each other." - Bill Ted - - - - - - - - - - - - - - - - - - - - - - - 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: Linux 2.4.2ac20
David Balazic wrote: Nathan Walp ([EMAIL PROTECTED]) wrote : Also, sometime between ac7 and ac18 (spring break kept me from testing stuff inbetween), i assume during the new aic7xxx driver merge, the order of detection got changed, and now the ide-scsi virtual host is host0, and my 29160N is host1. Is this on purpose? It messed up a bunch of my stuff as far as /dev and such are concerned. SCSI adapters are enumerated randomly(*) , relying on certain numbering will get you into trouble, sooner or later. There is no commonly accepted solution, AFAIK. The same thing can happent to disk enumeration ( sdb becomes sdc ) or partition enumeration ( hda6 becomes hda5 ). * - theoreticaly no, but practicaly yes ( most of the time ) -- David Balazic -- "Be excellent to each other." - Bill Ted - - - - - - - - - - - - - - - - - - - - - - SCSI adapters are given host numbers in a random order? Even with no hardware changes? Does this make less than sense to anyone else? Every kernel EVER up till now has had the real scsi cards (in some particular order) then ide-scsi. Have I just been lucky??? Nathan - 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: Linux 2.4.2ac20
On Tue, Mar 13, 2001 at 02:24:54PM -0500, Nathan Walp wrote: David Balazic wrote: SCSI adapters are enumerated randomly(*) , relying on certain numbering will get you into trouble, sooner or later. There is no commonly accepted solution, AFAIK. The same thing can happent to disk enumeration ( sdb becomes sdc ) or partition enumeration ( hda6 becomes hda5 ). * - theoreticaly no, but practicaly yes ( most of the time ) SCSI adapters are given host numbers in a random order? Even with no hardware changes? Does this make less than sense to anyone else? Every kernel EVER up till now has had the real scsi cards (in some particular order) then ide-scsi. Have I just been lucky??? No, it's not truly random. That would be insane. And, no, if you don't change the kernel or the hardware, then they won't jump around. But, yes, if you change the hardware, or someone changes the probe order in the kernel, you can suffer from device name slippage. This is a minor problem on a small home system, and a massive PITA on a large server. You can at least mandate the probe order on a 2.4 system (see the scsihosts parameter). Tim -- Tim Wright - [EMAIL PROTECTED] or [EMAIL PROTECTED] or [EMAIL PROTECTED] IBM Linux Technology Center, Beaverton, Oregon Interested in Linux scalability ? Look at http://lse.sourceforge.net/ "Nobody ever said I was charming, they said "Rimmer, you're a git!"" RD VI - 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: Linux 2.4.2ac20
On Tue, Mar 13, 2001 at 04:36:18AM +, Alan Cox wrote: ... 2.4.2-ac20 ... o Fix Alpha build (Jeff Garzik) Now I see (at least on Alpha) a constant wailing: /linux-2.4.2ac/include/linux/binfmts.h:45: warning: `struct mm_struct' declared inside parameter list /linux-2.4.2ac/include/linux/binfmts.h:45: warning: its scope is only this definition or declaration, which is probably not what you want Is this somehow related? Michal - 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: Linux 2.4.2ac20
Michal Jaegermann wrote: On Tue, Mar 13, 2001 at 04:36:18AM +, Alan Cox wrote: ... 2.4.2-ac20 ... o Fix Alpha build (Jeff Garzik) Now I see (at least on Alpha) a constant wailing: /linux-2.4.2ac/include/linux/binfmts.h:45: warning: `struct mm_struct' declared inside parameter list /linux-2.4.2ac/include/linux/binfmts.h:45: warning: its scope is only this definition or declaration, which is probably not what you want Is this somehow related? Nope, I saw that before the patch. My patch was, in any case, to a single .c file, not a header file, so it wouldn't spew like that. It compiled and booted, I moved on :) So solve that warning you probably need to shuffle the delicate balance of includes around so that linux/sched.h, where mm_struct is defined, is included before binfmts.h. Or have binfmt.h include sched.h (which should work... but its all kinds of nested nastiness) -- Jeff Garzik | May you have warm words on a cold evening, Building 1024 | a full mooon on a dark night, MandrakeSoft | and a smooth road all the way to your door. - 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: Linux 2.4.2ac20
I've just noticed with 2.4.2-ac20 that /proc/sys/fs/binfmt_misc is no longer being created. I have CONFIG_BINFMT_MISC=y in my .config. This was working fine in 2.4.3-pre4. Wayne - 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: Linux 2.4.2ac20
David Balazic wrote: Nathan Walp ([EMAIL PROTECTED]) wrote : Also, sometime between ac7 and ac18 (spring break kept me from testing stuff inbetween), i assume during the new aic7xxx driver merge, the order of detection got changed, and now the ide-scsi virtual host is host0, and my 29160N is host1. Is this on purpose? It messed up a bunch of my stuff as far as /dev and such are concerned. SCSI adapters are enumerated randomly(*) , relying on certain numbering will get you into trouble, sooner or later. There is no commonly accepted solution, AFAIK. The same thing can happent to disk enumeration ( sdb becomes sdc ) or partition enumeration ( hda6 becomes hda5 ). * - theoreticaly no, but practicaly yes ( most of the time ) SCSI adapters are given host numbers in a random order? Even with no hardware changes? Does this make less than sense to anyone else? Every kernel EVER up till now has had the real scsi cards (in some particular order) then ide-scsi. Have I just been lucky??? Built in scsi adapter drivers are probed in the order in which they appear in drivers/scsi/Makefile (in the lk 2.4 series). Adapters can be assigned to host numbers using the "scsihosts" kernel boot option (but this will not differentiate between 2 adapters controlled by the same driver (e.g. 2 29160 cards)). Scsi buses are scanned for devices in ascending order. If you have lots of SCSI devices then devfs is your friend. Doug Gilbert - 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: Linux 2.4.2ac20
Alan Cox wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/alan/3.4/ > > Intermediate diffs are available from > > http://www.bzimage.org > > (Note that the cmsfs port to 2.4 is a work in progress) > > Its now 2767631 bytes .gz but a fair amount of stuff has gone to Linus so > if you redo the diff versus 2.4.3pre4 it looks a lot nicer 8) > > 2.4.2-ac20 > o Add support for the GoHubs GO-COM232(Greg Kroah-Hartman) > o Remove cobalt remnants (Ralf Baechle) > o First block of mm documentation (Rik van Riel) > o Replace ancient Zoran driver with new one (Serguei Miridonov, > Wolfgang Scherr, Rainer Johanni, Dave Perks) > o Fix Alpha build (Jeff Garzik) > o Fix K7 mtrr breakage(Dave Jones) > o Fix pcnet32 touching resources before enable(Dave Jones) > o Merge with Linus 2.4.3pre4 Debian sid (unstable). ac18 compiled fine. ac20, i got this: gcc -I/usr/include -ldb aicasm_gram.c aicasm_scan.c aicasm.c aicasm_symbol.c -o aicasm aicasm/aicasm_gram.y:45: ../queue.h: No such file or directory aicasm/aicasm_gram.y:50: aicasm.h: No such file or directory aicasm/aicasm_gram.y:51: aicasm_symbol.h: No such file or directory aicasm/aicasm_gram.y:52: aicasm_insformat.h: No such file or directory aicasm/aicasm_scan.l:44: ../queue.h: No such file or directory aicasm/aicasm_scan.l:49: aicasm.h: No such file or directory aicasm/aicasm_scan.l:50: aicasm_symbol.h: No such file or directory aicasm/aicasm_scan.l:51: y.tab.h: No such file or directory make[5]: *** [aicasm] Error 1 make[5]: Leaving directory `/usr/src/linux-2.4.2-ac20/drivers/scsi/aic7xxx/aicasm' make[4]: *** [aicasm/aicasm] Error 2 make[4]: Leaving directory `/usr/src/linux-2.4.2-ac20/drivers/scsi/aic7xxx' make[3]: *** [first_rule] Error 2 make[3]: Leaving directory `/usr/src/linux-2.4.2-ac20/drivers/scsi/aic7xxx' make[2]: *** [_subdir_aic7xxx] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4.2-ac20/drivers/scsi' make[1]: *** [_subdir_scsi] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.2-ac20/drivers' make: *** [_dir_drivers] Error 2 patience:/usr/src/linux# Also, sometime between ac7 and ac18 (spring break kept me from testing stuff inbetween), i assume during the new aic7xxx driver merge, the order of detection got changed, and now the ide-scsi virtual host is host0, and my 29160N is host1. Is this on purpose? It messed up a bunch of my stuff as far as /dev and such are concerned. Thanks, Nathan - 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: Linux 2.4.2ac20
Alan Cox wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/alan/3.4/ Intermediate diffs are available from http://www.bzimage.org (Note that the cmsfs port to 2.4 is a work in progress) Its now 2767631 bytes .gz but a fair amount of stuff has gone to Linus so if you redo the diff versus 2.4.3pre4 it looks a lot nicer 8) 2.4.2-ac20 o Add support for the GoHubs GO-COM232(Greg Kroah-Hartman) o Remove cobalt remnants (Ralf Baechle) o First block of mm documentation (Rik van Riel) o Replace ancient Zoran driver with new one (Serguei Miridonov, Wolfgang Scherr, Rainer Johanni, Dave Perks) o Fix Alpha build (Jeff Garzik) o Fix K7 mtrr breakage(Dave Jones) o Fix pcnet32 touching resources before enable(Dave Jones) o Merge with Linus 2.4.3pre4 Debian sid (unstable). ac18 compiled fine. ac20, i got this: gcc -I/usr/include -ldb aicasm_gram.c aicasm_scan.c aicasm.c aicasm_symbol.c -o aicasm aicasm/aicasm_gram.y:45: ../queue.h: No such file or directory aicasm/aicasm_gram.y:50: aicasm.h: No such file or directory aicasm/aicasm_gram.y:51: aicasm_symbol.h: No such file or directory aicasm/aicasm_gram.y:52: aicasm_insformat.h: No such file or directory aicasm/aicasm_scan.l:44: ../queue.h: No such file or directory aicasm/aicasm_scan.l:49: aicasm.h: No such file or directory aicasm/aicasm_scan.l:50: aicasm_symbol.h: No such file or directory aicasm/aicasm_scan.l:51: y.tab.h: No such file or directory make[5]: *** [aicasm] Error 1 make[5]: Leaving directory `/usr/src/linux-2.4.2-ac20/drivers/scsi/aic7xxx/aicasm' make[4]: *** [aicasm/aicasm] Error 2 make[4]: Leaving directory `/usr/src/linux-2.4.2-ac20/drivers/scsi/aic7xxx' make[3]: *** [first_rule] Error 2 make[3]: Leaving directory `/usr/src/linux-2.4.2-ac20/drivers/scsi/aic7xxx' make[2]: *** [_subdir_aic7xxx] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4.2-ac20/drivers/scsi' make[1]: *** [_subdir_scsi] Error 2 make[1]: Leaving directory `/usr/src/linux-2.4.2-ac20/drivers' make: *** [_dir_drivers] Error 2 patience:/usr/src/linux# Also, sometime between ac7 and ac18 (spring break kept me from testing stuff inbetween), i assume during the new aic7xxx driver merge, the order of detection got changed, and now the ide-scsi virtual host is host0, and my 29160N is host1. Is this on purpose? It messed up a bunch of my stuff as far as /dev and such are concerned. Thanks, Nathan - 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/
