A Visual Expedition Inside the Linux File Systems 85
RazvanM writes "This is an attempt to visualize the relationships among the Linux File Systems through the lens of the external symbols their kernel modules use. We took an initial look a few months back but this time the scope is much broader. This analysis was done on 1377 kernel modules from 2.6.0 to 2.6.29, but there is also a small dip into the BSD world. The most thorough analysis was done on Daniel Phillips's tree, which contains the latest two disk-based file systems for Linux: tux3 and btrfs. The main techniques used to establish relationships among file systems are hierarchical clustering and phylogenetic trees. Also presented are a set of rankings based on various properties related to the evolution of the external symbols from one release to another, and complete timelines of the kernel releases for Linux, FreeBSD, NetBSD, and OpenBSD. In all there are 78 figures and 10 animations."
Re:Verry Pretty ...but (Score:1, Informative)
You can draw several conclusions from the images. One of them is how similar some filesystems are.
Have a look to the hierarchical clustering and hamming distances graphs.
Link to the article's Front Page please? (Score:5, Informative)
Dear submitter,
A /. summary is a bit like a main page on a website. Make the organization clear. Don't pile on shortcuts to different parts of the website: the reader risks being discouraged trying to find out how best to get to the important part of your website. Less is better.
I actually clicked on one of the links that appeared to go to the "Expedition" website (based on its similarity to other links, as shown in my browser's statusbar!), then changed the address in the address bar to get to the front page.
You actually didn't include a link to your article's front page [jhu.edu], for heaven's sake!
Hope this helps for the next time you write a summary.
Re:One other observation though... (Score:2, Informative)
How is it possible to create a file system driver which does not call "register_filesystem" ?
If you 'rtfa'... it stated [jhu.edu]:
Another (again expected) observation is that the lack of (un)register_filesystem identifiers in the modules which only provides services to others: dlm, lockd, fat, and jbd2/jbd2.
Yes I did read the article and thought it was very interesting. For one thing the fact that in earlier kernel releases file system drivers used to use more or less the same set of external symbols and in recent releases they more often used exclusive external symbols. If that's a good or a bad thing I don't know because I'm not an expert in file systems. It may indicate file system kernel module writers are re-using code less or do no longer compare their work that much anymore or it could mean file systems are now functioning more efficiently because they use more specialized external functions now... or maybe it means nothing or something completely else ... I don't know really ....