Suggest the "best" FS

[AlfaOmega08]

I know that it's impossible to say which file system is the best, as each one will provide goods and bads.
Anyway I'm building an OS which will run on a machine which will be used like a NAS. So there will be huge amount of reads and (hopefully) not so many writes, encryption would be a Good-To-Have thing, support quite big files (not less than 128 Gb - hd movies and BR games backups). Low fragmentation would be great. It doesn't need to be supported by GRUB, as mine will be the only OS on the machine, so I'll write a boot loader for it. But it has to be very, very fast at reading.

As I started thinking about FS, the first thing in my mind was to throw FAT and NTFS away, FAT because it just su**s, and NTFS, even if it might be a quite good one, it's too poorly documented. Ext seems reasonable, but as I read on Wikipedia, it's slower compared to Raiser4 (which looks discontinued) or Btrfs. What about XFS?

Any suggestion is very well appreciated.

[brain]

Reiserfs might do the job, but it might also kill your wife sorry bad pun. on a more serious note I think this is partially why its now unmaintained...

[rdos]

The best FS to implement is probably FAT, since almost everything supports it. OTOH, FAT is terrible in many regards, like for instance needing "clean-up" tools and things like that. FAT is also not very good on large drives.

[amd64pager]

I have designed one FS....
features:
has a crc maintained internally
has a access control list
built for huge files(names can be huge too,maybe a whole sector?)
cons:
never had an implementation

If you want the specification,I can hand it over to you.

[brain]

while on the subject of cleanup tools, beware of some things regarding reiser, at least version 3.

I used reiser 3 for quite some time on linux and i never will use it or any later version ever again. My friends told me it was amazing in performance and reliable etc. Well one day my system powered off unexpectedly due to power failure and upon powering back up i had a software disk error, e.g. corrupted filesystem.

So i ran fsck on the disk and it gave up 40 minutes later, saying something like:

fsck.reiser cant fix this disk. only a certain subset of errors in the inode tree can be fixed. if you want to you can call our premium support line on <blah> which is charged at $3 per minute.

Needless to say, i went to my backup cursing reiser and never ever used it again.

If you are implementing it, be aware of these reliability issues and code a BETTER recovery tool!!!

[rdos]

I have designed one FS....
features:
has a crc maintained internally
has a access control list
built for huge files(names can be huge too,maybe a whole sector?)
cons:
never had an implementation

If you want the specification,I can hand it over to you.

No, I don't want access control lists. FSes with such are out-of the question.

[rdos]

while on the subject of cleanup tools, beware of some things regarding reiser, at least version 3.

I used reiser 3 for quite some time on linux and i never will use it or any later version ever again. My friends told me it was amazing in performance and reliable etc. Well one day my system powered off unexpectedly due to power failure and upon powering back up i had a software disk error, e.g. corrupted filesystem.

So i ran fsck on the disk and it gave up 40 minutes later, saying something like:

fsck.reiser cant fix this disk. only a certain subset of errors in the inode tree can be fixed. if you want to you can call our premium support line on <blah> which is charged at $3 per minute.

Needless to say, i went to my backup cursing reiser and never ever used it again.

If you are implementing it, be aware of these reliability issues and code a BETTER recovery tool!!!

I would prefer a FS that never needs recovery, regardless of when I turn-off my computer. I designed such a FS 5-10 years ago, that also was optimized for flash-based hardware (not reusing sectors, rather circulating them). The only problem was that I never got my driver to work. It was too complex for an assembler-based device-driver with the grade of debug-tools I had back then.

[amd64pager]

No, I don't want access control lists. FSes with such are out-of the question.

You can disable the access control lists then.

[rdos]

No, I don't want access control lists. FSes with such are out-of the question.

You can disable the access control lists then.

What exactly is the point of ACLs if you can multiboot the machine with an OS that supports the FS but not the ACLs?

[bluemoon]

I would prefer a FS that never needs recovery, regardless of when I turn-off my computer. I designed such a FS 5-10 years ago, that also was optimized for flash-based hardware (not reusing sectors, rather circulating them). The only problem was that I never got my driver to work. It was too complex for an assembler-based device-driver with the grade of debug-tools I had back then.

You are aware that, recovery is an option when multiple redundancy copies does not match.
It can be done automatically, even without user knowing what has been done - you may place recovered files on desktop, but it's a good to have feature.

[bluemoon]

Some system uses ACL as key for "one-way" decryption, unless you have a supercomputer to crack it.

[rdos]

Some system uses ACL as key for "one-way" decryption, unless you have a supercomputer to crack it.

Might be so, but the users lists probably is in an ordinary file. If the ACL-less OS knows about the ACL-using OS ways of handling these ACL, it could simulate everything, including user login, and just discard any restrictions setup. Unless the file contents use keys that include the passwords, but then you cannot change passwords without recrypting file contents.

It would be really nice to have a couple of these ACL-using filesystems in RDOS, and just multiboot to be able to read anything without restrictions.

[rdos]

You are aware that, recovery is an option when multiple redundancy copies does not match.
It can be done automatically, even without user knowing what has been done - you may place recovered files on desktop, but it's a good to have feature.

The thing is there is no desktop, and no user that can run diagnostic utilities when the FS becomes corrupt. A corrupt FS means somebody must create a new disk-image and drive to the site, which costs a lot of money. I therefore partition the disk in two parts: Boot partition and application partition. The application partition can be recreated without any adverse effects, and then all the files would be fetched from a FTP-server on the Internet. You can delete the application partition from a systems menu and restart.

[OSwhatever]

I would prefer a FS that never needs recovery, regardless of when I turn-off my computer. I designed such a FS 5-10 years ago, that also was optimized for flash-based hardware (not reusing sectors, rather circulating them). The only problem was that I never got my driver to work. It was too complex for an assembler-based device-driver with the grade of debug-tools I had back then.

The wear leveling should be in flash translation layer rather than the FS I think. The FS should be media agnostic and only work on blocks. Most FS has some kind of journaling that will be used if for example the power was lost.

[rdos]

I would prefer a FS that never needs recovery, regardless of when I turn-off my computer. I designed such a FS 5-10 years ago, that also was optimized for flash-based hardware (not reusing sectors, rather circulating them). The only problem was that I never got my driver to work. It was too complex for an assembler-based device-driver with the grade of debug-tools I had back then.

The wear leveling should be in flash translation layer rather than the FS I think. The FS should be media agnostic and only work on blocks. Most FS has some kind of journaling that will be used if for example the power was lost.

The FS combined wear leveling and crash-security in one. It did this by always writing new data to new sectors, and keeping the old data until reuse started. The FS also supported block-mode erase operations so it could be run on raw flash-devices, and not just emulations like IDE or SATA.

Found a very rudimentary specification: http://www.rdos.net/rdos/flashdisc.htm

I've also "designed" another FS, but this was at an even more basic level, and I never finsihed some necesary things with that FS (and never even came close to a working device-driver): http://www.rdos.net/rdos/rdfs.htm