What filesystem will/should Pyra have for root FS?

[Silent-Hunter]

Apologies if I shouldn't be asking this, it was discussed in another thread but I thought it should have its own.

What root filesystem should the Pyra use by default? Ext4 isn't very nice for flash memory, is it? I was thinking F2FS, but I dunno how mature it is.

 

[levi]

The Pandora's seems to have been UBIFS. That still seems a reasonable choice for flash formatting, as far as I read it, but I don't know what debian's stance is on the various flash-optimised filesystems, which may have an influence.

 

[rygD]

I learned something here today. Now I need to go look into things so I can have an opinion. Thanks for making my day, guys.

 

[Letalis Sonus]

Pandora -> raw flash, ext4 and F2FS are not an option
Pyra -> HW FTL turns flash into a block based device, UBIFS is not an option

 

[Silent-Hunter]

The Pandora's seems to have been UBIFS. That still seems a reasonable choice for flash formatting, as far as I read it, but I don't know what debian's stance is on the various flash-optimised filesystems, which may have an influence.

UBIFS only works on raw flash devices, without a flash transition layer. The eMMC in the Pyra is more like an SD card, so things like UBIFS won't work on it.

 

[ingoreis]

??
I would prefer the fastest of these

 

[Caine]

FAT32, what else

[edit]This is not a serious proposal[/edit]

 

[levi]

exFAT is microsoft's filesystem for flash based block devices (SD cards, SSDs and so on). Now I don't know what the actual difference between exFAT and FAT32 is (linux seems to mount them both the same), but I understand in MS nomenclature you want exFAT, not FAT32.

UBIFS only works on raw flash devices, without a flash transition layer. The eMMC in the Pyra is more like an SD card, so things like UBIFS won't work on it.

Ah, so we want something for block devices. I guess since we're no super-tight on space we want journalling and other stuff I don't really understand like extents, so something like btrFS would fit the bill, and maybe it being copy-on-write based would actually be helpful, if people want to extend it onto SD card or something.

 

[Letalis Sonus]

so something like btrFS would fit the bill

I've had enough issues with lost/emtpy files due to power loss and the filesystem driver going rampage after resuming from standby - you really don't want a beta file system on a device with increased exposure to such situations.

ext4 is fine, fast and stable, the only missing feature that would be interesting is transparent compression, zstd would surely be able provide quite a boost in performance.

 

[levi]

Oh, is btrFS still in beta? Blimey, that feels like a long enough gestation. Not that I actually use it myself yet, but I was thinking for my next format I might give it a try. I'm everywhere ext4 now (apart from one stick I use to transfer stuff from windows, although these days I mostly transfer that stuff over a cifs mount).

 

[Silent-Hunter]

We don't want anything that will journal, it wears out flash devices quickly. The reason I suggested F2FS is it's specifically designed for flash based media.

 

[Letalis Sonus]

We don't want anything that will journal, it wears out flash devices quickly.

You may want to read Ted Ts'o's opinion on that matter. Additionally, most modern flash devices die due to their controller, not because they run out of write cycles.

F2FS has a journal as well. Its optimizations primarily target the physical layout of flash memory and especially the typical behavior of FTLs, mostly to improve performance - actively minimizing meta-data write accesses was not a priority. You actually have to manually tailor its parameters to fit to the characteristics of your flash chips and FTL or you'll lose most of its flash-related benefits - which is a PITA because you usually do not get the information required to do so. This LWN article has some more detailed information about its inner workings.

 

[Silent-Hunter]

Ahh okay, so it doesn't really matter what we use then?

 

[Grench]

Ahh okay, so it doesn't really matter what we use then?

Personally I found that EXT2 performed the best on cards on the Pandora - so I plan to use it on the microSDXC in the Pyra. The eMMC will probably be left with whatever EvilDragon, hns, notaz & others (sorry mind blank on the rest of the development names) decide is best to format it to.

 

[Silent-Hunter]

That's why I made this thread, I wanted to ask what filesystem was best to use.

 

[ible]

i'll probably be boring and use ext4. fast (enough), stable, don't have to think about it.

 

[NetBLOKS]

i'll probably be boring and use ext4. fast (enough), stable, don't have to think about it.

Ext4 has my vote too.
It's the de facto standard on debian or Linux local FS in general.
The eMMC should be intelligent enough to expose the least used blocks to the FS for writing, so no harm there.
And even if journaling would mean that my SD card dies faster, I don't want to miss a journal to safe my ass after power failure or system crashes (the Pyra software will be quite buggy at start I suppose).

 

[Silent-Hunter]

You may want to read Ted Ts'o's opinion on that matter. Additionally, most modern flash devices die due to their controller, not because they run out of write cycles.

F2FS has a journal as well. Its optimizations primarily target the physical layout of flash memory and especially the typical behavior of FTLs, mostly to improve performance - actively minimizing meta-data write accesses was not a priority. You actually have to manually tailor its parameters to fit to the characteristics of your flash chips and FTL or you'll lose most of its flash-related benefits - which is a PITA because you usually do not get the information required to do so. This LWN article has some more detailed information about its inner workings.

So will anyone know the FTL info for the eMMC we're using in the Pyra? If not, I suppose F2FS is out.