On Wed, Jan 07, v...@parcelfarce.linux.theplanet.co.uk wrote:
> On Wed, Jan 07, 2004 at 11:15:59AM +0100, Olaf Hering wrote: > > Now, thats just fine and it was always been that way. > > What if I chroot into /foo, proc is mounted on /foo/proc, > > and run fsck /dev/sda3 in that chroot? > > That silly app looks for /etc/mtab (oh my...) and start the work. > > Fine. Now, /dev/root is in reality /dev/sda3. Bad for me.
> Huh?
For short: noone knows that /dev/sda3 is busy/used.
> Note that you're not only adding ad-hackery (which filesystems get that > major:minor printed and which do not?), you *STILL* hadn't solved your > problem. Why? Because you still won't catch e.g. ext3 on /dev/sda5 with > external journal on /dev/sda3. And if you hack parsing ext3 lines in > /proc/mounts, there's always reiserfs, jfs, etc., etc. _And_ there's > RAID with the same problems wrt. access to components. Real funny > when you have raid0 on md0, have md0 mounted and try to fsck one of > components.
That makes sense. Is there a sane way to inform userland apps that some stuff is used (mounted, part of a volume group or raid)? Sure, the raid or lvm specific tools will tell you...
> Scanning /etc/mtab or /proc/mounts in such situations is wrong. If fsck > is doing that, it's broken. The right way to fix it depends on what you > really want and whatever the hell it is, putting new and new fs-specific > code that would parse /proc/mounts lines into fsck(8) is not an answer.
Ok, it was mkfs.minix and an older distro. But still, is '/dev/root' or '/dev/fred' really correct?
On Wed, Jan 07, 2004 at 02:00:36PM +0100, Olaf Hering wrote: > Ok, it was mkfs.minix and an older distro.
mkfs should simply pass O_EXCL to open(). Which is what you really want and yes, it should work on 2.6 (not sure if it got backported on 2.4). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
måndagen den 5 januari 2004 13.39 skrev Nigel Cunningham:
> Hi.
> The suspend to disk implementations all assume that devices are not > [dis]appearing under us while we're suspended. If you do go adding and > removing devices while the power is off, you can expect the same > problems you'd get if you removed them without suspending the machine. > It would be roughly equivalent to hot[un]plugging devices.
Yes. It's very unclear unless you do mind reading, but I had in mind mounted filesystems such as /home on a USB stick or firewire Reasonable? yes! But such devices have to be rediscovered and allocated in such a way that the user can resume using the device as soon as it has been found. And it should not fail miserably if the user forgets to connect the device before resuming the machine. As you cannot unmount /home (usually) the kernel must remember the device somehow or make mounting file systems more loosely than today.
On Tue, Jan 06, 2004 at 02:41:15AM +0100, Andries Brouwer wrote: > On Mon, Jan 05, 2004 at 04:00:15PM -0800, Greg KH wrote:
> > > > Have you even _tried_ udev?
> > > Yes, and it works reasonably well. I have version 012 here. > > > Some flaws will be fixed in 013 or so.
> > What flaws would that be? The short time delay for partitions? Or > > something else?
> Yes, partitions are not handled very well. > So far I have never seen udev discover partitions on its own.
That is because it can not. Please see the current thread "removable media revalidation - udev vs. devfs or static /dev" on lkml for a solution to this.
> > > Some difficulties are of a more fundamental type, not so easy to fix.
> > Such as?
> Udev cannot do anything when there are no events. > And media insertion or removal does not always give events.
Exactly. That's why userspace needs to poll for this.
> [By the way, a compilation warning for every C file: > % make > gcc -pipe -Wall -Wmore.. -Os -fomit-frame-pointer -D_GNU_SOURCE \ > -I/usr/lib/gcc-lib/i486-suse-linux/3.2/include -I.../udev-012/libsysfs > -c -o udev.o udev.c > cc1: warning: changing search order for system directory > "/usr/lib/gcc-lib/i486-suse-linux/3.2/include" > cc1: warning: as it has already been specified as a non-system directory]
Odd, it works here just fine on a number of different Red Hat boxes :)
Ah. Well if you've unmounted filesystems prior to suspending, I would expect you should be fine. The device numbers might change - if they can change between mounts - but that won't be any different because of suspending. If you're talking about suspending with the file systems mounted, that ought to work to (once the appropriate power management support is done). If the user fails to reconnect the device before resuming, they should expect the same problems that they would encounter if they pulled it out without suspending. Of course I'm saying 'should' a lot here. Let me use it one more time... in my mind at least, the fact that we've suspended should be irrelevant to how things work.
On Thu, 2004-01-08 at 02:39, Robin Rosenberg wrote: > måndagen den 5 januari 2004 13.39 skrev Nigel Cunningham: > > Hi.
> > The suspend to disk implementations all assume that devices are not > > [dis]appearing under us while we're suspended. If you do go adding and > > removing devices while the power is off, you can expect the same > > problems you'd get if you removed them without suspending the machine. > > It would be roughly equivalent to hot[un]plugging devices.
> Yes. It's very unclear unless you do mind reading, but I had in mind mounted filesystems > such as /home on a USB stick or firewire Reasonable? yes! But such devices have to > be rediscovered and allocated in such a way that the user can resume using the device > as soon as it has been found. And it should not fail miserably if the user forgets to connect > the device before resuming the machine. As you cannot unmount /home (usually) the > kernel must remember the device somehow or make mounting file systems more loosely > than today.
> -- robin
-- My work on Software Suspend is graciously brought to you by LinuxFund.org.
> > > 2) We are (well, were) running out of major and minor numbers for > > > devices.
> > devfs tried to fix this one by _getting rid_ of those numbers. > > Seriously - what are they needed for?
> But devfs failed in this. The devfs kernel interface still requires a > major/minor number to create device nodes.
> Hopefully I can work on fixing this up in 2.7.
You must be kidding here. Where exactly do you see devfs fault?
It is not "devfs kernel interface". It is "kernel userland interface" that requires a major/minor to associate device node with device.
Devfs (in its current shape) is no more than just a repository of (device node, major/minor) relations. Devfs does not care where dev number comes from. Driver may hardcode it or request dynamically from kernel, either way is fine.
Answering your other mail - "devfs kernel interface" provided ability to request dynamic device number when registering a node. Sounds very much like what you'd wish. Somebody decided it was evil and removed it. I personally do not care either way.
> So, how does devfs stack up to the above problems and constraints: > Problems: > 1) devfs only shows the dev entries for the devices in the system.
Is this a problem? Where exactly this problem lies?
> 2) devfs does not handle the need for dynamic major/minor numbers
Neither does udev. Both take whatever driver gives them.
> 3) devfs does not provide a way to name devices in a persistent > fashion.
I am not sure what exactly you mean here.
> 4) devfs does provide a deamon that userspace programs can hook > into > to listen to see what devices are being created or removed. > Constraints: > 1) devfs forces the devfs naming policy into the kernel. If you > don't like this naming scheme, tough.
kernel imposes naming scheme for exporting devices in sysfs. It is possible to get rid of devfs_name in kernel and use those names that must exist anyway to support udev as well. devfs has devfsd that can call whatever naming agent you like.
> 2) devfs does not follow the LSB device naming standard.
it is user-space (devfsd) issue, not kernel space (devfs)
> 3) devfs is small, and embedded devices use it. However it is > implemented in non-pagable memory.
Same for sysfs. Other Unices have pageable kernel memory. If Linux had it any memory based filesystem could benefit from it. I did not look at backing store for sysfs patches but it is likely that same idea could be used for devfs.
> Oh yeah, and there are the insolvable race conditions with the devfs > implementation in the kernel, but I'm not going to talk about them > right
I do not argue that current devfs implementation is ugly and racy. I just beg you to point at what makes those races "unsolvable".
> now, sorry. See the linux-kernel archives if you care about them (and > if you use devfs, you should care...)
I do care. Searching archives for devfs mostly brings "everyone knows this is crap". That is why I kindly ask you to show real evidence that the problems it has are unsolvable.
> So devfs is 2 for 7, ignoring the kernel races.
Hmm ... I really see only one - devfs names that are historically used. Assuming that
- devfs just exports kernel names (that must exist anyway) - sysfs provides consistent cdev view as it does for bdev
devfsd simply can take kernel name and call whatever program you like to implement naming policy including udev. With added benefit of removable devices support :)
On Thu, 8 Jan 2004, [koi8-r] "Andrey Borzenkov[koi8-r] " wrote:
> > 4) devfs does provide a deamon that userspace programs can hook > into > > to listen to see what devices are being created or removed. > > Constraints: > > 1) devfs forces the devfs naming policy into the kernel. If you > > don't like this naming scheme, tough.
> kernel imposes naming scheme for exporting devices in sysfs. It is > possible to get rid of devfs_name in kernel and use those names > that must exist anyway to support udev as well. devfs has > devfsd that can call whatever naming agent you like.
Yes. I'm having trouble finding justification for that statement as well.
devfs appears to have almost no device name info within it.
> > 2) devfs does not follow the LSB device naming standard.
> it is user-space (devfsd) issue, not kernel space (devfs)
And there is heaps of device naming going on in devfsd. As is what people seem to be recommending.
> > Oh yeah, and there are the insolvable race conditions with the devfs > > implementation in the kernel, but I'm not going to talk about them > right
> I do not argue that current devfs implementation is ugly and racy. I > just beg you to point at what makes those races "unsolvable".
> > now, sorry. See the linux-kernel archives if you care about them (and > > if you use devfs, you should care...)
> I do care. Searching archives for devfs mostly brings "everyone knows > this is crap". That is why I kindly ask you to show real evidence that > the problems it has are unsolvable.
Again I'm also unable to find descriptions of the 'unsolvable' races.
I wouldn't mind knowing what they are either. Anyone?
hch: devfs: there's a fundamental lookup vs devfsd race that's only fixable by introducing a lookup vs devfs deadlock. I can't see how this is fixable without getting rid of the current devfsd design. Mandrake seems to have a workaround for this so this is at least not triggered so easily, but that's not what I'd consider a fix.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Thu, 8 Jan 2004, Ian Kent wrote: > On Thu, 8 Jan 2004, [koi8-r] "Andrey Borzenkov[koi8-r] " wrote:
[Snip]
> > I do care. Searching archives for devfs mostly brings "everyone knows > > this is crap". That is why I kindly ask you to show real evidence that > > the problems it has are unsolvable.
> Again I'm also unable to find descriptions of the 'unsolvable' races.
> I wouldn't mind knowing what they are either. Anyone?
Can no one think of good search terms for these sorts of things these days? From the first and only page of results for 'devfs unsolvable races':
-- Alex Goddard agoddard at purdue.edu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Thu, 8 Jan 2004, Alex Goddard wrote: > On Thu, 8 Jan 2004, Ian Kent wrote:
> > On Thu, 8 Jan 2004, [koi8-r] "Andrey Borzenkov[koi8-r] " wrote:
> [Snip]
> > > I do care. Searching archives for devfs mostly brings "everyone knows > > > this is crap". That is why I kindly ask you to show real evidence that > > > the problems it has are unsolvable.
> > Again I'm also unable to find descriptions of the 'unsolvable' races.
> > I wouldn't mind knowing what they are either. Anyone?
> Can no one think of good search terms for these sorts of things these > days? From the first and only page of results for 'devfs unsolvable > races':
Someone else already mentioned the many, many posts by Al Viro on this subject I was about to post a URL or two for. They make for good (and entertainingly flame-ridden) reading.
-- Alex Goddard agoddard at purdue.edu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On Thursday 08 January 2004 20:26, Diego Calleja wrote:
> El Thu, 8 Jan 2004 23:40:16 +0800 (WST) Ian Kent <ra...@themaw.net> escribió: > > Again I'm also unable to find descriptions of the 'unsolvable' races.
> > I wouldn't mind knowing what they are either. Anyone?
> You can find tons of examples (several of them patches by Al Viro to fix > them) by searching with google with keywords like "devfs races". The > "should fix" list > (http://www.kernel.org/pub/linux/kernel/people/akpm/must-fix) has this:
is it a gospel?
> hch: devfs: there's a fundamental lookup vs devfsd race that's only > fixable by introducing a lookup vs devfs deadlock. I can't see how this > is fixable without getting rid of the current devfsd design. Mandrake > seems to have a workaround for this so this is at least not triggered so > easily, but that's not what I'd consider a fix..
oh, well ... if you selected this example ...
Mandrake workaround it mentions was my first attempt to fix this; this did not fix the devfs but rather fixed the user-space program that provoked this on boot (and that was buggy irrespectively of this problem).
Current 2.6 kernel includes my fix to deadlock condition. Current -mm includes one possible fix for race condition; Andrew Morton mentioned that it is unlikely to be accepted due to minor changes in VFS layer; I am working on another less intrusive fix and overall devfs cleanup.
Would you please instead of citing long obsolete paper show me real example and explain *why* it is not fixable. Better yet, would you take some time to try to provoke any of those huge races and report back your success (stack trace and instructions how to reproduce them are welcome :)
On Thursday 08 January 2004 21:14, Alex Goddard wrote:
> On Thu, 8 Jan 2004, Ian Kent wrote: > > On Thu, 8 Jan 2004, [koi8-r] "Andrey Borzenkov[koi8-r] " wrote:
> [Snip]
> > > I do care. Searching archives for devfs mostly brings "everyone knows > > > this is crap". That is why I kindly ask you to show real evidence that > > > the problems it has are unsolvable.
> > Again I'm also unable to find descriptions of the 'unsolvable' races.
> > I wouldn't mind knowing what they are either. Anyone?
> Can no one think of good search terms for these sorts of things these > days? From the first and only page
hmm ... that does not sound like "tons of" as someone else mentioned does it?
I wasn't aware the lookup race had been fixed. Silly me. As to the number of results for the terms I used, I was looking for that specific post, as I'd cited it before. 'devfs deadlock' also returns plenty of good (and irrelevant) results at that same archive.
On Thu, 8 Jan 2004, Andrey Borzenkov wrote: > On Thursday 08 January 2004 20:26, Diego Calleja wrote: > > El Thu, 8 Jan 2004 23:40:16 +0800 (WST) Ian Kent <ra...@themaw.net> > escribió: > > > Again I'm also unable to find descriptions of the 'unsolvable' races.
> > > I wouldn't mind knowing what they are either. Anyone?
> > You can find tons of examples (several of them patches by Al Viro to fix > > them) by searching with google with keywords like "devfs races". The > > "should fix" list > > (http://www.kernel.org/pub/linux/kernel/people/akpm/must-fix) has this:
> is it a gospel?
Given akpm's track record and, the fact that he's going to be maintaining 2.6, his word is enough for me. But...
> Mandrake workaround it mentions was my first attempt to fix this; this > did not fix the devfs but rather fixed the user-space program that > provoked this on boot (and that was buggy irrespectively of this > problem).
> Current 2.6 kernel includes my fix to deadlock condition. Current -mm > includes one possible fix for race condition; Andrew Morton mentioned > that it is unlikely to be accepted due to minor changes in VFS layer; I > am working on another less intrusive fix and overall devfs cleanup.
> Would you please instead of citing long obsolete paper show me real example > and explain *why* it is not fixable. Better yet, would you take some time to > try to provoke any of those huge races and report back your success (stack > trace and instructions how to reproduce them are welcome :)
> Thank you
One should do one's own research. If I'd done my own better, I would've found a better example than the one I posted previously. However, since you seem unwilling or unable to do your own homework, and I have nearly unlimited free time until next Monday, here's some more:
These posts are out there and they are _not_ hard to find at all. That last one was from about two weeks ago. The other is much older, and I'd have to do some digging in ugly, ugly code to find points that still apply. However, as I started this paragraph by saying, this stuff isn't hard to find at all.
Please consider doing your own homework. It's not like discussion of devfs and its problems has been rare.
Thank you.
-- Alex Goddard agoddard at purdue.edu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
> One should do one's own research. If I'd done my own better, I would've > found a better example than the one I posted previously. However, since > you seem unwilling or unable to do your own homework, and I have nearly > unlimited free time until next Monday,
May I ask you once more - please show me the _unsolvable_ parts. Articles you quote discuss devfs shortcomings and design problems; many of them are fixed; others can be fixed; none of them are unfixable.
Andrey Borzenkov wrote: >>So, how does devfs stack up to the above problems and constraints: >> Problems: >> 1) devfs only shows the dev entries for the devices in the system.
> Is this a problem? Where exactly this problem lies?
Some people like to unload their (modular) devices so they don't use memory when not in use. This saves them a few kB. It is then useful to have the device node sitting there anyway, functioning as a trigger. The kernel will autoload the module when the device is opened, but that won't happen if there's no device node to open.
This approach can be made to work with devfs too - by splitting the device into two pieces. One that manages the device node, and autoloads the rest when needed.
>> 2) devfs does not handle the need for dynamic major/minor numbers
> Neither does udev. Both take whatever driver gives them.
>> 3) devfs does not provide a way to name devices in a persistent >> fashion.
> I am not sure what exactly you mean here.
Probably something like mv /dev/hda /dev/mydisk and have it remembered upon the next reboot. devfsd can do that though.
>> 4) devfs does provide a deamon that userspace programs can hook > into >> to listen to see what devices are being created or removed. >> Constraints: >> 1) devfs forces the devfs naming policy into the kernel. If you >> don't like this naming scheme, tough.
> kernel imposes naming scheme for exporting devices in sysfs. It is > possible to get rid of devfs_name in kernel and use those names > that must exist anyway to support udev as well. devfs has > devfsd that can call whatever naming agent you like.
>> 2) devfs does not follow the LSB device naming standard.
> it is user-space (devfsd) issue, not kernel space (devfs)
>> 3) devfs is small, and embedded devices use it. However it is >> implemented in non-pagable memory.
> Same for sysfs. Other Unices have pageable kernel memory. If Linux > had it any memory based filesystem could benefit from it. I did not > look at backing store for sysfs patches but it is likely that same > idea could be used for devfs.
>>Oh yeah, and there are the insolvable race conditions with the devfs >>implementation in the kernel, but I'm not going to talk about them > right
> I do not argue that current devfs implementation is ugly and racy. I > just beg you to point at what makes those races "unsolvable".
They are of course not unsolvable. Those understanding them seems to believe that a complete rewrite will be easier than the rather invasive changes necessary to fix the races. This is why the _current implementation_ is marked obsolete. Nobody is volunteering to fix devfs or rewrite it though.
> But since you brought it up: do you actually have anything else that can > open a remote IMAP file with a few thousand messages without taking ages > for it, and that you don't have to mouse around with? I'd like a graphical > interface for configuring stuff etc, but I sure as hell don't want to find > some f*ing icon to save a few messages that I selected in-order to my > "doit" queue or go to the next one, or pipe the thing to a shell-script, > or any number of things that are my actual _job_.
Don't you already use emacs? Emacs has gnus! Gnus now has nnimap, an imap backend.
> And the "no mousing" means that I don't want to have some popup window > that asks me what file I want to save into or similar crap. I can type > fast enough if I stay on the keyboard and can focus on one part of the > screen, but if I have to switch my focus around, I'm a goner.
> On a related matter, I'm probably a retard, but I've tried alternatives to > "trn" too, and there really aren't any. None of the graphical news readers > can show me one full page of threads, select the 3-4 threads from _that_ > one page that I want (from the keyboard), and then kill _that_ one page. > Not the whole newsgroup: only the part that shows in the window at that > time.
Man, you sound so ready for gnus. It does nntp as well.
> If nothing else, things like SATA will end up meaning that the device you > were used to seeign as /dev/hdc will suddenly show up as /dev/scd0 > instead. Just because you changed the cabling while you upgraded to a
I do not see easy solution for cdroms... UUID is not going to work there... Pavel
