4 ms·

Note though that unlike zfs, ext4 has a battle-tested fsck. Combine ext4's dumb but robust approach to journaling and robust metadata layout (for example inode

Note though that unlike zfs, ext4 has a battle-tested fsck. Combine ext4's dumb but robust approach to journaling and robust metadata layout (for example inodes are statically allocated) with fsck.ext4 (which got refined for years) and you can recover from any situation. To give you an example, fsck.ext4 will happily carve a working filesystem out of random data, as long as there is a valid superblock. Seriously - try it yourself: # create a working filesystem image dd if=/dev/zero of=test1.img bs=1M count=256 /sbin/mkfs.ext4 test1.img # write file with random data dd if=/dev/urandom of=test2.img bs=1M count=256 # copy superblock into random file dd if=test1.img of=test2.img bs=1024 count=4 seek=1 skip=1 conv=notrunc /sbin/fsck.ext4 -fy test2.img sudo mount test2.img /mnt/somewhere

mustache_kimono 3y ago
I'm trying to understand what exactly this is testing/demonstrating. Like: "Wow, but why should I care?" I'm not sure being able to fsck a random disk image shows resiliency. Doing this could do all sorts of nasty things to data you actually care about.
- grrandalf 3y ago
  (not the author) The metadata is a contiguous range of disk blocks. I think the intuition is that such layouts are likely to require simpler filesystem code to manipulate. [versus (iirc) ZFS which may have metadata blocks scattered throughout the disk, probably requiring more intricate code to keep track of].
  - mustache_kimono 3y ago
    > [versus (iirc) ZFS which may have metadata blocks scattered throughout the disk, probably requiring more intricate code to keep track of]. So -- you think redundant metadata is a bad thing? Try wiping your metadata and then trying to fsck that random disk image. Again, has this been the source of data corruption you're aware of? This seems like a "Maybe, it could be this way, but I don't know" kind of take.
1000thVisitor 3y ago
> To give you an example, fsck.ext4 will happily carve a working filesystem out of random data What application does this have for recovering user data? Would it not be more interesting to see how much of the user data can be recovered? Or are you implying that the random data can symbolize the user data here and much of it would be recovered?

mustache_kimono 3y ago

I'm trying to understand what exactly this is testing/demonstrating. Like: "Wow, but why should I care?" I'm not sure being able to fsck a random disk image shows resiliency. Doing this could do all sorts of nasty things to data you actually care about.

grrandalf 3y ago
(not the author) The metadata is a contiguous range of disk blocks. I think the intuition is that such layouts are likely to require simpler filesystem code to manipulate. [versus (iirc) ZFS which may have metadata blocks scattered throughout the disk, probably requiring more intricate code to keep track of].
- mustache_kimono 3y ago
  > [versus (iirc) ZFS which may have metadata blocks scattered throughout the disk, probably requiring more intricate code to keep track of]. So -- you think redundant metadata is a bad thing? Try wiping your metadata and then trying to fsck that random disk image. Again, has this been the source of data corruption you're aware of? This seems like a "Maybe, it could be this way, but I don't know" kind of take.

1000thVisitor 3y ago

> To give you an example, fsck.ext4 will happily carve a working filesystem out of random data What application does this have for recovering user data? Would it not be more interesting to see how much of the user data can be recovered? Or are you implying that the random data can symbolize the user data here and much of it would be recovered?