Re: Antwort: Max number of dasd devices
Hi John, no one every pointed that out to me before I just looked it up and according to the docs your right it does the job. I need to try this but I assume one could do the following: dasdfmt -l cdl . fdasd -a . mkreiserfs -l label_for_vol1 .. mount -L label_for_vol1 . or place it in the fstab for a mount -a: LABEL=label_for_vol1 Much or the doc refers to e2fs and e3fs and xfs, although mkreiserfs supports a label keyword - do you know if this works OK with reiserfs on SuSE SLES-7 s390 and/or s390x? Thanks again for the education ;-) Ciao Mark -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of John Summerfield Sent: 15 October 2002 23:22 To: [EMAIL PROTECTED] Subject: Re: Antwort: Max number of dasd devices On Tue, 15 Oct 2002, Mark Perry wrote: I've been trying to understand the headache that Jim mentions relating to the lack of devfs support in SuSE zinux. All that devfs buys you is the ability to refer to the device address rather than some drive letter in non-devfs, and the fact that drive letters get reallocated when device addresses are removed and/or added. Thus the real issue is being able to use an fstab that contains specific device addresses rather than drive letters, right? Is there a problem filesystem labels cannot solve? -- Cheers John. Please, no off-list mail. You will fall foul of my spam treatment. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: Antwort: Max number of dasd devices
Hello again, it now occurs to me why I had never used FS Labels. FS Labels can't be used for the root FS, and in our environment every other DASD/partition is placed under LVM control. LVM also solves the same problem, it doesn't matter what the DASD drive letter may be vgscan locates it, and the fstab simply contains /dev/VGNAME/xxx and is thus DASD drive letter independent. It would seem to me that LVM is really the way to go to avoid the headaches Jim spoke of earlier, as it also allows FS's to span DASD too giving 3390-x model independence (plus stripping etc.). The floor is now open to comments ;-) Ciao Mark -Original Message- From: Mark Perry Sent: 16 October 2002 09:28 To: Linux on 390 Port Subject: RE: Antwort: Max number of dasd devices Hi John, no one every pointed that out to me before I just looked it up and according to the docs your right it does the job. I need to try this but I assume one could do the following: dasdfmt -l cdl . fdasd -a . mkreiserfs -l label_for_vol1 .. mount -L label_for_vol1 . or place it in the fstab for a mount -a: LABEL=label_for_vol1 Much or the doc refers to e2fs and e3fs and xfs, although mkreiserfs supports a label keyword - do you know if this works OK with reiserfs on SuSE SLES-7 s390 and/or s390x? Thanks again for the education ;-) Ciao Mark -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of John Summerfield Sent: 15 October 2002 23:22 To: [EMAIL PROTECTED] Subject: Re: Antwort: Max number of dasd devices On Tue, 15 Oct 2002, Mark Perry wrote: I've been trying to understand the headache that Jim mentions relating to the lack of devfs support in SuSE zinux. All that devfs buys you is the ability to refer to the device address rather than some drive letter in non-devfs, and the fact that drive letters get reallocated when device addresses are removed and/or added. Thus the real issue is being able to use an fstab that contains specific device addresses rather than drive letters, right? Is there a problem filesystem labels cannot solve? -- Cheers John. Please, no off-list mail. You will fall foul of my spam treatment. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: Antwort: Max number of dasd devices
At 10:04 16-10-02, Mark Perry wrote: It would seem to me that LVM is really the way to go to avoid the headaches Jim spoke of earlier, as it also allows FS's to span DASD too giving 3390-x model independence (plus stripping etc.). ... maybe the way to go, but not very far I believe ... When I have understood the discussion on LKM correctly then LVM is not going to be around for long anymore. There seems to be growing interest in ESVM now.
Re: Antwort: Max number of dasd devices
At 11:06 14-10-02 +0100, Malcolm Beattie wrote: For the userland issue, I've often wondered why someone hasn't done a version of scsidev for z/Linux (presumably dasddev would be the obvious name). It would simply go look at all the DASD information available via /proc/dasd/devices, /proc/partitions, query all the volumes for their volsers and build up a set of nodes and symlinks You probably don't want to go out and probe all DASD devices but restrict yourself to a specified subset. This even makese sense in a virtual machine because it is cumbersome to require peopel to detach all devices before starting Linux. For those who run in LPAR it would be unwise to refer to device addresses in their /etc/fstab and such. In a virtual machine you can normally re-arrange the addresses to match whatever you have in your files, and it may be annoying to require unique volsers within the virtual machine. The label would be attractive if it were not so confusing with the label-per-partition used in other areas. When in doubt, ask for both ;-) Rob
Re: Antwort: Max number of dasd devices
I've been trying to understand the headache that Jim mentions relating to the lack of devfs support in SuSE zinux. All that devfs buys you is the ability to refer to the device address rather than some drive letter in non-devfs, and the fact that drive letters get reallocated when device addresses are removed and/or added. Thus the real issue is being able to use an fstab that contains specific device addresses rather than drive letters, right? If I were in the position of managing 40 linux LPARs and needed something similar to devfs I would probably resort to scripting my own /etc/fstab before the mount -a(s) were issued in the boot scripts. All such a personal script would need to do would be to use /proc/dasd/devices and /proc/partitions and some pseudo fstab as input (maybe one that assumed devfs for syntax), then substitute the device numbers and partition numbers in it with /dev/dasda1 etc. Of course this assumes you need to run on every boot, if it's just a matter of producing the non-devfs fstab once in a while when the dasd configuration changes it becomes basic sysadmin work ;-) Not trivial, but not rocket science either (contracts always available) Ciao Mark -Original Message- From: Linux on 390 Port [mailto:[EMAIL PROTECTED]]On Behalf Of John Summerfield Sent: 15 October 2002 03:30 To: [EMAIL PROTECTED] Subject: Re: Antwort: Max number of dasd devices On Tue, 15 Oct 2002 08:51, you wrote: Just as I thought - Linux is more interested in some notion of cleanliness rather than real user problems! devfs has already been coded and is available for zSeries users who need some relief. I've been struggling with this idiotic dev node system for 2 years on up to 40 linux LPARS and I can tell you from hard experience that niceness and what might happen in the future hasn't been the least bit of help in dealing with several thousands devices. Excuse the frankness but the linux solution is neither clean or easy to use IMNSHO. The net effect of this linux approach, in reality, is that all machines should look like a PCs rather than Linux being flexible enough to provide special solutions for special problems. Why don't you put the question to your Linux vendor? I have heard that devfs isn't all it was hoped to be and the RH will not support it, that something better is coming. Unfortunately, I can't recall anything specific. Perhaps Alan can enlighten us, or tell be I've been enjoying forbidden substances. I do have the impression the SCSI world is going from bananas to worse; I hot-plugged in a Firewire drive and it came up at /dev/sda, and apparently USB cameras have been known to appear at /dev/sda too, and that sounds to me like a serious headache for the PC world. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: Antwort: Max number of dasd devices
World hunger comes to mind. Romney On Wed, 16 Oct 2002 05:21:43 +0800 John Summerfield said: On Tue, 15 Oct 2002, Mark Perry wrote: I've been trying to understand the headache that Jim mentions relating to the lack of devfs support in SuSE zinux. All that devfs buys you is the ability to refer to the device address rather than some drive letter in non-devfs, and the fact that drive letters get reallocated when device addresses are removed and/or added. Thus the real issue is being able to use an fstab that contains specific device addresses rather than drive letters, right? Is there a problem filesystem labels cannot solve? -- Cheers John. Please, no off-list mail. You will fall foul of my spam treatment. Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: Antwort: Max number of dasd devices
Jim Sibley writes: When will SuSE have the devfs as the default for zSeries so we don't have to compile the kernel to use it and get away from the double mapping we have to do between device and device node? It is a real nuisance to try and map 100 devices per LPAR for 7 or 8 LPARs. Then try moving 20 or thirty of those volumes to another LPAR when business needs dictate! W/O devfs, I can vouch that it is both a pain and error prone. devfs is not the only way of handling these device management issues. devfs carries along with it a certain amount of design and implementation history. Let's just say that distributions wouldn't gratuitously omit it just to make your life harder. There are two issues: the cleanliness of the kernel side and device management in userland. They only overlap slightly. In the medium to long term, the stick together multiple majors and index everything into arrays of stuff issue on kernel side should be solved via the combination of 32-bit dev_t (12 bit major, 20 bit minor), nice struct device, struct gendisk or whatever and devicefs. This assumes that Al Viro and co make the scramble before the 2.5 feature freeze next week (or get it in afterwards anyway :-). Linus gave him the OK two weeks ago so I have high hopes. For the userland issue, I've often wondered why someone hasn't done a version of scsidev for z/Linux (presumably dasddev would be the obvious name). It would simply go look at all the DASD information available via /proc/dasd/devices, /proc/partitions, query all the volumes for their volsers and build up a set of nodes and symlinks so you can refer to your volumes by label, /dev/dasdvol/VLABEL, or devno, /dev/dasdno/2345 and so on. I must admit, I haven't quite wondered hard enough for it to reach the top of my todo list though... --Malcolm -- Malcolm Beattie [EMAIL PROTECTED] Linux Technical Consultant IBM EMEA Enterprise Server Group... ...from home, speaking only for myself
Re: Antwort: Max number of dasd devices
Just as I thought - Linux is more interested in some notion of cleanliness rather than real user problems! devfs has already been coded and is available for zSeries users who need some relief. I've been struggling with this idiotic dev node system for 2 years on up to 40 linux LPARS and I can tell you from hard experience that niceness and what might happen in the future hasn't been the least bit of help in dealing with several thousands devices. Excuse the frankness but the linux solution is neither clean or easy to use IMNSHO. The net effect of this linux approach, in reality, is that all machines should look like a PCs rather than Linux being flexible enough to provide special solutions for special problems. Enough said. On Monday, Oct 14, 2002, at 03:06 US/Pacific, Malcolm Beattie wrote: Jim Sibley writes: When will SuSE have the devfs as the default for zSeries so we don't have to compile the kernel to use it and get away from the double mapping we have to do between device and device node? It is a real nuisance to try and map 100 devices per LPAR for 7 or 8 LPARs. Then try moving 20 or thirty of those volumes to another LPAR when business needs dictate! W/O devfs, I can vouch that it is both a pain and error prone. devfs is not the only way of handling these device management issues. devfs carries along with it a certain amount of design and implementation history. Let's just say that distributions wouldn't gratuitously omit it just to make your life harder. There are two issues: the cleanliness of the kernel side and device management in userland. They only overlap slightly. In the medium to long term, the stick together multiple majors and index everything into arrays of stuff issue on kernel side should be solved via the combination of 32-bit dev_t (12 bit major, 20 bit minor), nice struct device, struct gendisk or whatever and devicefs. This assumes that Al Viro and co make the scramble before the 2.5 feature freeze next week (or get it in afterwards anyway :-). Linus gave him the OK two weeks ago so I have high hopes. For the userland issue, I've often wondered why someone hasn't done a version of scsidev for z/Linux (presumably dasddev would be the obvious name). It would simply go look at all the DASD information available via /proc/dasd/devices, /proc/partitions, query all the volumes for their volsers and build up a set of nodes and symlinks so you can refer to your volumes by label, /dev/dasdvol/VLABEL, or devno, /dev/dasdno/2345 and so on. I must admit, I haven't quite wondered hard enough for it to reach the top of my todo list though... --Malcolm -- Malcolm Beattie [EMAIL PROTECTED] Linux Technical Consultant IBM EMEA Enterprise Server Group... ...from home, speaking only for myself
Re: Antwort: Max number of dasd devices
On Tue, 15 Oct 2002 08:51, you wrote: Just as I thought - Linux is more interested in some notion of cleanliness rather than real user problems! devfs has already been coded and is available for zSeries users who need some relief. I've been struggling with this idiotic dev node system for 2 years on up to 40 linux LPARS and I can tell you from hard experience that niceness and what might happen in the future hasn't been the least bit of help in dealing with several thousands devices. Excuse the frankness but the linux solution is neither clean or easy to use IMNSHO. The net effect of this linux approach, in reality, is that all machines should look like a PCs rather than Linux being flexible enough to provide special solutions for special problems. Why don't you put the question to your Linux vendor? I have heard that devfs isn't all it was hoped to be and the RH will not support it, that something better is coming. Unfortunately, I can't recall anything specific. Perhaps Alan can enlighten us, or tell be I've been enjoying forbidden substances. I do have the impression the SCSI world is going from bananas to worse; I hot-plugged in a Firewire drive and it came up at /dev/sda, and apparently USB cameras have been known to appear at /dev/sda too, and that sounds to me like a serious headache for the PC world. -- Cheers John Summerfield Microsoft's most solid OS: http://www.geocities.com/rcwoolley/ Join the Linux Support by Small Businesses list at http://mail.computerdatasafe.com.au/mailman/listinfo/lssb
Re: Antwort: Max number of dasd devices
On Fri, Oct 11, 2002 at 04:11:28PM -0700, Jim Sibley wrote: Udo wrote: so additional major numbers (typically descending from 254) are allocated Doesn't this conflict with the tape major numbers? What is their range? According to /usr/src/linux/Documentation/devices.txt the numbers from 231 to 254 are allocatet the following way: 231-239 UNASSIGNED 240-254 LOCAL/EXPERIMENTAL USE Ihno -- Ihno Krumreich[EMAIL PROTECTED] SuSE Linux AG S390 zSeries Deutschherrnstr. 15-19+49-911-74053-439 90429 N|rnberghttp://www.suse.de
Re: Antwort: Max number of dasd devices
Ihno wrote: According to /usr/src/linux/Documentation/devices.txt the numbers from 231 .to 254 are allocatet the following way: 231-239 UNASSIGNED 240-254 LOCAL/EXPERIMENTAL USE There is a discrepancy between the doc and the code that was implemented for the dasd driver. So, what else is new. 16x256=4096 (nodes 94 and 240-254). zSeries pushes well beyond that in device capability. 4 shark, iceberg, or other dasd subsystem hits this limit quickly nowadays. The current theoretical limit is 256 channels x 256 devices/channel=65,536 on a zSeries. When will SuSE have the devfs as the default for zSeries so we don't have to compile the kernel to use it and get away from the double mapping we have to do between device and device node? It is a real nuisance to try and map 100 devices per LPAR for 7 or 8 LPARs. Then try moving 20 or thirty of those volumes to another LPAR when business needs dictate! W/O devfs, I can vouch that it is both a pain and error prone.
