6 ms·

Well, for now is about an year with few machines (personal desktop, home server, laptop and few friends machines) on NixOS, root included [1] issueless. Variou

by xte 8y ago

Well, for now is about an year with few machines (personal desktop, home server, laptop and few friends machines) on NixOS, root included [1] issueless. Various loads, even if not really "high" in server-like terms, very few not-clean shutdowns, mostly for testing, few fs resize (both in grow and shrink senses) + LVM resize [2], regular sync of different desktops via unison + converting in ss (snapshot) the latest cp (checkpoint) and back again after sync. The only real problem I found is cleaner process that's extremely slow so on frequently changing fs like root, home, var etc you need to tweak config a bit [3] to make cleaner far more aggressive or require really big free space to avoid fs full from time to time due to extra cp saved... That's really the sole problem I found. Respect of my ancient zfs-root setup is far lighter and logging is fantastic as a protection against accidental overwrite. Of course it's not as powerful as hammer and it UI is even more raw, for instance to diff a tree or a file you have to manually: - change relevant cp to an ss - mount the ss to an arbitrary location - diff live vol/snap against the other mounted A thing that limit usefulness a bit but considering that in terms of performance and overhead can be compared to a non-buggy btrfs with the overhead of xfs/jfs... It's really worth it! [1] you only need to use a custom iso, something super-easy on NixOS, mine is here http://ix.io/1wIQ http://ix.io/1wIQ the only really important part is boot.supportedFilesystems = [ "nilfs2" ]; boot.initrd.kernelModules = [ "crc32" "nilfs2" ]; you may choose zfs, f2fs, bcachefs, ... [2] simply for grow resize first the LVM lv and after nilfs2, without dimension it grow the maximum free space available; for shrink shrink nilfs2 a bit more than the target size, resize the LVM lv to the new desired size, grow nilfs2 without dimension to occupy the entire LV free space. All operation are live, with mounted fs, it can't be resized otherwise! [3] here http://ix.io/1wIS http://ix.io/1wIS a really aggressive config, that on SSD essentially does not crate any noticeable overhead, on plate disk it make them spin regularly but it's just a matter of noise for desktop usage.

hawski 8y ago
Thank you for your response! I remember that NILFS2 was in the middle order of magnitude in case of bugs from the presentation about filesystems fuzzing from 2016[0]. That certainly makes it more robust than BTRFS, but it's hard to compete against so much tested code like Ext4. Time to first bug: Ext4 2h BUG() Xfs 1h45m Soft lockup Gfs2 8m Double free Ntfs 4m Soft lockup Nilfs2 1m Page Fault Hfs 30s Page Fault Hfsplus 25s Page Fault Reiserfs 25s BUG() Ocfs2 15s BUG() F2fs 10s BUG() Btrfs 5s BUG() [0] https://events.static.linuxfound.org/sites/events/files/slides/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0.pdf https://events.static.linuxfound.org/sites/events/files/slid...
- xte 8y ago
  Your welcome and thanks for the link, I do not know it :-) Generally speaking I prefer experience than testing, no matter how accurate they are, I can't really tell if nilfs2 is rock solid or not due to the too little experience I have, however it's an old (so patched enough) project by a Japan telco that I think use it internally so I feel a bit of trust, the rest is covered by a good and tested backup that can't be left apart in any case and with NixOS/GuixSD even a root fs crash is not a big issue since replicate it's only a matter of copy few (possibly one) text files and let the installer do it's business... So my main point is that nilfs2 it's far lighter than zfs, it's considered safe on GNU/Linux (zfs is not) and it offer a good protection against accidental overwrite/deletion that on a desktop is important for me, even with the best and quickest backup I can imaging... I've probably remained on zfs if nilfs2 was not in kernel officially supported since years but being already there, lightweight enough it's my default choice hoping/dreaming for a different future... The rest of panorama is really bad: - xfs is essentially dead, like jfs - btrfs is a shitload of bugs - zfs can't be integrated and it's considered not production-ready on GNU/Linux - ext* are fs from another era, without nothing of the good things of xfs/jfs - stratis is for now more a dubious dream and not a real solution, only a way to poorly circumvent actual sorry state of storage - bcachefs is a promise, but for now it does not offer anything relevant - f2fs have nice performance but it's a bit buggy IME and it's even more limited than nilfs2 to a point of being unuseful... Outside of GNU/Linux IllumOS (despite it's zombie status) and FreeBSD have a good zfs support, production ready, DragonFlyBSD have hammer, the rest is as worse as Linux world...
  - pmoriarty 8y ago
    Could you elaborate on why you think xfs is dead? I've been using it for a long time and it's been rock solid. It just lacks the features of filesystems like zfs, btrfs, hammer, and bcachefs. But it's also very stable, is a tried and true filesystem, and exists right now on Linux.
    - xte 8y ago
      If I remember correctly at a Vault Conference few years ago Dave Chinner say that xFS codebase while actively maintained should be considered legacy since it's not really possible evolve it anymore and the better way to go is a complete re-design so a new filesystem, a thing that will not happen in xFS upstream... I do not find any transcript now, but looking for it somewhere in the web surely exists :-) So yes, it's rock solid and battle tested, certainly a safe choice respect of btrfs (buggy and not really good in production despite many do not care) or bcachefs (solid, stable, but essentially feature-less in today's implementation) but nothing more... RH and Oracle seems to push it a bit inconstantly but I still have to see any real plan...

by xte 8y ago

hawski 8y ago

Thank you for your response! I remember that NILFS2 was in the middle order of magnitude in case of bugs from the presentation about filesystems fuzzing from 2016[0]. That certainly makes it more robust than BTRFS, but it's hard to compete against so much tested code like Ext4. Time to first bug: Ext4 2h BUG() Xfs 1h45m Soft lockup Gfs2 8m Double free Ntfs 4m Soft lockup Nilfs2 1m Page Fault Hfs 30s Page Fault Hfsplus 25s Page Fault Reiserfs 25s BUG() Ocfs2 15s BUG() F2fs 10s BUG() Btrfs 5s BUG() [0] https://events.static.linuxfound.org/sites/events/files/slides/AFL%20filesystem%20fuzzing%2C%20Vault%202016_0.pdf https://events.static.linuxfound.org/sites/events/files/slid...

xte 8y ago
Your welcome and thanks for the link, I do not know it :-) Generally speaking I prefer experience than testing, no matter how accurate they are, I can't really tell if nilfs2 is rock solid or not due to the too little experience I have, however it's an old (so patched enough) project by a Japan telco that I think use it internally so I feel a bit of trust, the rest is covered by a good and tested backup that can't be left apart in any case and with NixOS/GuixSD even a root fs crash is not a big issue since replicate it's only a matter of copy few (possibly one) text files and let the installer do it's business... So my main point is that nilfs2 it's far lighter than zfs, it's considered safe on GNU/Linux (zfs is not) and it offer a good protection against accidental overwrite/deletion that on a desktop is important for me, even with the best and quickest backup I can imaging... I've probably remained on zfs if nilfs2 was not in kernel officially supported since years but being already there, lightweight enough it's my default choice hoping/dreaming for a different future... The rest of panorama is really bad: - xfs is essentially dead, like jfs - btrfs is a shitload of bugs - zfs can't be integrated and it's considered not production-ready on GNU/Linux - ext* are fs from another era, without nothing of the good things of xfs/jfs - stratis is for now more a dubious dream and not a real solution, only a way to poorly circumvent actual sorry state of storage - bcachefs is a promise, but for now it does not offer anything relevant - f2fs have nice performance but it's a bit buggy IME and it's even more limited than nilfs2 to a point of being unuseful... Outside of GNU/Linux IllumOS (despite it's zombie status) and FreeBSD have a good zfs support, production ready, DragonFlyBSD have hammer, the rest is as worse as Linux world...
- pmoriarty 8y ago
  Could you elaborate on why you think xfs is dead? I've been using it for a long time and it's been rock solid. It just lacks the features of filesystems like zfs, btrfs, hammer, and bcachefs. But it's also very stable, is a tried and true filesystem, and exists right now on Linux.
  - xte 8y ago
    If I remember correctly at a Vault Conference few years ago Dave Chinner say that xFS codebase while actively maintained should be considered legacy since it's not really possible evolve it anymore and the better way to go is a complete re-design so a new filesystem, a thing that will not happen in xFS upstream... I do not find any transcript now, but looking for it somewhere in the web surely exists :-) So yes, it's rock solid and battle tested, certainly a safe choice respect of btrfs (buggy and not really good in production despite many do not care) or bcachefs (solid, stable, but essentially feature-less in today's implementation) but nothing more... RH and Oracle seems to push it a bit inconstantly but I still have to see any real plan...