Larger dev_t

OK - everybody back from San Jose - pity I couldnt come - and it is no longer April 1st, so we can continue quarreling a little.

Interesting that where I had divided stuff in the trivial part, the interesting part and the lot-of-work part we already start fighting on the trivial part. Maybe it is not very important - still I'd prefer to do things right from the start.

Yes. We need a larger dev_t as everybody agrees.
How large?

What is dev_t used for? It is a communication channel from filesystem to user space (via the stat() system call) and from user space to filesystem (via the mknod() system call).

So, it seems the kernel interface must allow passing the values that actually occur, in present or future file systems. Making the interface narrow is only asking for problems later. Are there already any filesystems that use 64-bits?
I would say that that is irrelevant - what we don't have today may come tomorrow - but in fact the NFSv3 interface uses a 64-bit device number.

So glibc comes with 64 bits, the kernel has to hand these bits over to NFS but is unwilling to - you are not going to get more than 32. Why?

I fail to see the connection. There is no bloat here, the kernel is hardly involved. Some values are passed. If the values are larger than the filesystem likes it will probably return EINVAL. But the kernel has no business getting in the way.

There is no matter of efficiency either - mknod is not precisely the most frequently used system call, and our stat interface, which really is important, is 64 bits today.

Not using 64 also gives interesting small problems with Solaris or FreeBSD NFS mounts. One uses 14+18, the other 8+24, so with 12+20 we cannot handle Solaris' majors and we cannot handle FreeBSD's minors.

[Then there were discussions about naming. These are interesting, but independent.
The current discussion is almost entirely about mknod.]

Andries

Mount NFS device areas with NFSv2. Thats the standard workaround for the fact the NFSv3 designers got a good idea slightly wrong. There are other approaches too that also do not need 64bits.

I think the only reason for Linux to take 12 bit major is the fact that then he only has to increas the lenght of the static major device pointers in the kernel and it will be there... However the problem is mostly that the aforementioned array of pointers shouldn't me there in first place.

- phone: +49 214 8656 283
- job:   eVision-Ventures AG, LEV .de (MY OPINIONS ARE MY OWN!)
- langs: de_DE.ISO8859-1, en_US, pl_PL.ISO8859-2, last ressort:
ru_RU.KOI8-R

The question is WHAT do we communicate (and don't answer "major minor" here, since this is only numbers) and WHY do we need this communication.

Devfs aims to associate device names with dynamic, flat device numbers. So we have a scalable solution for the kernel -> user space communication. What we DON't have, is a similar simple way to tell it the other way around.

The reasons, why we need to know where a file is located on are:
- to only include files from one media
- to run certain optimizations like fsck does with disk spindles
- ...

So instead of just shifting the problems into the future and making the same mistake again, we should better think of interfaces, that give us the information we need and let this error prone (ever had a typo on mknod?) and never large enough static interface die.

Maybe there should be a way to translate a dynamic associated device number into a real device name, like the devfs name of it. May be a reverse mapping in devfs (/dev/by_dev_no/[0-9]+) would work. If these are symlinks, a readlink() would suffice. Very simple solution.

For comparing inode1.media == inode2.media (one of the most important uses for device numbers) we don't need to change anything.

For getting the device number of the spindle, the block devices which support partitions or are remapping a (set of) block device(s) could get IOCTLs (where this information belongs into and is as reliable as the driver).

For all these things, we can have a flat and dynamic device number namespace.

Device numbers have to be uniqe only during one power on -> run -> power off cycle. For the rest applications should store device names instead anyway. The applications, that don't are buggy by defintion.

Note: I certainly overlooked sth., so please flame me ;-)

Yes: Let "mknod /dev/foo [bc] x y" die!

Regards

Ingo Oeser

10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag>
         <<<<<<<<<<<<     been there and had much fun   >>>>>>>>>>>>

Device numbers/names have to be constant in order to detect disk layout changes across boots.

Alan

Names stay constant, but why the NUMBERS? The names should stay constant and represent the actual layout on each busses (say:
sane hierachic enumeration) of course.

But /dev/ide/host0/bus0/target0/lun0/part1 could get a new device number on every reboot, right?

I'm sure, I'm missing some important usage of device of device numers here (not counting the ones listed already), but I don't know what ;-)

Otherwise it would be too easy to remove static major/minors and all the fun allocating them. And LANANA would have one thing less to worry about ;-)

One thing I certainly miss: DevFS is not mandatory (yet).

Thanks & Regards

Ingo Oeser

10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag>
         <<<<<<<<<<<<     been there and had much fun   >>>>>>>>>>>>

You can do it that way too

It could be a different device each boot too. Who is doing the bus enumeration in a constant manner.

There are a very large number of reasons you need them and things that depend on constant numbering for block devices such as backup tools. They can Im sure be taught constant naming, but there is no provision for names not device ids in them.

Things like tar will no longer work on Linux for example because tar does not know how to archive the name of a device node.

devfs solves a different problem - enumeration of dynamically configured resources. Its unrelated to the fundamental problem.

That's "only" due to the fact that DevFS is an insanely racy and instable
piece of CRAP. I'm unhappy it's there anyway...

It certainly seems to have some race conditions but other than that and the slight problem it puts policy in the kernel it seems ok. I'd prefer it was userspace and implemented via /sbin/hotplug - but that isnt possible yet and opens a whole other set of interesting races to ponder

Yes, devfs has some races. They are in the process of getting fixed. Yes, it's taken a long time (moving house twice in 6 months and several travel trips take their toll on productivity).

However, a large number of people run devfs on small to large systems, and these "races" aren't causing problems. People tell me it's quite stable. I run devfs on my systems, and not once have I had a problem due to devfs "races". So I feel it's quite unfair to paint such a dire picture (I'm referring to Martin's comments here, not Alan's).

				Regards,

					Richard....
Permanent: [email protected]
Current:   [email protected]

And _that_ approach is the reason why I absolutely refuse to run your code on any of my boxen. Sorry. If devfs (without serious cleanup) will become mandatory I'll fork the tree - better backporting patches to Linus' one than depending on current devfs. You've been sitting on known (and easily fixable) bugs and asking to leave fixing them to you for what, 10 months already? Furrfu... You are maintainer of that code. You keep insisting on having everything and a kitchen sink in the devfs and refuse to split the functionality into reasonable pieces. Essentially you are saying that it's all or nothing deal. Fine with me - out of these options I certainly prefer the latter.
Al

Al, I've told you that the races will be fixed. Calm down. I know you take a very theoretical and hard-line approach. All I said was that the races aren't causing problems for people in real life. That's why some vendors are using it. I never disagreed with you about the existence of the races.
Peace, OK?

Yeah, 10 months during which I've gone to 7 conferences/workshops, written 2 papers, moved house twice, took two holidays (sorry, I have a life), moved/split/unsplit our lab network twice, caught the flu at least once, and sundry other distractions. Pardon me for being busy.

The claim that splitting it into pieces will be an improvement is just hand-waving. I've not seen a solid argument that shows how it will help. Especially not after I remove the FS database code in devfs and just use the dcache to store my tree. That will trim the code by 50% or more. I'm going to wait and see how my next versions of devfs turn out before I make any hard claims.

				Regards,

					Richard....
Permanent: [email protected]
Current:   [email protected]

They dont have users actively trying to exploit them. I don't consider it a big problem for development trees though. devfs has a maintainer at least

Alan

Agreed. If I were a sysadmin where I had users I didn't trust, then I'd be worried. Actually, I'd simply not enable module autoloading. In fact, I don't run autoloading because I don't like it personally. And I'm lucky that I have users on my network that I feel I can trust. Besides, I know where they live, or at least where they store their data/theses :-)

				Regards,

					Richard....
Permanent: [email protected]
Current:   [email protected]

This ignores the issue that in some cases you cannot give a physical location. Take the case of fibre-channel connected disks, potentially using multi-path I/O. There is no "actual layout" since you don't have a fixed physical path. At that point you have to have a more sophisticated naming scheme than the physical location of the disk, since physical location loses its meaning.

You absolutely must avoid device name slippage. Whether this involves major and minor numbers is pretty much orthogonal. Major and minor numbers provided a nice and simple way for the kernel to map a device open into a driver and an argument to said driver. There are obviously other (more complex ways) of achieving the same thing. An obvious answer for hard disks is some form of labelling. Equally obviously, this does not solve the problem of e.g. fibre-channel connected tape drives.

Regards,

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