>>Some limitations are obvious: >>[...] >and no native support in existing OS, that would be the most important >limitation IMO... You could also just write data on sd-card, without any >filesystem at all
Oh, yes, that limitation was so obvious that I even forgot to list it ;-) Sure, storing raw data to certain sectors is the easiest and also the most common way. But if there is an unknown number of data sets, like sound files for an audio player or recordings from a data logger, it would be convenient to have some sort of grouping mechanism for data sets. The main criteria I have in mind when thinking about creating a new file system is RAM usage while reading and writing of files. FAT takes at least one sector of FAT (or a cached list of fragment positions) plus a sector of user data. This is a quarter of the available RAM even for the largest 8-bit PICs. And I'd like to have fast data transfer in linear mode. In my opinion, random access can be a bit slower for most µC applications. I'll have a look at CP/M and C64 filesystems, but at least the C64 was created for 180kByte media, so I fear it will not easily scale to 2GByte or 1TByte... But I would have borrowed the way of storing "speaking" filenames: Just define a file format for file #0, which associates a "numerical filename" to a character string, that can be displayed as human-readable filename. Other metadata, like file creation/modification/access time can go there, too. For the OS support, userspace programs can be a start, but kernel modules for linux and MacOS can be written. And for windows, noone expects non-microsoft file systems to be supported ;-) Greets, Kiste -- You received this message because you are subscribed to the Google Groups "jallib" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/jallib?hl=en.
