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?"

Comments

Not a specialized one, no

[melquiades]

I don't see why you'd want a specialized system is a good idea. Instead, we should ask what general principles might make filesystems work better with music. The obvious ones for music files include:

• performance (obviously),
  
• handling of massive storage (pushing the latest n-bit addressing limit,
  
• customizable file metadata (for storing tag information, among other things), and
  
• query facilities for the metadata.
  

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?

Nautilus

[xiox]

Nautilus has a music view, where it shoes the id3 tags as if it was an album sleeve. I'm not sure whether this is searchable though.

Re:Metadata

[foobar104]

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.

Been there, done that with BeOS

[Rude Turnip]

(and got the t-shirt)

BeOS (god rest its soul) uses the Be Filesystem, or BFS. It is a 64-bit journalling and indexing filesystem. It is essentially a filesystem that works much like a database. You can attach any number of arbitrary attributes to any file. Filetyping is handled by MIME filetypes, which are also stored as attributes. The default BeOS installation includes all of the usual attributes for music files and it is very easy to add many more. The BeOS "find file" tool is not unlike a database query tool.

In terms of speed, file searches are done almost instantaneously, even when searching through several gigs of data.

Nautilus

[mobydobius]

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

I don't think this has anything to do with the Windows file system. Its just how explorer presents data in certain folders. Nautilus does the exact same thing, for instance. It displays bitrate, time, artist, and presents a mini-player at the bottom of the folder view. I assume it gets the artist info from ID3 tags.