Re: Screw Linux, I'm going back to Windows!
From: Fredderic (fredderic@iprimus.com.au)Date: 09/15/02
- Next message: Tim Haynes: "Re: KOREAN SPAM: HOWTO deal with it???"
- Previous message: $kr1p7_k177y@salmahayeksknockers.edu: "comp.os.linux.security biweekly FAQ pointer"
- In reply to: Kasper Dupont: "Re: Screw Linux, I'm going back to Windows!"
- Next in thread: Kasper Dupont: "Re: Screw Linux, I'm going back to Windows!"
- Reply: Kasper Dupont: "Re: Screw Linux, I'm going back to Windows!"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Fredderic" <fredderic@iprimus.com.au> Date: Sun, 15 Sep 2002 14:42:36 +1000
> > > But we need some kernel support. A virtual block device,
> > > that can be bound to physical devices on command, might be
> > > what we need. It should be possible to disasociate the
> > > physical device from the block device even when it is
> > > mounted, in that case our userspace application should be
> > > notified if any process needs to access the drive.
> > How about a symlinik? I'd think that simply having a directory
> > containing symlinks associating the drive's label and/or serial
> > number to the physical drive, would do.
> That wouldn't work. Following the link is done at mount time,
> not at every block access which is what we need.
I don't understtand what you mean here...
I was having some trouble with the automounter for a while, so I created a
symlink in the root to the automounter's favorite install point. And with
fstab configured for another mount point, I get to pick which one to use.
The symlink was also useful because the automounter doesn't actually create
its mount points until they're activated. That's not looking at the symlink
at mount time, it's being followed by the kernel, and THEN the automounter's
being triggered.
Same goes for block access's... The kernel follows the symlink to it's
destination at file open time, and then uses the device ID and inode number
found at the end. Even mount does the same, it follows any symlinks to
determine the real name, and looks that up in the mount table. So any
symlinks are largely irrelevant.
Some less intelligent lower-level utilities might barf at a label symlink,
but I don't consider that to be a particular problem. Such utilities should
probably be used directly on the main mount point anyhow, just to help make
sure you're not getting yourself confused.
> > If it's made and broken by the mount process, it should be
> > pretty reliable.
> We need it to be changed even during the time the filesystem
> stays mounted.
No real problem there, especially if it resides in a virtual filesystem ala
/proc (and /dev/pts, I think).
> > Even a virtual block device would need to be created and
> > deleted as appropriate.
> Yes.
So the only difference between it and a symlink, is a second mount of the
same device which makes it harder to distinguish programatically.
> > Unless you did something similar to the automounter.
> That is actually what I had in mind.
Maybe one could just teach the automounter how to do it, as long as it
actually created the mount points and appropriate symlinks. It doesn
however raise a problem if two drives have the same label. Would you
combine serial number (which is largely uninteresting to a human user) and
label (which may not exist at all) into one name, create two seperate links,
or just prefer to use the label if it exists? And how should two disks with
the same label and/or serial be handled?
> > And even then, making it appear as a symlink should work just
> > fine,
> No.
Why not? I've had no problems using my /cdrom which is a link to the
automounter most of the time, except when I change it to point at the fstab
mount point.
The facility is there, and any remotely intelligent or stupidly dumb program
won't even notice. The only time a problem will arise, is with software
that tries to be intelligent but fails. The kernel provides the means to
translate a symlink into a real name -- its used by the just about every
kernel filesystem access call, mount, and everything else. And all that
really matters in the end, is the device ID and inode numbers. Even an
immediate file, simply resolves into an inode number which is used in
conjunction with the device ID, symlinks or no symlinks. That's the basis
of hardlinks, which are often considered a bad idea for directories (and
hence block devices, which is what you're proposing), and therefore
prevented from creation in userland (only root can overide that rule).
> > Indeed. Though if we're going to jump between readonly and
> > readwrite all the time (which would requre kernel support), may as
> > well just make a hybrid writeback mode -- someone suggested
> > "semi-sync", or being a C programmer, I suggested "volatile".
> You are right. That makes sense. The ability of actually
> being able to do something in userspace during the
> transition could come in handy. But having the kernel
> automatically finish writings is cleaner than trying to
> enforce it by remounting readonly. Still the changing of
> the dirty flag in the superblock at start/end of writes
> is a part of the feature. (Yes AmigaOS does that.)
To be honest, I didn't know that much filesystem theory when I had my Amiga,
so I didn't realise it HAD a dirty flag. I do remember that the AmigaOS
filesystem had a trippy linked-list structure which had certain weaknesses
in terms of disk corruption and directory search speed. Still, it made for
a wikkid ram disk! ;)
- Next message: Tim Haynes: "Re: KOREAN SPAM: HOWTO deal with it???"
- Previous message: $kr1p7_k177y@salmahayeksknockers.edu: "comp.os.linux.security biweekly FAQ pointer"
- In reply to: Kasper Dupont: "Re: Screw Linux, I'm going back to Windows!"
- Next in thread: Kasper Dupont: "Re: Screw Linux, I'm going back to Windows!"
- Reply: Kasper Dupont: "Re: Screw Linux, I'm going back to Windows!"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
