| |||||||||||||
Improving ext4: bigalloc, inline data, and metadata checksumsImproving ext4: bigalloc, inline data, and metadata checksumsPosted Nov 30, 2011 21:22 UTC (Wed) by mleu (subscriber, #73224)Parent article: Improving ext4: bigalloc, inline data, and metadata checksums As a SLES customer reading these (great) LWN articles just gives me the feeling I'm once again on the wrong side of the filesystem situation.
(Log in to post comments)
Improving ext4: bigalloc, inline data, and metadata checksums Posted Nov 30, 2011 22:11 UTC (Wed) by jospoortvliet (subscriber, #33164) [Link]
Don't worry, btrfs won't be the default let alone only option in SLES anytime soon. Surely will be supported and well integrated with tools like Snapper but it's still a choice.
As a matter of fact, there is work going on to allow use of snapper with Ext4 so SUSE ain't jumping ship there.
Improving ext4: bigalloc, inline data, and metadata checksums Posted Dec 3, 2011 0:25 UTC (Sat) by walex (subscriber, #69836) [Link] Don't worry about SLES. Reiser3 after some initial issues was actually quite robust, and was designed for robustness. If there were issues after the initial shaking down period it was because of the O_PONIES problem that causes so much distrust against ext4 itself, and previously against XFS; but not against JFS because JFS has always had a rather twitchy flushing logic sort of equivalent to the short flushout ext3 has always had. Indeed ext3 got a good reputation mostly just because even when it did not support barriers it had a very short flushing interval etc. which made it seemingly resilient in many cases to sudden power off even for applications that did not issue fsync(2). To some extend it is sad that SLES switched to the ext line, but I guess a large part of it was marketing (it is an
Improving ext4: bigalloc, inline data, and metadata checksums Posted Dec 3, 2011 11:30 UTC (Sat) by mpr22 (subscriber, #60784) [Link] Did anyone ever fix the ReiserFS tools to the point that you could safely fsck a ReiserFS volume that contained an uncompressed ReiserFS image?
deep recovery and embedded filesystem images Posted Dec 3, 2011 17:57 UTC (Sat) by walex (subscriber, #69836) [Link] That's an interesting case. ReiserFS was designed to be very robust in the face of partial data loss, allowing for a reconstruction of the file system metadata from recognizable copies embedded in the files themselves. Thus the contents of an embedded ReiserFS image will look like lost files from the containing filesystem, if the option to reconstruct metadata is enabled. Running man reiserfsck is advised before doing recovery on a damaged ReiserFS image. Paying particular attention to the various mentions of --rebuild-tree may be wise. In other words there is nothing to fix, except a lack of awareness of one of the better features of ReiserFS, or perhaps a lack of a specific warning.
deep recovery and embedded filesystem images Posted Dec 4, 2011 1:05 UTC (Sun) by nix (subscriber, #2304) [Link]
You're the only person I have ever heard call reiserfsck's propensity to fuse disk images into an unholy union with their containing filesystem a *feature*.
I don't think it was ever any part of reiserfsck's design to "reconstruct[] file system metadata from recognizable copies embedded in the files themselves" because nobody ever does that (how many copies of your inode tables do you have written to files in your filesystem for safety? None, that's right). It's more that reiserfsck --rebuild-tree simply scanned the whole partition for things that looked like btree nodes, and if it found them, it assumed they came from the same filesystem, and not from a completely different filesystem that happened to be merged into it -- there was no per-filesystem identifier in each node or anything like that, so they all got merged together.
This is plainly a design error, but equally plainly not one that would have been as obvious when reiserfs was designed as it is now, when disks were smaller than they are today and virtual machine images much rarer.
If you want some real fun, try a reiserfs filesystem with an ext3 filesystem inside it and another reiserfs filesystem embedded in that. To describe what reiserfsck --rebuild-tree on the outermost filesystem does to the innermost two would require using words insufficiently family-friendly for this site (though it is extremely amusing if you have nothing important on the fs).
Rebuild tree a useful feature with side-effects. Posted Dec 8, 2011 4:26 UTC (Thu) by gmatht (guest, #58961) [Link]
I don't think that merging filesystems was meant to be a feature, but rather the rebuild-tree is useful feature that other fscks don't have.
If someone has stored all their precious photos and media files on a disk, and the metadata is trashed, then rebuilding the tree should get them their files back where a regular fsck wouldn't. I wouldn't trust --rebuild-tree not to add random files at the best of times, for example, I understand that it restores deleted files [1] which you probably don't want to do in a routine fsck. If, on the other hand, you've just found out that all your backups are on write-only media, rebuilding a tree from leaves could save you from losing years of work. It would be even better if it didn't merge partitions, but is still better than nothing if used as a last resort.
I think it would also be better if it encouraged you to rebuild the tree onto an entirely new partition.
[1] http://www.linuxquestions.org/linux/answers/Hardware/Reis...
Rebuild tree a useful feature with side-effects. Posted Dec 8, 2011 5:35 UTC (Thu) by tytso (subscriber, #9993) [Link]
The fsck for ext2/3/4 doesn't have this feature because it doesn't need it. One of the tradeoffs of using a dynamic inode table (since in reiserfs it is stored as part of the btree) is if you lose the root node of the file system, you have no choice but to search the entire disk looking for nodes that appear to belong to the file system b-tree.
With ext 2/3/4, we have a static inode table. This does have some disadvantages, but the advantage is that it's much more robust against file system damage, since the location of the metadata is much more predictable.
Improving ext4: bigalloc, inline data, and metadata checksums Posted Dec 12, 2011 16:15 UTC (Mon) by nye (guest, #51576) [Link]
>Did anyone ever fix the ReiserFS tools to the point that you could safely fsck a ReiserFS volume that contained an uncompressed ReiserFS image?
The existing replies have basically answered this, but just to make it clear:
You could always do that.
Reiserfs *additionally* came with an *option* designed to make a last-ditched attempt at recovering a totally hosed filesystem by looking for any data on the disk that looked like Reiserfs data structures and making its best guess at rebuilding it based on that.
Somehow the FUD brigade latched on to the drawbacks of that feature and conveniently 'forgot' that it was neither the only, nor the default fsck method.
Improving ext4: bigalloc, inline data, and metadata checksums Posted Dec 12, 2011 16:46 UTC (Mon) by jimparis (subscriber, #38647) [Link]
In my long-ago experience, reiserfsck --fix-fixable did absolutely nothing to improve a broken filesystem, and --rebuild-tree was the only way to get anything out. Maybe you got very lucky?
Improving ext4: bigalloc, inline data, and metadata checksums Posted Dec 14, 2011 12:15 UTC (Wed) by nye (guest, #51576) [Link]
>Maybe you got very lucky?
Maybe I did. Or maybe you got unlucky. Most of the people commenting on it though *never tried*; they just heard something bad via hearsay and parrotted it, and that just gets to me.
|
|||||||||||||