Live data from Hacker News

How to write a filesystem in 50 lines of code

blog.ksplice.com

11–20 of 31 posts

Re: How to write a filesystem in 50 lines of code

#11

Clever. But I find the idea of RouteFS more clever than the toy FS he built...

Applications of the same idea have been around for some time, e.g. Plan 9's file system (e.g. GUI elements are part of the FS, , bash's /dev/tcp// etc., and indeed /proc's file system seen in Linux and, in a limited way, in Solaris.

Seems like no Linux app framework can be complete without reinventing its own virtual file system, with various syntaxes for paths to e.g. network shares but that are inaccessible when used on the command line, etc.

Re: How to write a filesystem in 50 lines of code

#12
post #4

Youch! Beware, there are hidden pitfalls here. I tried the fuse-python xmp example and accidentally mounted the filesystem on top of an existing folder with the result being that the folder vanished. Now if I try to cd into that folder I get an input/output error. It doesn't show up on directory listings. And umount says it's not mounted. I have a backup so this is not an unmitigated disaster, but the folder is huge…

Have you tried `fusermount -u` on the mountpoint? That's the fuse-specific command to force an unmount, which might clean up the FUSE mount even if the OS's VFS layer doesn't think there's a mountpoint there.

Re: How to write a filesystem in 50 lines of code

#13
post #2

While this is a very interesting article, I think it would be great if people stopped using "How to do x in y lines of code" titles - it's just as bad as "x things about y" titles. It's a lot better when title actually describes what the article is really about. It would be awesome if this was added to the FAQ or something.

Although I think they're overdone, I think "x in y lines" is avery relevant to the hacker community, while "x things about y" isn't always. Doing "x in y lines" generally implies an unusually elegant solution, that could be of great use.

Re: How to write a filesystem in 50 lines of code

#14
post #10
post #4

Youch! Beware, there are hidden pitfalls here. I tried the fuse-python xmp example and accidentally mounted the filesystem on top of an existing folder with the result being that the folder vanished. Now if I try to cd into that folder I get an input/output error. It doesn't show up on directory listings. And umount says it's not mounted. I have a backup so this is not an unmitigated disaster, but the folder is huge…

Your data is fine -- it's hidden while something else is mounted on top of the folder. Rebooting will fix it. But you should be able to just unmount the filesystem, which will also fix it. Does 'mount' list something mounted there? Does 'df /path/to/folder/' reflect the FUSE filesystem rather than the underlying filesystem? The input/output error sounds like the FUSE filesystem being mounted indeed, and just being br…

> Your data is fine -- it's hidden while something else is mounted on top of the folder.

I thought that was the case. But the truth is I don't really understand how mount points work under the hood. Where is the mount point information actually stored? I'm guessing it's in kernel memory somewhere, but I don't really know, and Googling hasn't been much help. Is there an article somewhere that explains this?

> Rebooting will fix it.

Good to know.

> But you should be able to just unmount the filesystem

Yeah, you'd think. But everything I try to do to that directory results in "Input/output error".

> Does 'mount' list something mounted there?

Yes:

Python@fuse0 on /Users/ron/devel (fusefs, nodev, nosuid, synchronous, mounted by ron)

> Does 'df /path/to/folder/' reflect the FUSE filesystem rather than the underlying filesystem?

  [ron@mickey:~]$ df devel
  df: devel: Input/output error
  [ron@mickey:~]$ umount devel
  umount: devel: not currently mounted
  [ron@mickey:~]$ ls devel
  ls: devel: Input/output error
You can hopefully see why I'm puzzled. I would really like to understand why this is happening.

Re: How to write a filesystem in 50 lines of code

#15
post #12
post #4

Youch! Beware, there are hidden pitfalls here. I tried the fuse-python xmp example and accidentally mounted the filesystem on top of an existing folder with the result being that the folder vanished. Now if I try to cd into that folder I get an input/output error. It doesn't show up on directory listings. And umount says it's not mounted. I have a backup so this is not an unmitigated disaster, but the folder is huge…

Have you tried `fusermount -u` on the mountpoint? That's the fuse-specific command to force an unmount, which might clean up the FUSE mount even if the OS's VFS layer doesn't think there's a mountpoint there.

I'm running MacFuse. The fusermount command is specific to Linux.

Re: How to write a filesystem in 50 lines of code

#16
post #14
post #10

Earlier quoted context omitted.

Your data is fine -- it's hidden while something else is mounted on top of the folder. Rebooting will fix it. But you should be able to just unmount the filesystem, which will also fix it. Does 'mount' list something mounted there? Does 'df /path/to/folder/' reflect the FUSE filesystem rather than the underlying filesystem? The input/output error sounds like the FUSE filesystem being mounted indeed, and just being br…

> Your data is fine -- it's hidden while something else is mounted on top of the folder. I thought that was the case. But the truth is I don't really understand how mount points work under the hood. Where is the mount point information actually stored? I'm guessing it's in kernel memory somewhere, but I don't really know, and Googling hasn't been much help. Is there an article somewhere that explains this? > Rebootin…

Figured it out. umount wanted an absolute path.

Re: How to write a filesystem in 50 lines of code

#17
post #11

Clever. But I find the idea of RouteFS more clever than the toy FS he built...

Applications of the same idea have been around for some time, e.g. Plan 9's file system (e.g. GUI elements are part of the FS, , bash's /dev/tcp/ / etc., and indeed /proc's file system seen in Linux and, in a limited way, in Solaris. Seems like no Linux app framework can be complete without reinventing its own virtual file system, with various syntaxes for paths to e.g. network shares but that are inaccessible when u…

The point is that a FUSE filesystem is available from the command line and anywhere else, because it is an actual filesystem. RouteFS is a way of taking any virtual filesystem-like tree that you might find useful and making it available to the entire system as a normal filesystem, just as easily as you could describe the tree in any other form.

Re: How to write a filesystem in 50 lines of code

#18
post #2

While this is a very interesting article, I think it would be great if people stopped using "How to do x in y lines of code" titles - it's just as bad as "x things about y" titles. It's a lot better when title actually describes what the article is really about. It would be awesome if this was added to the FAQ or something.

Although I think they're overdone, I think "x in y lines" is avery relevant to the hacker community, while "x things about y" isn't always. Doing "x in y lines" generally implies an unusually elegant solution, that could be of great use.

It's such an easy metric to game, though ("The first line is 'import library_that_does_everything'") - It's a proxy for succinctness, at best.

That said, "[something non-trivial] in only 250-500 LOC" is often more interesting than "...in only 5 LOC", because generally anything that small is just gluing together libraries. There are exceptions, of course - I've seen impressive stuff in just a few lines of J/K/APL.

Re: How to write a filesystem in 50 lines of code

#19
post #15
post #12

Earlier quoted context omitted.

Have you tried `fusermount -u` on the mountpoint? That's the fuse-specific command to force an unmount, which might clean up the FUSE mount even if the OS's VFS layer doesn't think there's a mountpoint there.

I'm running MacFuse. The fusermount command is specific to Linux.

Time to get a real OS, it sounds like.

Re: How to write a filesystem in 50 lines of code

#20
post #2

While this is a very interesting article, I think it would be great if people stopped using "How to do x in y lines of code" titles - it's just as bad as "x things about y" titles. It's a lot better when title actually describes what the article is really about. It would be awesome if this was added to the FAQ or something.

I'd usually agree with you. But, since this is about building filesystems, something I thought was reserved for kernel hackers and truckload of C, I think the LOC title is appropriate. I would have still clicked, but would have expected something way over my head.
Post reply on HN