Slashdot Mirror
Music Filesystems?
Cutriss asks: "I suspect the odds are fairly good that a high percentage of Slashdot readers have a folder, disk partition, network share, or even a hard drive dedicated to storing Oggs or MP3s. Given that this is the case, wouldn't it be beneficial to develop a filesystem optimized for such a use? For instance, in Windows, Microsoft has special folder layouts for folders declared to have digital music or images in them. The digital music folders don't bother with file permissions or any unnecessary data, but instead display your songs with the appropriate ID3 tag information instead. If a filesystem were developed that intrinsically indexed its files by ID3 tags (or similar mechanisms), wouldn't this be an ideal structure for storing and searching through your album collection? And, more to the point, are there any such efforts under way to develop such a beast?"
That all sounds like BeFS to me. -- which, lo and behold, was discussed on Slashdot just the other day!
What other general features might be good for the specific application of music?
We don't need a special purpose filesystem for this; just one that supports metadata.
There are a lot of reasons why filesystem-level metadata is harder than it sounds. (XFS supports it, incidentally, though extended attributes. There are command-line tools, and also a C API. Dead simple.)
Filesystem-level metadata is usually stored in the inode itself. If it's not stored literally inside the inode, then it's tightly coupled to the inode. This is good; it makes it fast. Reading a big chunk of metadata (say, 128K) is about as fast as doing a stat(). So that's good.
But most applications do something tricky with their data files. Say, Photoshop for example. When you're working on a file (foo.tiff) in Photoshop and you tell it to "save," Photoshop doesn't truncate and write to the file foo.tiff. Instead it writes to a temporary file. When the write is complete, it unlinks foo.tiff and renames the temporary file "foo.tiff." This is also good, because it makes it very unlikely for a program or system crash to destroy foo.tiff, even if saving the file takes a really long time. A crash or other interruption during the save process leaves foo.tiff just as it was; at worst, it leaves a dangling temporary file laying around.
Here's the catch: when Photoshop saves that new temporary file it gets a new inode. That inode has no metadata in it. All the metadata associated with foo.tiff is in foo.tiff's inode. When the temp file has been written and Photoshop unlinks foo.tiff, that wonderful rich metadata disappears in a tiny puff of blue smoke.
Sure, there are ways to work around this. We could implement a system call like clone() or something that allows an application to get a new, empty file open for writing that has all the filesystem metadata from another file automatically copied to it. Or we could do any number of other clever things. But all of them-- at least to my knowledge-- would involve changing end-user applications. That makes it tough.
ID3 tags are different, because they're stored as part of the MP3 file itself. Copying the file's data, using any method you might choose, will also copy the ID3 tags. But inode-based filesystem-level metadata is something else entirely.