Re: [RFC] sane access to per-fs metadata (was Re:[PATCH]Documentation/ioctl-number.txt)
Alexander Viro wrote: > Other that that (and general ugliness of ioctls) - no problems. I > really think that trick I've described would be cleaner, but that's > a separate story. It's not like we had a moratorium on new ioctls, > after all and JFS wouldn't be the first fs to do something like that. > I don't think that it's a good idea, but the worst thing that can > happen is inconvenience for union-mount setups. When union-mount > gets to testable stage, that is - it's not like it was going into the > tree before 2.5, anyway. > > procfs use for per-filesystem stuff is a different issue - that is just > asking for bad breakage. Im a little new in here but after seeing you mention union mount I have to ask, where can I get some more information on union mount, am I correct in thinking that it is some form of overlay filesystem? Regards Angelo - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [RFC] sane access to per-fs metadata (was Re:[PATCH]Documentation/ioctl-number.txt)
Alexander Viro wrote: > > On Fri, 23 Mar 2001, Dave Kleikamp wrote: > > > Are you okay with JFS using a few ioctl's in the utilities and > > continuing the discussion of whether more general-purpose metadata > > access should occur in procfs or under your proposal? > > OK, one immediate problem with ioctls on directories: unions. > Think what happens when you union-mount JFS somewhere. And > mountpoint also is on JFS. Where should ioctl() go? AFAIC, I wouldn't object to calling this a limitation and letting the ioctl fail. In fact, the utilities could detect a union-mount and fail immediately. Although, someone, someday, will ask for it to work, won't they? > Other that that (and general ugliness of ioctls) - no problems. I > really think that trick I've described would be cleaner, but that's > a separate story. It's not like we had a moratorium on new ioctls, > after all and JFS wouldn't be the first fs to do something like that. > I don't think that it's a good idea, but the worst thing that can > happen is inconvenience for union-mount setups. When union-mount > gets to testable stage, that is - it's not like it was going into the > tree before 2.5, anyway. > > procfs use for per-filesystem stuff is a different issue - that is just > asking for bad breakage. I won't argue this point without learning more about it. So far I've only played with procfs to peek at some global data. -- David Kleikamp IBM Linux Technology Center - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [RFC] sane access to per-fs metadata (was Re:[PATCH]Documentation/ioctl-number.txt)
On Fri, 23 Mar 2001, Dave Kleikamp wrote: > Are you okay with JFS using a few ioctl's in the utilities and > continuing the discussion of whether more general-purpose metadata > access should occur in procfs or under your proposal? OK, one immediate problem with ioctls on directories: unions. Think what happens when you union-mount JFS somewhere. And mountpoint also is on JFS. Where should ioctl() go? Other that that (and general ugliness of ioctls) - no problems. I really think that trick I've described would be cleaner, but that's a separate story. It's not like we had a moratorium on new ioctls, after all and JFS wouldn't be the first fs to do something like that. I don't think that it's a good idea, but the worst thing that can happen is inconvenience for union-mount setups. When union-mount gets to testable stage, that is - it's not like it was going into the tree before 2.5, anyway. procfs use for per-filesystem stuff is a different issue - that is just asking for bad breakage. Cheers, Al - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [RFC] sane access to per-fs metadata (was Re:[PATCH]Documentation/ioctl-number.txt)
Al, I'm still unsure why you object to JFS using any ioctl's. I tried to explain that I wanted to use the ioctl's for operations that are specific to the JFS utilities. I thought the procfs would be a useful mechanism for debugging, on-the-fly performance tuning, and the like. I didn't state it directly, but I assumed the procfs stuff would not be enabled by default, so I was less concerned about the drawbacks of procfs. My main point was that I was planning on using some ioctl's for the utilities, and that I did not plan use ioctl's for a bunch of other purposes, like debugging. Are you okay with JFS using a few ioctl's in the utilities and continuing the discussion of whether more general-purpose metadata access should occur in procfs or under your proposal? -- David Kleikamp IBM Linux Technology Center - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [RFC] sane access to per-fs metadata (was Re:[PATCH]Documentation/ioctl-number.txt)
On Fri, 23 Mar 2001, Danilov Nikita wrote: > > Yes. And if after sleeping in read() you try to access the superblock again > > you will find that it's not there. > > Ok, so it wouldn't work for the complex entries providing services like > plan9 file servers, but use for simple statistics reports, etc. is ok as > far as they write data into kernel page allocated by proc_file_read() > and don't sleep, right? (I just need your sanction :). Umm... Probably that's OK, but I would be really careful about that. You should also make sure that window between the beginning of your put_super() and calling the remove_proc_entry() is safe. And keep in mind that ->s_root goes away before ->put_super() is called, so don't rely on its presense. I'm not saying that it can't be done or that it simple cases do not exist. But the whole approach looks like a bad idea - too many things you need to take care of to avoid screwups. Cheers, Al - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [RFC] sane access to per-fs metadata (was Re:[PATCH]Documentation/ioctl-number.txt)
Alexander Viro writes: > > > On Fri, 23 Mar 2001, Danilov Nikita wrote: > > > Alexander Viro writes: > > > > > > > > > On Fri, 23 Mar 2001, Danilov Nikita wrote: > > > > > > > > Not enough. You'll need to deal with invalidation of procfs entries on >umount > > > > > and that will be rather painful. > > > > > > > > What's wrong with remove_proc_entry()? > > > > > > The fact that in can be called in the middle of read() (or write(), for that > > > matter). > > > > Can you clarify this? I thought remove_proc_entry() takes care of this. > > As an experiment I created simple stub function (follows). > > > > If I umount fs while read is sleeping, remove_proc_entry() complains > > that entry is busy, and after read completes, deletes it (the same holds > > for directories). > > Yes. And if after sleeping in read() you try to access the superblock again > you will find that it's not there. Ok, so it wouldn't work for the complex entries providing services like plan9 file servers, but use for simple statistics reports, etc. is ok as far as they write data into kernel page allocated by proc_file_read() and don't sleep, right? (I just need your sanction :). > > remove_proc_entry() prevents further read() from going into fs code, > but it doesn't help the operations in progress. And making read() that > would never sleep is not a pretty thing - think of page faults if buffer > is unmapped, for one thing. Or allocating the buffer if you want to > get all data first and then copy them to userland without caring about > underlying object. > > You certainly can do a bunch of ad-hoc tricks that will preserve the > internals of your methods. It won't be easy, it won't be pretty and > it will be constant source of PITA. > Cheers, > Al Nikita. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [RFC] sane access to per-fs metadata (was Re:[PATCH]Documentation/ioctl-number.txt)
On Fri, 23 Mar 2001, Danilov Nikita wrote: > Alexander Viro writes: > > > > > > On Fri, 23 Mar 2001, Danilov Nikita wrote: > > > > > > Not enough. You'll need to deal with invalidation of procfs entries on >umount > > > > and that will be rather painful. > > > > > > What's wrong with remove_proc_entry()? > > > > The fact that in can be called in the middle of read() (or write(), for that > > matter). > > Can you clarify this? I thought remove_proc_entry() takes care of this. > As an experiment I created simple stub function (follows). > > If I umount fs while read is sleeping, remove_proc_entry() complains > that entry is busy, and after read completes, deletes it (the same holds > for directories). Yes. And if after sleeping in read() you try to access the superblock again you will find that it's not there. remove_proc_entry() prevents further read() from going into fs code, but it doesn't help the operations in progress. And making read() that would never sleep is not a pretty thing - think of page faults if buffer is unmapped, for one thing. Or allocating the buffer if you want to get all data first and then copy them to userland without caring about underlying object. You certainly can do a bunch of ad-hoc tricks that will preserve the internals of your methods. It won't be easy, it won't be pretty and it will be constant source of PITA. Cheers, Al - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [RFC] sane access to per-fs metadata (was Re:[PATCH]Documentation/ioctl-number.txt)
Alexander Viro writes:
>
>
> On Fri, 23 Mar 2001, Danilov Nikita wrote:
>
> > > Not enough. You'll need to deal with invalidation of procfs entries on umount
> > > and that will be rather painful.
> >
> > What's wrong with remove_proc_entry()?
>
> The fact that in can be called in the middle of read() (or write(), for that
> matter).
Can you clarify this? I thought remove_proc_entry() takes care of this.
As an experiment I created simple stub function (follows).
If I umount fs while read is sleeping, remove_proc_entry() complains
that entry is busy, and after read completes, deletes it (the same holds
for directories).
Nikita.
int reiserfs_blackhole_in_proc( char *buffer, char **start, off_t offset,
int count, int *eof, void *data )
{
extern unsigned long volatile jiffies;
int len = 0;
unsigned long now;
now = jiffies;
while( jiffies < now + 120 * HZ ) {
schedule();
}
len += sprintf( &buffer[ len ], "Thank you for your patience.\n" );
return reiserfs_proc_tail( len, buffer, start, offset, count, eof );
}
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
Re: [RFC] sane access to per-fs metadata (was Re: [PATCH]Documentation/ioctl-number.txt)
On Fri, 23 Mar 2001, Andreas Dilger wrote: > Now I'm wondering, why not have the filesystems export this via /proc? > Something like /proc/fs/, creating empty directories if Aiieee... And you are going to play with that tree whenever we rename a directory on the path to some mountpoint? Thanks, but I'll pass... Oh, and here's an instant self-LART: mount something on /proc/fs/bin ;-) > needed to fill out the tree. Saves the hassle of where to mount all > of the meta filesystems, and having to do the mounts in the first place > (i.e. how do you know a filesystem supports meta-mounts)? If you want to do fs-specific stuff you presumably know what fs you are dealing with, right? ;-) Anyway, procfs has a nasty problem regardless of the handling of mount tree: removal of active entires. You really don't want to go there. Notice that normally it is solved by having these entries per-driver, so they stay alive as long as driver is not unloaded. Not an option here, and yes, procfs sucks putrefied rat intensines through the straw for stuff like /proc/sys/net/ipv4/neigh/* too. Cheers, Al - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt)
Al writes: > On Thu, 22 Mar 2001, Andreas Dilger wrote: > > I look forward to seeing the ext2 code. I was just in the process of > > adding ioctls to ext3 to do online resizing within transactions. Maybe > > I'll rather use this interface if it looks good. Will it work on 2.2, > > or does it depend too much on new VFS? > > Should be OK, except that with 2.2 you'll need to get hold on dentry > from original fs instead of vfsmount (unfortunately, that can't be > done same way for both - 2.2 doesn't have vfsmount tree and in 2.4 > holding dentry without holding vfsmount is a one-way ticket to hell - > umount() will be unhappy). However, version-dependent part should be > very small. Now I'm wondering, why not have the filesystems export this via /proc? Something like /proc/fs/, creating empty directories if needed to fill out the tree. Saves the hassle of where to mount all of the meta filesystems, and having to do the mounts in the first place (i.e. how do you know a filesystem supports meta-mounts)? 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-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [RFC] sane access to per-fs metadata (was Re:[PATCH]Documentation/ioctl-number.txt)
On Fri, 23 Mar 2001, Danilov Nikita wrote: > > Not enough. You'll need to deal with invalidation of procfs entries on umount > > and that will be rather painful. > > What's wrong with remove_proc_entry()? The fact that in can be called in the middle of read() (or write(), for that matter). - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [RFC] sane access to per-fs metadata (was Re:[PATCH]Documentation/ioctl-number.txt)
Alexander Viro writes: > > > On Fri, 23 Mar 2001, Danilov Nikita wrote: > > > Ragnar Kjørstad writes: > > > On Fri, Mar 23, 2001 at 10:15:33AM -0600, Dave Kleikamp wrote: > > > > Again, why re-invent procfs? We could put this under > > > > /proc/fs/jfs/metadata. > > > > > > I guess /proc isn't the best choice when you have pr-mounted-fs metadata. > > > > > > > You can use something like > > > > proc_info_root = proc_mkdir( "fs/foofs", 0 ); > > superblock -> u.foofs_sb.proc_dir = proc_mkdir( bdevname( superblock -> s_dev ), > > proc_info_root ); > > > > Not beautiful, but passable. > > Not enough. You'll need to deal with invalidation of procfs entries on umount > and that will be rather painful. What's wrong with remove_proc_entry()? Nikita. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [RFC] sane access to per-fs metadata (was Re:[PATCH]Documentation/ioctl-number.txt)
On Fri, 23 Mar 2001, Danilov Nikita wrote: > Ragnar Kjørstad writes: > > On Fri, Mar 23, 2001 at 10:15:33AM -0600, Dave Kleikamp wrote: > > > Again, why re-invent procfs? We could put this under > > > /proc/fs/jfs/metadata. > > > > I guess /proc isn't the best choice when you have pr-mounted-fs metadata. > > > > You can use something like > > proc_info_root = proc_mkdir( "fs/foofs", 0 ); > superblock -> u.foofs_sb.proc_dir = proc_mkdir( bdevname( superblock -> s_dev ), > proc_info_root ); > > Not beautiful, but passable. Not enough. You'll need to deal with invalidation of procfs entries on umount and that will be rather painful. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [RFC] sane access to per-fs metadata (was Re: [PATCH]Documentation/ioctl-number.txt)
On Fri, 23 Mar 2001, Dave Kleikamp wrote: > Ragnar Kjørstad wrote: > > > > On Fri, Mar 23, 2001 at 10:15:33AM -0600, Dave Kleikamp wrote: > > > Again, why re-invent procfs? We could put this under > > > /proc/fs/jfs/metadata. > > > > I guess /proc isn't the best choice when you have pr-mounted-fs metadata. > > I'd have to add a component, made from s_dev, possibly. And then you are * bound to procfs internal API (_not_ a good idea, unless you have very strong reasons for that). * having all lovely problems with procfs (lack of) granularity. * having _huge_ fun with procfs entry removal upon umount. If you make them hold the corresponding JFS superblock - fine, you'll never be able to umount the thing. If you don't - well, enjoy handling JFS superblock yanked from you at zero notice. * putting policy into the place where it doesn't belong [location in procfs]. * ending up with the same amount of code (if not more than in non-procfs variant - payload code is identical, but instead of dummy read_super() you need to add a bunch of ad-hackery to prevent fun on umount) Oh, and * adding more non-sysctl and non-per-process objects into procfs. Also not a good idea... Cheers, Al - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [RFC] sane access to per-fs metadata (was Re: [PATCH]Documentation/ioctl-number.txt)
On Fri, 23 Mar 2001, Matthew Wilcox wrote:
> On Fri, Mar 23, 2001 at 09:56:47AM -0700, Bryan Henderson wrote:
> > There's a lot of cool simplicity in this, both in implementation and
> > application, but it leaves something to be desired in functionality. This
> > is partly because the price you pay for being able to use existing,
> > well-worn Unix interfaces is the ancient limitations of those interfaces
> > -- like the inability to return adequate error information.
>
> hmm... open("defrag-error") first, then read from it if it fails?
Or just do
(echo $cmd; read reply) &0
and make write() queue a reply. Yup, on the struct file used for write().
You _will_ need serialization for operations themselves, but for getting
replies... Not really.
> > With ioctl, I can easily match a response of any kind to a request. I can
> > even return an English text message if I want to be friendly.
So you can with read(). You know, the function that is intended to be used for
reading stuff into user-supplied buffer...
-
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: [RFC] sane access to per-fs metadata (was Re: [PATCH]Documentation/ioctl-number.txt)
Ragnar Kjørstad writes: > On Fri, Mar 23, 2001 at 10:15:33AM -0600, Dave Kleikamp wrote: > > Again, why re-invent procfs? We could put this under > > /proc/fs/jfs/metadata. > > I guess /proc isn't the best choice when you have pr-mounted-fs metadata. > You can use something like proc_info_root = proc_mkdir( "fs/foofs", 0 ); superblock -> u.foofs_sb.proc_dir = proc_mkdir( bdevname( superblock -> s_dev ), proc_info_root ); Not beautiful, but passable. Nikita. > > -- > Ragnar Kjørstad > Big Storage > - > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [RFC] sane access to per-fs metadata (was Re: [PATCH]Documentation/ioctl-number.txt)
On Fri, 23 Mar 2001, Bryan Henderson wrote: > How it can be used? Well, say it you've mounted JFS on /usr/local > >% mount -t jfsmeta none /mnt -o jfsroot=/usr/local > >% ls /mnt > >stats control bootcode whatever_I_bloody_want > >% cat /mnt/stats > >master is on /usr/local > >fragmentation = 5% > >696942 reads, yodda, yodda > >% echo "defrag 69 whatever 42 13" > /mnt/control > >% umount /mnt > > There's a lot of cool simplicity in this, both in implementation and > application, but it leaves something to be desired in functionality. This > is partly because the price you pay for being able to use existing, > well-worn Unix interfaces is the ancient limitations of those interfaces > -- like the inability to return adequate error information. I can imagine a solution to this using the _same_ method - extend /proc/*/ with a new entry (say, trace) for dumping errors. Put data in there from every failing function in your code. Normally, this will not introduce overheads (not unless you use error conditions to pass on useful information), however, in case of errors, you can get the backtrace (together with any info you want to put in there) immediately. > Specifically, transactional stuff looks really hard in this method. > If I want the user to know why his "defrag" command failed, how would I > pass that information back to him? What if I want to warn him of of a > filesystem inconsistency I found along the way? Or inform him of how > effective the defrag was? And bear in mind that multiple processes may be > issuing commands to /mnt/control simultaneously. That's all up to you. Informational messages can go to /proc. Transactions/serialization can be done in your filesystem's implementation. Maybe glibc guys would even want to extend strerror() to handle these cases? > > With ioctl, I can easily match a response of any kind to a request. I can > even return an English text message if I want to be friendly. > > - > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to [EMAIL PROTECTED] > Cheers, Pjotr Kourzanov - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt)
On Fri, Mar 23, 2001 at 09:56:47AM -0700, Bryan Henderson wrote:
> There's a lot of cool simplicity in this, both in implementation and
> application, but it leaves something to be desired in functionality. This
> is partly because the price you pay for being able to use existing,
> well-worn Unix interfaces is the ancient limitations of those interfaces
> -- like the inability to return adequate error information.
hmm... open("defrag-error") first, then read from it if it fails?
> effective the defrag was? And bear in mind that multiple processes may be
> issuing commands to /mnt/control simultaneously.
you should probably serialise them. you probably have to do this anyway.
> With ioctl, I can easily match a response of any kind to a request. I can
> even return an English text message if I want to be friendly.
yes, one of the nice plan9 changes was the change to returning strings
instead of numerics.
--
Revolutions do not require corporate support.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
Re: [RFC] sane access to per-fs metadata (was Re: [PATCH]Documentation/ioctl-number.txt)
Ragnar Kjørstad wrote: > > On Fri, Mar 23, 2001 at 10:15:33AM -0600, Dave Kleikamp wrote: > > Again, why re-invent procfs? We could put this under > > /proc/fs/jfs/metadata. > > I guess /proc isn't the best choice when you have pr-mounted-fs metadata. I'd have to add a component, made from s_dev, possibly. > -- David Kleikamp IBM Linux Technology Center - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt)
How it can be used? Well, say it you've mounted JFS on /usr/local >% mount -t jfsmeta none /mnt -o jfsroot=/usr/local >% ls /mnt >stats control bootcode whatever_I_bloody_want >% cat /mnt/stats >master is on /usr/local >fragmentation = 5% >696942 reads, yodda, yodda >% echo "defrag 69 whatever 42 13" > /mnt/control >% umount /mnt There's a lot of cool simplicity in this, both in implementation and application, but it leaves something to be desired in functionality. This is partly because the price you pay for being able to use existing, well-worn Unix interfaces is the ancient limitations of those interfaces -- like the inability to return adequate error information. Specifically, transactional stuff looks really hard in this method. If I want the user to know why his "defrag" command failed, how would I pass that information back to him? What if I want to warn him of of a filesystem inconsistency I found along the way? Or inform him of how effective the defrag was? And bear in mind that multiple processes may be issuing commands to /mnt/control simultaneously. With ioctl, I can easily match a response of any kind to a request. I can even return an English text message if I want to be friendly. - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [RFC] sane access to per-fs metadata (was Re: [PATCH]Documentation/ioctl-number.txt)
On Fri, Mar 23, 2001 at 10:15:33AM -0600, Dave Kleikamp wrote: > Again, why re-invent procfs? We could put this under > /proc/fs/jfs/metadata. I guess /proc isn't the best choice when you have pr-mounted-fs metadata. -- Ragnar Kjørstad Big Storage - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [RFC] sane access to per-fs metadata (was Re: [PATCH]Documentation/ioctl-number.txt)
Al, I didn't know that creating file system ioctl's was such a hot topic. Since the functions I want to implement are for a very specific purpose (I don't expect anything except the JFS utilities to invoke them), I would expect an ioctl to be an appropriate vehicle. If not ioctl's, why not procfs? Your proposal is that each filesystem implements its own mini-procfs. What's the advantage of that? My intentions so far are to use ioctl's for specific operations required by the JFS utilities, and procfs for debugging output, tuning, and anything else that make sense. Alexander Viro wrote: > That may look like an overkill, however > * You can get rid of any need to register ioctls, etc. This is a one-time thing > * You can add debugging/whatever at any moment with no need to > update any utilities - everything is available from plain shell We can do this with procfs right now. > * You can conveniently view whatever metadata you want - no need to > shove everything into ioctls on one object. Again, why re-invent procfs? We could put this under /proc/fs/jfs/metadata. > * You can use normal permissions control - just set appropriate > permission bits for objects on jfsmeta > > IOW, you can get normal filesystem view (meaning that you have all usual > UNIX toolkit available) for per-fs control stuff. And keep the ability to > do proper locking - it's the same driver that handles the main fs and you > have access to superblock. No need to change the API - everything is already > there... I'm not sure how a utility would make atomic changes to several pieces of metadata. The underlying fs code would protect the integrity of every metadata "file", but changes to more than one of these "files" would not be done as a group without some additional locking that would have to be coordinated between the utility and the fs. This kind of thing could be handled by writing some special command to a "command-processor" type file, but why is this better than an ioctl? -- David Kleikamp IBM Linux Technology Center - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED]
Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt)
Alexander Viro <[EMAIL PROTECTED]> writes:
> IOW, you can get normal filesystem view (meaning that you have all usual
> UNIX toolkit available) for per-fs control stuff. And keep the ability to
> do proper locking - it's the same driver that handles the main fs and you
> have access to superblock. No need to change the API - everything is already
> there...
> I'll post an example patch for ext2 (safe access to superblock,
> group descriptors, inode table and bitmaps on a live fs) after this weekend
> (== when misc shit will somewhat settle down).
> Cheers,
> Al
>
> PS: Folks[1], I hope it explains why I'm very sceptical about "let's add new
> A{B,P}I" sort of ideas - approach above can be used for almost all stuff
> I've seen proposed. You can have multiple views of the same object. And
> have all of them available via normal API.
This is a cool idea. But I couple of places where this might fall down.
1) If a filesystem has multiple name spaces and we use different mounts
to handle them, will this break anything? Fat32 with it's short and long
names, and the Novell filesystem are the examples I can think of.
2) An API is still being developed it just uses the existing infrastructure
which is good, but we still need to standardize what is exported. It's
a cleaner way to build a new API but a new API is being built.
3) What is a safe way to do this so a non-root user can call mount?
4) What is appropriate way using open,read,write,close,mount to handle stat data
and extended attributes. The stat data is the big one because it is used
so frequently. Possibly a mount&open&read/write&close&umount syscall is needed.
I keep thinking open("/path/to/file/stat_data") but that feels excessively heavy
at the API level. But if we involve mount (at least semantically)
that could work for directories as well.
The goal here is to push your ideas to the limits so we can where
using ioctl or new a syscall is appropriate. If indeed there is such
a case.
Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
Re: [RFC] sane access to per-fs metadata (was Re: [PATCH]Documentation/ioctl-number.txt)
On Thu, 22 Mar 2001, Andreas Dilger wrote:
> I look forward to seeing the ext2 code. I was just in the process of
> adding ioctls to ext3 to do online resizing within transactions. Maybe
> I'll rather use this interface if it looks good. Will it work on 2.2,
> or does it depend too much on new VFS?
Should be OK, except that with 2.2 you'll need to get hold on dentry
from original fs instead of vfsmount (unfortunately, that can't be
done same way for both - 2.2 doesn't have vfsmount tree and in 2.4
holding dentry without holding vfsmount is a one-way ticket to hell -
umount() will be unhappy). However, version-dependent part should be
very small. Something like
struct superblock *grab_super(name, p)
char *name;
void **p;
{
struct nameidata nd;
int err = 0;
*p = NULL;
if (path_init(name, 0, &nd))
err = path_walk(name, &nd);
if (err)
return ERR_PTR(err);
*p = mntget(nd.mnt);
path_release(&nd);
return (*(struct vfsmount**)p)->mnt_sb;
}
for 2.4 and
struct superblock *grab_super(name, p)
char *name;
void **p;
{
int err = 0;
struct dentry *dentry;
*p = NULL;
dentry = lookup_dentry(name, NULL, 0);
if (IS_ERR(dentry))
return (struct super_block*)dentry;
*p = dentry;
return dentry->d_sb;
}
for 2.2 should do the trick -
master_sb = grab_super(ext2root, &sb->u.ext2meta_sb.holder);
if (IS_ERR(matser_sb))
/* fail */
sb->u.ext2meta_sb.master = master_sb;
...
should be OK (to release the master sb you'll need to do dput() or mntput()
of sb->holder in 2.2 and 2.4 resp., indeed). I wouldn't try to port
that to 2.0, though...
Cheers,
Al
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
Re: [RFC] sane access to per-fs metadata (was Re: [PATCH] Documentation/ioctl-number.txt)
Al, you write: > * You can get rid of any need to register ioctls, etc. > * You can add debugging/whatever at any moment with no need to > update any utilities - everything is available from plain shell > * You can conveniently view whatever metadata you want - no need to > shove everything into ioctls on one object. > * You can use normal permissions control - just set appropriate > permission bits for objects on jfsmeta > > IOW, you can get normal filesystem view (meaning that you have all usual > UNIX toolkit available) for per-fs control stuff. And keep the ability to > do proper locking - it's the same driver that handles the main fs and you > have access to superblock. No need to change the API - everything is already > there... > I'll post an example patch for ext2 (safe access to superblock, > group descriptors, inode table and bitmaps on a live fs) after this weekend > (== when misc shit will somewhat settle down). I look forward to seeing the ext2 code. I was just in the process of adding ioctls to ext3 to do online resizing within transactions. Maybe I'll rather use this interface if it looks good. Will it work on 2.2, or does it depend too much on new VFS? 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/
[RFC] sane access to per-fs metadata (was Re: [PATCH]Documentation/ioctl-number.txt)
[cc'd to fsdevel, since trick described below may be of interest for other
folks]
On Thu, 22 Mar 2001, Dave Kleikamp wrote:
> Alexander Viro wrote:
> >
> > On Thu, 22 Mar 2001, Dave Kleikamp wrote:
> >
> > > Linus,
> > > I would like to reserve a block of 32 ioctl's for the JFS filesystem.
> >
> > Details, please? More specifically, what kind of objects are these ioctls
> > applied to?
>
> I don't have all the details worked out yet, but the utilities to extend
> and defragment the filesystem will operate on a live volume, so the
> utilities will need to talk to the filesystem to move blocks, extend the
> block map, etc.
>
> The utilities will probably open the root directory and apply the ioctls
> to it, unless there is a better way to do it.
There is - and it may simplify your life, actually. Here's what can be
done:
a) Use _two_ DECLARE_FSTYPE in your filesystem. Say it, for JFS
(normal) and jfsmeta. Make it FS_LITTER one.
b) let jfsmeta_read_super() take a pathname as an option (say it,
require "-o jfsroot=")
c) let it do lookup on that pathname and verify that it's on JFS
error = 0;
if (path_init(jfsroot, LOOKUP_FOLLOW|LOOKUP_POSITIVE, &nd))
error = path_walk(jfsroot, &nd);
if (error)
/* fail */
if (nd.mnt->mnt_sb->s_type != &jfs_fs_type)
/* fail */
d) store the reference to nd.mnt in superblock.
e) Allocate root dentry (as usual) and whatever files you want
(just pull the example from fs/binfmt_misc.c in -ac).
f) Make read/write on these files whatever you want them to do -
you can access the superblock of "master" JFS (see below)
via the saved value of nd.mnt (d).
g) in jfsmeta_put_super() do mntput() on pointer saved in (d).
How it can be used? Well, say it you've mounted JFS on /usr/local
% mount -t jfsmeta none /mnt -o jfsroot=/usr/local
% ls /mnt
stats control bootcode whatever_I_bloody_want
% cat /mnt/stats
master is on /usr/local
fragmentation = 5%
696942 reads, yodda, yodda
% echo "defrag 69 whatever 42 13" > /mnt/control
% umount /mnt
That may look like an overkill, however
* You can get rid of any need to register ioctls, etc.
* You can add debugging/whatever at any moment with no need to
update any utilities - everything is available from plain shell
* You can conveniently view whatever metadata you want - no need to
shove everything into ioctls on one object.
* You can use normal permissions control - just set appropriate
permission bits for objects on jfsmeta
IOW, you can get normal filesystem view (meaning that you have all usual
UNIX toolkit available) for per-fs control stuff. And keep the ability to
do proper locking - it's the same driver that handles the main fs and you
have access to superblock. No need to change the API - everything is already
there...
I'll post an example patch for ext2 (safe access to superblock,
group descriptors, inode table and bitmaps on a live fs) after this weekend
(== when misc shit will somewhat settle down).
Cheers,
Al
PS: Folks[1], I hope it explains why I'm very sceptical about "let's add new
A{B,P}I" sort of ideas - approach above can be used for almost all stuff
I've seen proposed. You can have multiple views of the same object. And
have all of them available via normal API.
[1] Hans, in particular ;-) Basically, that's the idea you keep mentioning -
_everything can be represented as fs_. Take it one step further and you'll
get _and the beauty of that is in the fact that you don't need new tools
to use the thing - generic ones are fine_
-
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/
