4 ms·

A side question somewhat related to the theme: What features of ZFS can't be achieved with ext4 on top of LVM? I see lots of people longing for full disk encryp

A side question somewhat related to the theme: What features of ZFS can't be achieved with ext4 on top of LVM? I see lots of people longing for full disk encryption, mirroring, snapshots or foreign hard disk consolidation, all of which seem doable with ext4+LVM.

X-Istence 12y ago
Full end to end checksumming. ZFS can find and correct errors on the fly, and can ensure data integrity. Even on a single disk ZFS can notify the user what files have been damaged and should be restored from backup. That is the most important thing for me, I want to make sure that my data is safe.
- stefantalpalaru 12y ago
  This is only guaranteed with ECC RAM, right?
  - X-Istence 12y ago
    Without ECC RAM it is entirely possible that upon reading a file may be marked as damaged when it is not, and it is entirely possible ZFS may write a file that has a bit flipped to disk (this one is silent and unrecoverable). While there is a chance, it is unlikely. In my case my zpool's have always given me early warning when one of my hard drives was having issues, even before SMART or anything else started showing warnings. Due to having multiple backups (desktop machine backs up to 2 different networked machines, and it is checksummed end to end) I haven't found any silent data corruption while writing data on any of my zpool's even without ECC RAM. There is no file system that can protect against corruption if a bit is flipped in memory while reading from/writing to disk, at least with ZFS it can warn me and re-read the data from disk and give the upper layers a valid file. Even without ECC RAM ZFS's end-to-end checksumming can help save your data and give you piece of mind that it is not silently being corrupted once it's on disk.
  - Freaky 12y ago
    As an anecdotal data point, I see ECC corrections much, much more often than ZFS CKSUM errors. If you're in any way concerned about bitrot, ECC memory should be the first thing you go for regardless of your choice of filesystem.
Freaky 12y ago
Snapshots with LVM still imply a relatively costly(?) quiescing of the filesystem for however long it takes to complete pending writes and perform the snapshot. This is certainly my experience with snapshots on UFS2 - they're supported, but you're not going to be too pleased performing them automatically from a cronjob every 15 minutes. Snapshots can also be promoted to fully-fledged filesystems using cloning, which is very handy for spawning off fully-featured jail environments and for setting up boot environments for a host. Filesystem replication. My primary backups involve using `zfs send` to maintain remote copies of my snapshots on another machine with minimal cost in bandwidth and disk IO. Filesystem compression. My root pool is just 0.63x the size it would have been thanks to lz4, basically for free. As X-Isence says, end-to-end data protection. Every bit of data and metadata are checksummed so any errors are detected, and if possible automatically repaired. Crucial metadata is duplicated even on single-disk configurations. Copy-on-write semantics make for more robustness in face of problems - active data is never overwritten in-place. This also makes for much safer parity RAID than traditional approaches.

X-Istence 12y ago

Full end to end checksumming. ZFS can find and correct errors on the fly, and can ensure data integrity. Even on a single disk ZFS can notify the user what files have been damaged and should be restored from backup. That is the most important thing for me, I want to make sure that my data is safe.

stefantalpalaru 12y ago
This is only guaranteed with ECC RAM, right?
- X-Istence 12y ago
  Without ECC RAM it is entirely possible that upon reading a file may be marked as damaged when it is not, and it is entirely possible ZFS may write a file that has a bit flipped to disk (this one is silent and unrecoverable). While there is a chance, it is unlikely. In my case my zpool's have always given me early warning when one of my hard drives was having issues, even before SMART or anything else started showing warnings. Due to having multiple backups (desktop machine backs up to 2 different networked machines, and it is checksummed end to end) I haven't found any silent data corruption while writing data on any of my zpool's even without ECC RAM. There is no file system that can protect against corruption if a bit is flipped in memory while reading from/writing to disk, at least with ZFS it can warn me and re-read the data from disk and give the upper layers a valid file. Even without ECC RAM ZFS's end-to-end checksumming can help save your data and give you piece of mind that it is not silently being corrupted once it's on disk.
- Freaky 12y ago
  As an anecdotal data point, I see ECC corrections much, much more often than ZFS CKSUM errors. If you're in any way concerned about bitrot, ECC memory should be the first thing you go for regardless of your choice of filesystem.

Freaky 12y ago

Snapshots with LVM still imply a relatively costly(?) quiescing of the filesystem for however long it takes to complete pending writes and perform the snapshot. This is certainly my experience with snapshots on UFS2 - they're supported, but you're not going to be too pleased performing them automatically from a cronjob every 15 minutes. Snapshots can also be promoted to fully-fledged filesystems using cloning, which is very handy for spawning off fully-featured jail environments and for setting up boot environments for a host. Filesystem replication. My primary backups involve using `zfs send` to maintain remote copies of my snapshots on another machine with minimal cost in bandwidth and disk IO. Filesystem compression. My root pool is just 0.63x the size it would have been thanks to lz4, basically for free. As X-Isence says, end-to-end data protection. Every bit of data and metadata are checksummed so any errors are detected, and if possible automatically repaired. Crucial metadata is duplicated even on single-disk configurations. Copy-on-write semantics make for more robustness in face of problems - active data is never overwritten in-place. This also makes for much safer parity RAID than traditional approaches.