OSDev.org

rdos wrote:I think FAT works fine, and so no reason to implement anything more complex.

bloodline wrote:

rdos wrote:I think FAT works fine, and so no reason to implement anything more complex.

I can think several reasons why I think FAT is an abomination from the third circle of Hell:

1. It’s clear from the way FAT works that it was never meant to have directories, the design is fundamentally suited to a single flat root directory with no subdirectories. The implementation of subdirectories is a horrible hack.

2. The Long file names kludge is a hideous bastardisation of the directory table, and makes traversing the directory very slow and complex requiring many in memory buffers (and logic) to fix.

3. It is by design non-extensible, I have had to write both detection code for FAT16 and FAT32, and two separate code paths to handle the different size FAT tables. If the implementations are incompatible then it would have made sense to implement a totally new system free of the above kludges.

4. It has far too much redundant data, the data structures are a mess of meaningless data.

I will point you to the Original Amiga File System (https://wiki.osdev.org/FFS_(Amiga) this link claims it’s the FFS but it actually describes the Original Amiga file system not the Amiga Fast File System, which was compatible but optimised away a lot of legacy cruft) as an example of a very simple, but properly implemented hierarchical file system. It too suffers from problem 4 as listed above, full of legacy cruft, but at least the overall structure is logical and very easy to parse in memory.

rdos wrote:The Amiga FS doesn't seem very efficient. You need to follow long linked lists which is highly inefficient since those cannot easily be cached.

rdos wrote:FAT allows that FAT table to be partially or completely cached, and when you read one FAT sector you get links to many blocks, something that is much more efficient than following links.

rdos wrote:Also, if you want to support FAT, you need to support FAT12, FAT16 and FAT32. FAT12 is pretty messy given that 1.5 bytes are used as FAT links.

offset = 3 * cluster / 2;
nextcluster = cluster & 1 ?
    ((fat[offset+1] << 4) | (fat[offset] >> 4)) :
    ((fat[offset+1] & 0xF) << 8) | fat[offset]);

rdos wrote:Another issue that is a bit troublesome is the 4G file size limitation.

nexos wrote:Does anyone know of tools for HPFS? I have been wanting to try using that.

bzt wrote:

rdos wrote:The Amiga FS doesn't seem very efficient. You need to follow long linked lists which is highly inefficient since those cannot easily be cached.

I don't see why not. Both are using long linked lists, why couldn't you cache the links for AmigaFS as well?

bzt wrote: Yeah, but probably you'll never need FAT12 these days. I agree it's looking ugly, but actually you can handle 1.5 bytes with a single trinary operator, does not influence the code much.

Code: Select all

offset = 3 * cluster / 2;
nextcluster = cluster & 1 ?
    ((fat[offset+1] << 4) | (fat[offset] >> 4)) :
    ((fat[offset+1] & 0xF) << 8) | fat[offset]);

(note, I haven't tested this code, just wrote it from memory to give you the idea, fat[] should be an unsigned char array.)

bzt wrote:

rdos wrote:Another issue that is a bit troublesome is the 4G file size limitation.

That's why exFAT was added to the family. It is much more complex than the other FAT file systems though. And yes, the file size limitation is another reason why FAT isn't recommended as your root file system.

rdos wrote:

bloodline wrote:

rdos wrote:I think FAT works fine, and so no reason to implement anything more complex.

I can think several reasons why I think FAT is an abomination from the third circle of Hell:

1. It’s clear from the way FAT works that it was never meant to have directories, the design is fundamentally suited to a single flat root directory with no subdirectories. The implementation of subdirectories is a horrible hack.

2. The Long file names kludge is a hideous bastardisation of the directory table, and makes traversing the directory very slow and complex requiring many in memory buffers (and logic) to fix.

3. It is by design non-extensible, I have had to write both detection code for FAT16 and FAT32, and two separate code paths to handle the different size FAT tables. If the implementations are incompatible then it would have made sense to implement a totally new system free of the above kludges.

4. It has far too much redundant data, the data structures are a mess of meaningless data.

I will point you to the Original Amiga File System (https://wiki.osdev.org/FFS_(Amiga) this link claims it’s the FFS but it actually describes the Original Amiga file system not the Amiga Fast File System, which was compatible but optimised away a lot of legacy cruft) as an example of a very simple, but properly implemented hierarchical file system. It too suffers from problem 4 as listed above, full of legacy cruft, but at least the overall structure is logical and very easy to parse in memory.

The Amiga FS doesn't seem very efficient. You need to follow long linked lists which is highly inefficient since those cannot easily be cached. FAT allows that FAT table to be partially or completely cached, and when you read one FAT sector you get links to many blocks, something that is much more efficient than following links.

FAT32 has the sector to the root directory in the boot record, so doesn't suffer from the problems of a fixed size root directory.

Also, if you want to support FAT, you need to support FAT12, FAT16 and FAT32. FAT12 is pretty messy given that 1.5 bytes are used as FAT links. OTOH, it is basically only the FAT table code that is different between FAT versions, and so most of the other code can be shared.

As for the long filename cludge, I agree that this was a pretty horrible design. Especially the idea to put wide character codes in the extended directory entries.

bloodline wrote:I do like the simplicity of this part of the FAT design, but it's fatally flawed for SSD as all write operations require hitting the FAT sectors... with the AmigaFS, each file essentially has it's own FAT.

bloodline wrote:The obvious comeback you can point out here, is that AmigaFS has a bitmap... I dislike this part of the design, so used a "freefile" as backwards compatible solution to reduce flash wear when I used the file system on SD cards (in an audio sampler design I was working on, which needed to write to disk a lot).

Octocontrabass wrote:

bloodline wrote:I do like the simplicity of this part of the FAT design, but it's fatally flawed for SSD as all write operations require hitting the FAT sectors... with the AmigaFS, each file essentially has it's own FAT.

SSDs perform wear leveling, so this isn't an issue as long as you follow reasonable SSD usage patterns (e.g. don't completely fill the disk, don't power the disk down when it's idle, use ATA TRIM/SCSI UNMAP when deleting data).

bloodline wrote:The obvious comeback you can point out here, is that AmigaFS has a bitmap... I dislike this part of the design, so used a "freefile" as backwards compatible solution to reduce flash wear when I used the file system on SD cards (in an audio sampler design I was working on, which needed to write to disk a lot).

The SD specification requires FAT on SD cards, and some cards will misbehave if you format them differently. All but the cheapest SD cards perform wear leveling anyway, so the best thing you can do for them is following the write patterns suggested in the SD specification.

clementttttttttt wrote:Fragmentation. Have you ever run a defragmentation program on Linux (with ext*) before?

bloodline wrote:

Octocontrabass wrote:SSDs perform wear leveling, so this isn't an issue as long as you follow reasonable SSD usage patterns (e.g. don't completely fill the disk, don't power the disk down when it's idle, use ATA TRIM/SCSI UNMAP when deleting data).

Like so much in the world of computing, most of our systems account for Microsoft and Intel's crappy design decisions

bloodline wrote:Like so much in the world of computing, most of our systems account for Microsoft and Intel's crappy design decisions