Hacker News Reader

Comment by Syonyk | Hacker News Reader

It's great for small files, but it's also got some really nasty little corner cases. You do not store ReiserFS filesystem images on ReiserFS filesystems without encryption, or the next time you run fsck, you'll end up with the two filesystems oddly merged into something entirely useless. I'm not sure if that's been fixed, I got a bit tired of the exotica for general daily driver systems, and ext3/ext4 cover my needs well enough.

I'm not sure btrfs is a sane replacement, though. It's exceedingly complex, and I try to avoid needless complexity where possible.

View on HN

That's one heck of an edge case! How does fsck manage to completely confuse filesystem metadata and data like this? Surely this is only if there's corruption in the (outer) filesystem, right?

No, the meta-data is somehow distributed and fsck can pick up pieces of it. I don't think you have to encrypt the image to avoid the edge case, a compress of the image should be enough. It still sucks though.

How do other filesystems avoid this? It seems like a hard problem in general.

Many other filesystems have one or more arrays for metadata. Sometimes these are formatted like files themselves. So a tool to recover it only has to guess at those contiguous arrays, instead of considering essentially any block metadata.

I think it was the --rebuild-tree argument, which as I understand tries to fix an otherwise completely broken filesystem by searching for anything that looks like metadata and gluing it back together.

I've not looked at reiserfs in many years though, so I could be mis-remembering here.

Seems like something pretty fixable too... Only scan areas of the disk which aren't part of already valid filesystem structures, including the users files.

ResierFS allow metadata in everywhere. That’s how they allow sharing a ext2fs and resierfs on same disk during conversion

And then the user deletes that file, and it's not a part of a file anymore, but is still stored somewhere on a disk.

It's kind of the point of fsck that it scans areas of the disk which aren't part of already valid filesystem structures. It's what you run when your filesystem structure is invalid in order to recover as much as you can.

> That's one heck of an edge case!

Yeah... especially if you tend to back up systems when you're rebuilding or replacing them by just backing up the whole disk. It's got everything, you can mount it as a loop device (which you can't do with a compressed image as someone else mentions), etc. I've got a lot of random filesystem images around, and once I trashed a fs entirely with Reiser images on Reiser, I was done with it.

I feel like you really need to have a reason to use ext3/4. I stick to xfs for daily stuff and btrfs if I want any sort of extra functionality. It's super stable in basic configs.

For example, I have a /data drive formated xfs, then I mount a /backup formated btrfs, rsync the 2, take a btrfs snapshot, and unmount /backup.

what makes xfs better than ext4 as a general purpose filesystem?

xfs dynamically allocates inode storage space. A very typical failure scenario of ext4 is to run out of inode quota while there are plenty of free blocks available. This scenario is not possible with xfs. This alone makes it more dependable than ext4 in practice.

There used to be major performance variances where xfs was better in certain workloads and ext4 in others, but those appear to have been smoothed out and now their performance seems very similar across all workloads.

  > For example, I have a /data drive formated xfs, then I mount a /backup formated btrfs, rsync the 2, take a btrfs snapshot, and unmount /backup.

I also unmount the backup drive(s) when not in use, but I'm just cp'ing the important directories from one ext4 filesystem to another. I'd consider btrfs or xfs for general use, I'd love to know why you choose xfs for everyday use. Sure, it's better than ext4, but why not btrfs all around?

Mostly legacy. I should convert it.

Lack of support for shrinking in XFS is one reason that regularly comes up for me

What use case regularly shrinks file systems? Not doubting, curious!

I once formatted an external drive with xfs, wanted to repurpose some of the space to be readable on Windows, found out you couldn't resize xfs, reformatted the drive as exfat (lol you can't resize that either), and lost my last copy of some past files.

From the same standpoint, btrfs is not sane either. You cannot dd it to a different block device, even when unmounted. When the kernel sees two btrfs filesystems with the same UUID on two different block devices, it thinks they are one filesystem, and corrupts both.

The difference is that you can easily edit the UUID of a btrfs filesystem with `btrfstune -U` immediately after making the copy so the filesystems are unique again. You need to do this anyway if you have mount rules based on the UUID, regardless of the filesystem type, or you run the risk of mounting the wrong device. It is also possible to tell btrfs which devices make up a particular filesystem with the device= mount option, which ought to bypass the default grouping based on the UUID.

Can one wait indefinitely before running `btrfstune -U`? The "immediately" in your comment makes it sound like a racy/flaky workaround, assuming you are referring to immediacy in time.

You can wait until just before the next time the device is scanned for filesystems, or perhaps when the next btrfs filesystem is mounted. Beyond that it will start to cause problems.

Damn, I was bit by this, I had forgotten about it because it was such a long time ago.

This blew my mind. The bug is actually the main intended behaviour.

Reply on news.ycombinator.com