3 ms·
So a year ago i tried to repeat my old trick damaging btrfs (as a user NOT root). Fill the volume with dd if=/dev/urandom of=./file bs=2M && sync && rm ./file t
by BSDobelix 2y ago
So a year ago i tried to repeat my old trick damaging btrfs (as a user NOT root). Fill the volume with dd if=/dev/urandom of=./file bs=2M && sync && rm ./file then reboot the machine and yes it still works, it's not booting anymore, bravo.
BTW: Even SLES SuseLinux Enterprise says use XFS for data btrfs just for the OS i wonder why
- PlutoIsAPlanet 2y ago> BTW: Even SLES SuseLinux Enterprise says use XFS for data btrfs just for the OS i wonder why Because XFS is far quicker for server-related software such as databases and virtual machines, which are weak points on btrfs due to its COW model.
- deleted 2y ago[deleted]
- BSDobelix 2y agoYeah and maybe additionally you want to keep your data and have a stable filesystem for them ;)
- josephcsible 2y agoDoesn't "chattr +C" give you back that performance, while still letting you keep the rest of the benefits of Btrfs?
- curt15 2y agoNodatacow is an ugly hack because it disables btrfs's core features for the affected data. It also should not be used with raid1.
- yjftsjthsd-h 2y ago> So a year ago i tried to repeat my old trick damaging btrfs (as a user NOT root). Fill the volume with dd if=/dev/urandom of=./file bs=2M && sync && rm ./file then reboot the machine and yes it still works, it's not booting anymore, bravo. Do you know how ZFS handles that?
- BSDobelix 2y agoWithout any problems. No other Filesystem i tested has that problem (ext4, XFS, ZFS, NTFS, JFS, Nilfs2)
- yjftsjthsd-h 2y agoGood to hear:) My understanding is that it's easier to break a CoW filesystem like that because if you run out of space you can't even delete things (because that requires writing that change), so I'm not surprised that the rest (the non-CoW filesystems) did fine, but I'm happy to hear that ZFS also handles it.