LWN: Comments on "Creating Linux virtual filesystems"

Creating Linux virtual filesystems

viro — 2012-04-04T06:11:53+00:00

Several points:

1) return value of mount_single() is struct dentry *; so's that of ->mount(). IOW, the body is correct, but declaration isn't - it should return struct dentry *, not struct super_block *.

2) use d_make_root() instead of d_alloc_root(); cleanup is easier with that one (and d_alloc_root() will be gone in 3.4 anyway). In this case it becomes simply

root = lfs_make_inode (sb, S_IFDIR | 0755);
if (root) {
root->i_op = &simple_dir_inode_operations;
root->i_fop = &simple_dir_operations;
}
sb->s_root = d_make_root(root);
if (!sb->s_root)
return -ENOMEM;
lfs_create_files(sb, sb->s_root);
return 0;

3) simple_read_from_buffer() is your friend. Instead of

len = snprintf(tmp, TMPSIZE, "%d\n", v);
if (*offset > len)
return 0;
if (count > len - *offset)
count = len - *offset;
/*
* Copy it back, increment the offset, and we're done.
*/
if (copy_to_user(buf, tmp + *offset, count))
return -EFAULT;
*offset += count;
return count;

just do

len = snprintf(tmp, TMPSIZE, "%d\n", v);
return simple_read_from_buffer(buf, count, offset, tmp, len);

and be done with that.

4) no need to open-code d_alloc_name(). Or simple_mkdir(), for that matter...

Creating Linux virtual filesystems

crxz0193 — 2012-04-04T05:24:10+00:00

to make it work with the linux 3.0 change following:
/*
* Stuff to pass in when registering the filesystem.
*/
static struct super_block *lfs_get_super(struct file_system_type *fst,
int flags, char *devname, void *data)
{
/* return get_sb_single(fst, flags, data, lfs_fill_super, mnt);*/
return mount_single(fst, flags, data, lfs_fill_super);
}

static struct file_system_type lfs_type = {
.owner = THIS_MODULE,
.name = "lwnfs",
.mount = lfs_get_super,
/*.get_sb = lfs_get_super,*/
.kill_sb = kill_litter_super,
};

Creating Linux virtual filesystems a Question

gjpc — 2006-03-02T18:48:36+00:00

Thanks very much for this helpful article.

I have a questions about mounted file systems within file systems.

Let's say within a ext3 root file system I create a file system foo at mount point /fooRoot.

I then create a node within the foo file system fooChild.

I then create sub node to fooChild, fooGrand.

Now I mount a ext2 file system on node fooGrand.

When a user tries to fopen( "/fooRoot/fooChild/fooGrand/someFile", "r" ) will that open request somhow be cleared through the foo file system before handed to the ext2 file system?

Creating Linux virtual filesystems

coderock — 2004-04-01T20:12:49+00:00

You are not supposed to mkfs it, or associate it with a device, just "mount -t lwnfs none /some/where" should work

Creating Linux virtual filesystems

mojozoox — 2004-03-22T13:31:04+00:00

Ya alright i managed to tweak the filesystem to run on linux 2.4. But im unable to mount it ...

mkfs -t option does not seem to work with the lwnfs okay!

could somebody help on how to go about it to associate it to a device and then mount it to mountpoint.

Creating Linux virtual filesystems

erich — 2002-10-29T19:32:19+00:00

I'd like to see some experience reviews of replicating filesystems (preferrably based on such virtual filesystems) but also on Coda, OpenAFS, Intermezzo, SFS (which is non replicating, but a nice secure network file system).
Especially on such issues like reliable locking, ease of setup, speed of replication etc. I'd love to have a mail server on a replicating set of servers (using Maildir of course, not mbox). Preferably capable of disconnected operation - having one mail server in the US, one in Europe would be cool...

Greetings,
Erich

P.S. Thanks to HP, LWN and Bdale for the Debian Group Subscription.

Split the difference

esnyder — 2002-10-24T22:40:56+00:00

I don't know; I liked the extra technical information, and would not really change the amount of code inline in the article. However, I did find myself wishing for a conclusion that offered some details on the kinds of (non-trivial) things that one might implement as virtual filesystems. While the counter-per-file was great to give a quick overview of how to implement something, I'm not sure I really got the big picture.

Count me in as voting for continued 'special interest' articles when time permits.

per process filesystem namespace

brouhaha — 2002-10-24T20:20:27+00:00

There's a simple solution to that: if a setuid program gets loaded when there is a per-process namespace active, the kernel can ignore the setuid bit and run it with no privileges.

AFAICT, that would allow non-privileged users to play with their namespace all they want, without compromising system integrity.

Creating Linux virtual filesystems

ekj — 2002-10-24T07:42:47+00:00

Well a filesystem that lives in its own module doesn't bother anyone who doesn't load it. "lwnfs" now exists. It bothers noone. Those who want their linux-box to be able to count in kernel-mode can insmod it, the rest of us can go on our merry way.

:-)

per process filesystem namespace

brugolsky — 2002-10-24T02:11:41+00:00

Al Viro also snuck it into 2.4.19. :-) It ought to be possible to allow non-root mounts on mount points where the user has write permission. As Jon noted, letting the user mount over, e.g., /etc/passwd, is incompatible with setuid executables.

I'm beginning to think about this because I want to start using Ron Minnich's implementation of 9P (v9fs.sourceforge.net) for various development and admin tasks.

Great article Jon -- once Al Viro adds union-mount, may a thousand
mini filesystems bloom. :-P

Creating Linux virtual filesystems

airwin — 2002-10-23T19:40:26+00:00

Thanks for that additional link.

Creating Linux virtual filesystems

corbet — 2002-10-23T18:38:22+00:00

Sorry you didn't like it...it was meant to be a far more technical piece than usually appears on the Kernel Page. The technical level of that page isn't changing, but I think it's worth putting in some more hardcore stuff occasionally.

"The introduction gives the impression that we might end up with hundreds of special file systems in the near future, and I believe that would be an even worse mess than the current /proc. "

That is a definite risk; the Linux system of the future could well have management issues that we don't see now.

"Your conclusion then does give a tantalizing indication that there are other ways to export information than a special file system, but this needs expansion."

The device model was covered in some detail back in August.

Creating Linux virtual filesystems

airwin — 2002-10-23T16:50:08+00:00

Actually, I didn't like this article as much as the other posters here. To my mind the balance between introductory material (which most LWN readers can understand) and technical details (which most LWN readers cannot understand) is off. Here are my two suggestions:

(1) I suggest you should have included the same technical details, but hide them in the link to your overall source code for the small subset of your readers who are interested. After all, the main point here is that libfs creates a boilerplate way of creating your own special file system; the details of the boilerplate are not that interesting until the day you actually want to create your own filesystem.

(2) Please expand the introductory and concluding material. The introduction gives the impression that we might end up with hundreds of special file systems in the near future, and I believe that would be an even worse mess than the current /proc. Your conclusion then does give a tantalizing indication that there are other ways to export information than a special file system, but this needs expansion.

Creating Linux virtual filesystems

corbet — 2002-10-23T15:16:10+00:00

No, the code is correct - lfs_create_file already gets a pointer to the counter as an argument, there's no need to indirect it again.

Creating Linux virtual filesystems

nick.leroy — 2002-10-23T14:59:01+00:00

Nice, informative article. Great!

However, if I'm not mistaken, isn't the following line incorrect, or did I miss something?
inode->u.generic_ip = counter;
Shouldn't it be (note the pointer to counter):
inode->u.generic_ip = &counter;

Once again, great article.

-Nick

per process filesystem namespace

corbet — 2002-10-23T12:34:42+00:00

2.5 has per-process namespaces, allowing the administrator to set up completely different views of the filesystem for different tasks. This capability remains restricted to root, though. If any user could set up any namespace they wanted, there would be a thousand ways to confuse setuid programs and take over the system.

Subscriber needs

veelo — 2002-10-23T10:04:07+00:00

Agreed!

> European Union
Make that Europe; it will take a couple of decades (or eternity) before all European countries have joined the Union... Maybe we should just stick to continents, I suspect LWN readers are spread over too many countries.

Bastiaan.

per process filesystem namespace

scottt — 2002-10-23T06:05:05+00:00

On a somewhat related topic, I was under the impression that in 2.5 the VFS supports per process namespaces so a user without root priviledges can mount filesystems at will. Can someone confirm this ?

Subscriber needs

smoogen — 2002-10-23T04:38:29+00:00

Thanks for the info. I think that having the number on the front page would be a useful thing. This is a new way of doing things and so people might start understanding that they cant just wait for others to support you.

While not on the page it would be interesting to see how the country breakdown is with something like:

% of subscriptions % of visitors (derived from IP)
United States
European Union
Japan
Canada
Mexico

Now that is something to be nationalistic about :)

Creating Linux virtual filesystems

roelofs — 2002-10-23T00:41:41+00:00

So you wrote this article, Jonathan? That was a tad difficult to divine from the actual posting, even though you were the most likely suspect (as Kernel page editor and all)... Perhaps a subtitle or closing block or something with an attribution in the future? (Don't be shy about tooting your own horn, eh? You might consider naming a few names on the About page, too.)

Greg

Creating Linux virtual filesystems

gregkh — 2002-10-22T22:13:09+00:00

Ah, missed the kill_litter_super() reference, nice.

But does this mean that if you unmount the fs, and then mount it again, the "counter" file is created from scratch, with a initialized value?

If so, this might not be what you want for a fs that is tied to a driver. You might want to keep around the files between mounts, and not be forced to regenerate them all every mount time. This can be seen in usbfs where the files are created when a device is added or removed from the system. We don't walk all devices at mount time, although that might not be a bad idea...

Anyway, this is a minor point, very nice article, it matches my upcoming linux.conf.au talk and paper quite well :)

Oh, and for doing something like this for the 2.4 kernel, this article might help out a bit.

Subscriber needs

corbet — 2002-10-22T20:32:11+00:00

Last week, when we were just short of 2000, we set a goal of 4000 as a relatively stable place to be somewhere not too far into next year at the latest. We up to almost 2100 now, so progress is happening...but the rate of new subscriptions is (not surprisingly) dropping off; it's probably going to take some serious work to get that doubling.

Creating Linux virtual filesystems

smoogen — 2002-10-22T20:29:06+00:00

Really nice article. It helps me on looking at something different today. So how many more subscribers are needed for your employment needs?

Creating Linux virtual filesystems

corbet — 2002-10-22T19:50:54+00:00

Actually, it unloads just fine. Trust me, I loaded/unloaded it a lot of times before I was ready to write anything about it... Only had to reboot once, though :). I haven't followed it too far, but my understanding is that kill_litter_super() cleans up all of that junk at unmount time.

Creating Linux virtual filesystems

gregkh — 2002-10-22T19:23:06+00:00

Nice article.

Unfortunatly, your module is not able to be unloaded, right (I'm guessing as I haven't tried the code myself)? Problem is that nothing is removing the files that you have created, forcing the module count to always remain positive.

To work around this, see the gyrations I had to do with get_mount and put_mount in the drivers/hotplug/pci_hotplug.c and drivers/usb/core/inode.c code. And patches to help port those two files to use libfs more are greatly appreciated :)