[BSDobelix]

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]

> 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.

[josephcsible]

Doesn't "chattr +C" give you back that performance, while still letting you keep the rest of the benefits of Btrfs?

[curt15]

Nodatacow is an ugly hack because it disables btrfs's core features for the affected data. It also should not be used with raid1.

[BSDobelix]

Yeah and maybe additionally you want to keep your data and have a stable filesystem for them ;)

[yjftsjthsd-h]

> 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]

Without any problems. No other Filesystem i tested has that problem (ext4, XFS, ZFS, NTFS, JFS, Nilfs2)

[yjftsjthsd-h]

Good 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.