4 ms·

Checksumming is rather not free on today's CPUs unless you use something like xxhash which operates close to RAM speed. Journaling is rather useful because esp

by tscs37 9y ago

Checksumming is rather not free on today's CPUs unless you use something like xxhash which operates close to RAM speed. Journaling is rather useful because especially consumer desktop computers tend to be mistreated and crash a lot. The physical journal in ext4 prevents the worst when stuff gets hairy. Additionally, it does not effectively delete data like ZFS (or rather, make it very very hard to access data) just because a bit was corrupted. I think a user will value their family pictures more than some random text file suddenly having another character somewhere, they will loose data with a checksumming FS on a normal machine. There is no second drive to pull a good copy of the data from. There is one. And you just killed the last picture of grandma. Congrats. >Why waste clock cycles on a journal when you might not need it? Journaling wastes mostly bandwidth and IO, not much CPU and clock cycles. >Roll-back last system-wide update? Done. Backup consistency? Free and vastly simplified. That is indeed something you can do with a CoW system but the tools to achieve this are in my experience not fully mature yet. The same tasks can also be achieved without snapshots at all, NixOS seems to be doing fine. >Backup consistency? Free and vastly simplified. Snapshots are not backups. If you pretend they are you will loose all your data. Snapshots are snapshots. Nothing more and nothing less. Not backups. >But this should be the default for all user-facing machines as well as servers. I've not stated they shouldn't be default, rather, that the end user does not necessarily need them. Though, ZFS is doing a rather poor job on all these tasks, especially disk management on ZFS is a hassle I wouldn't have a typical end user face. I think Bcache FS is a much cleaner and better design than ZFS, which is rather unflexible. But again, I don't see the immediate need for every end user machine to have a checksumming and CoW filesystem, people have been doing fine for years without them and I doubt there is chaos and fire everywhere as you seem to imply. It could be a little bit better but ext4 is a perfectly fine filesystem for production data. If you rely on checksumming and snapshots for your data safety, you're in for a bad time. Proper backups, not snapshots, will beat snapshots any day. Checksums make data inaccessible, a rather bad choice for a user machine. Whoops, I guess those family photos are totally unusuable because 1 bit has corrupted.

heinrich5991 9y ago
>>Backup consistency? Free and vastly simplified. >Snapshots are not backups. If you pretend they are you will loose all your data. The good thing about snapshots it that you can use them as a consistent base for your backup: If you naively copy files over from a running system, you'll get inconsistent data, but if you copy it over from a snapshot, it'll work without taking the system down.
- tscs37 9y ago
  That is fairly obvious, a lot of systems provide snapshot functionality irrelevant of the file system. If you still need snapshots, there are several methods without needing CoW Filesystems, notably LVM and dattobd (both of which I have utilized in the past) Also keep in mind that a pure snapshot from a running system will behave like a system that just crashed, a half written file won't complete the write magically because you have snapshot. If you don't tell postgresql that you're doing snapshots or backups, both will likely corrupt data, doesn't give you anything in that case. Same for desktop systems. You make a snapshot of the runnign system and suddenly the browser only finds corrupted settings because a write wasn't complete until after the snapshot.
  - Dylan16807 9y ago
    If postgresql corrupts your data upon sudden halt you have far bigger problems to worry about. And as far as I know most software acts responsibly with files, either writing out the new version to a temp file or using sqlite. Both of which are atomic-snapshot-safe.
    - tscs37 9y ago
      You might still loose partial datasets (especially when the database is not 100% perfectly constrained) and not all software handles such sudden halts perfectly. Making a snapshot of any working dataset of any software without the data corrupting or loosing parts of the working set is a pipedream.
- X86BSD 9y ago
  Yeah I somewhat understand the phrase "snapshots are not backups". But what really constitutes a "backup" ? Because I argue snapshots are backups. I snapshot a dataset. And use ZFS send/recv to a remote ZFS server of the dataset snapshot. Is that not a backup? I argue it is. If the original dataset is completely trashed I simply send/recv again the remote snapshot of that dataset back to the primary server. Plus you can update with incremental send/recv as well. I simply don't need tapes. I suppose for archival purposes one might want a tape copy somewhere. But even tapes are problematic. They degrade, get chewed up, etc. There are fewer variables with digital data for me personally.
tjoff 9y ago
I've explicitly said that snapshots HELPS with backups, not that they are backups. Just because a checksum doesn't match and you don't have redundant copies doesn't mean you throw away data (hint: you don't in practice either). I think a user would rather know about corruption rather than, ehm, not. Depending on FS you can also disable checksumming, happy?
- tscs37 9y ago
  I'm not aware of ZFS letting you access corrupted files that easily, the Oracle manual [1] notes that files can only be recovered from backup or removed, not how to access a file that has been corrupted. So this does seem to imply that ZFS does indeed throw away data if it's corrupted. Of course a user would rather know about corruption, but on the average user system with family pictures, you don't run into problems even after years to my experience. The photos function perfectly fine with minor corruption, which as noted above, does not work on ZFS since on ZFS it's either perfect or repairable or lost. >I've explicitly said that snapshots HELPS with backups, not that they are backups. You can do Snapshots on other FS' too, LVM and dattobd allow Snapshots of Blockdevices fairly easily. So I still don't see why that makes ZFS superior to ext4 when you can simply layer the solution underneath. Also, btw, LVM has RAID1 and RAID6, both of which allow the user to detect data corruption on any filesystem, which IMO, is better than restricting to one filesystem. That way you can make an image of an old FAT16 device and be assured that it won't suddenly corrupt data. Same goes for mdraid and snapraid, the later of which is a file-based solution and allows recovery of data beyond loosing all parity of an array plus additional drives. ZFS does to my knowledge not work well once you loose more than it tolerates. Why choose ZFS when I can layer the solution together? Or rather, layer until a FS with a better underlying design comes around. [1]: https://docs.oracle.com/cd/E26505_01/html/E37384/gbbbc.html https://docs.oracle.com/cd/E26505_01/html/E37384/gbbbc.html
  - tjoff 9y ago
    LVM and dattobd are not equivalent and only have some overlap in usability and often come with severe limitations and implications in practice. ZFS is targeted towards the enterprise and such is adapted for that use case. I agree that it isn't perfect for home users and I'm not advocating that ZFS be the acceptable solution. I'm just stating that Linux does not have a decent general purpose filesystem. There is nothing that says that a checksum mismatch results in data loss, that statement is absurd. ZFS has the stance that you should not work on corrupted data as that will result in further corruption when action are based upon it. I tend to agree with that approach, but ZFS will not remove the data it finds corrupted. You can also layer a more traditional filesystem upon ZFS to leverage redundancy, checksumming and snapshots, something that mdadm does not provide. There are very good reasons for why a layered approach isn't nearly as flexible, this was controversial at the time and debated alot a decade ago. Most RAID solutions don't even verify the data when read from normal operations. A checksummed approach is a significant improvement, in combination with redundant information you can automatically recover - something that is hard to do in a layered approach. Also, with with a checksum you can verify the correct result. With raid 5 or degraded raid 6 you can at best know that an error has occured but not fix it. Again something that a layered approach has issues with (even if the filesystem had checksumming the RAID controller/software wouldn't know or be able to act upon it).

by tscs37 9y ago

heinrich5991 9y ago

>>Backup consistency? Free and vastly simplified. >Snapshots are not backups. If you pretend they are you will loose all your data. The good thing about snapshots it that you can use them as a consistent base for your backup: If you naively copy files over from a running system, you'll get inconsistent data, but if you copy it over from a snapshot, it'll work without taking the system down.

tscs37 9y ago
That is fairly obvious, a lot of systems provide snapshot functionality irrelevant of the file system. If you still need snapshots, there are several methods without needing CoW Filesystems, notably LVM and dattobd (both of which I have utilized in the past) Also keep in mind that a pure snapshot from a running system will behave like a system that just crashed, a half written file won't complete the write magically because you have snapshot. If you don't tell postgresql that you're doing snapshots or backups, both will likely corrupt data, doesn't give you anything in that case. Same for desktop systems. You make a snapshot of the runnign system and suddenly the browser only finds corrupted settings because a write wasn't complete until after the snapshot.
- Dylan16807 9y ago
  If postgresql corrupts your data upon sudden halt you have far bigger problems to worry about. And as far as I know most software acts responsibly with files, either writing out the new version to a temp file or using sqlite. Both of which are atomic-snapshot-safe.
  - tscs37 9y ago
    You might still loose partial datasets (especially when the database is not 100% perfectly constrained) and not all software handles such sudden halts perfectly. Making a snapshot of any working dataset of any software without the data corrupting or loosing parts of the working set is a pipedream.
X86BSD 9y ago
Yeah I somewhat understand the phrase "snapshots are not backups". But what really constitutes a "backup" ? Because I argue snapshots are backups. I snapshot a dataset. And use ZFS send/recv to a remote ZFS server of the dataset snapshot. Is that not a backup? I argue it is. If the original dataset is completely trashed I simply send/recv again the remote snapshot of that dataset back to the primary server. Plus you can update with incremental send/recv as well. I simply don't need tapes. I suppose for archival purposes one might want a tape copy somewhere. But even tapes are problematic. They degrade, get chewed up, etc. There are fewer variables with digital data for me personally.

tjoff 9y ago

I've explicitly said that snapshots HELPS with backups, not that they are backups. Just because a checksum doesn't match and you don't have redundant copies doesn't mean you throw away data (hint: you don't in practice either). I think a user would rather know about corruption rather than, ehm, not. Depending on FS you can also disable checksumming, happy?

tscs37 9y ago
I'm not aware of ZFS letting you access corrupted files that easily, the Oracle manual [1] notes that files can only be recovered from backup or removed, not how to access a file that has been corrupted. So this does seem to imply that ZFS does indeed throw away data if it's corrupted. Of course a user would rather know about corruption, but on the average user system with family pictures, you don't run into problems even after years to my experience. The photos function perfectly fine with minor corruption, which as noted above, does not work on ZFS since on ZFS it's either perfect or repairable or lost. >I've explicitly said that snapshots HELPS with backups, not that they are backups. You can do Snapshots on other FS' too, LVM and dattobd allow Snapshots of Blockdevices fairly easily. So I still don't see why that makes ZFS superior to ext4 when you can simply layer the solution underneath. Also, btw, LVM has RAID1 and RAID6, both of which allow the user to detect data corruption on any filesystem, which IMO, is better than restricting to one filesystem. That way you can make an image of an old FAT16 device and be assured that it won't suddenly corrupt data. Same goes for mdraid and snapraid, the later of which is a file-based solution and allows recovery of data beyond loosing all parity of an array plus additional drives. ZFS does to my knowledge not work well once you loose more than it tolerates. Why choose ZFS when I can layer the solution together? Or rather, layer until a FS with a better underlying design comes around. [1]: https://docs.oracle.com/cd/E26505_01/html/E37384/gbbbc.html https://docs.oracle.com/cd/E26505_01/html/E37384/gbbbc.html
- tjoff 9y ago
  LVM and dattobd are not equivalent and only have some overlap in usability and often come with severe limitations and implications in practice. ZFS is targeted towards the enterprise and such is adapted for that use case. I agree that it isn't perfect for home users and I'm not advocating that ZFS be the acceptable solution. I'm just stating that Linux does not have a decent general purpose filesystem. There is nothing that says that a checksum mismatch results in data loss, that statement is absurd. ZFS has the stance that you should not work on corrupted data as that will result in further corruption when action are based upon it. I tend to agree with that approach, but ZFS will not remove the data it finds corrupted. You can also layer a more traditional filesystem upon ZFS to leverage redundancy, checksumming and snapshots, something that mdadm does not provide. There are very good reasons for why a layered approach isn't nearly as flexible, this was controversial at the time and debated alot a decade ago. Most RAID solutions don't even verify the data when read from normal operations. A checksummed approach is a significant improvement, in combination with redundant information you can automatically recover - something that is hard to do in a layered approach. Also, with with a checksum you can verify the correct result. With raid 5 or degraded raid 6 you can at best know that an error has occured but not fix it. Again something that a layered approach has issues with (even if the filesystem had checksumming the RAID controller/software wouldn't know or be able to act upon it).