4 ms·

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 withou

by Syonyk 5y ago

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.

sterwill 5y ago
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?
- actionfromafar 5y ago
  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.
  - cout 5y ago
    How do other filesystems avoid this? It seems like a hard problem in general.
    - formerly_proven 5y ago
      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.
- dale_glass 5y ago
  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.
  - londons_explore 5y ago
    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.
    - kragen 5y ago
      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.
    - j16sdiz 5y ago
      ResierFS allow metadata in everywhere. That’s how they allow sharing a ext2fs and resierfs on same disk during conversion
    - ajsnigrutin 5y ago
      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.
- Syonyk 5y ago
  > 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.
actionfromafar 5y ago
Damn, I was bit by this, I had forgotten about it because it was such a long time ago.
pnutjam 5y ago
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.
- tomjakubowski 5y ago
  what makes xfs better than ext4 as a general purpose filesystem?
  - ak217 5y ago
    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.
- dotancohen 5y ago
  > 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?
  - pnutjam 5y ago
    Mostly legacy. I should convert it.
- kiririn 5y ago
  Lack of support for shrinking in XFS is one reason that regularly comes up for me
andi999 5y ago
This blew my mind. The bug is actually the main intended behaviour.
patrakov 5y ago
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.
- nybble41 5y ago
  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.
  - jml7c5 5y ago
    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.
    - nybble41 5y ago
      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.

by Syonyk 5y ago

sterwill 5y ago

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?

actionfromafar 5y ago
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.
- cout 5y ago
  How do other filesystems avoid this? It seems like a hard problem in general.
  - formerly_proven 5y ago
    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.
dale_glass 5y ago
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.
- londons_explore 5y ago
  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.
  - kragen 5y ago
    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.
  - j16sdiz 5y ago
    ResierFS allow metadata in everywhere. That’s how they allow sharing a ext2fs and resierfs on same disk during conversion
  - ajsnigrutin 5y ago
    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.
Syonyk 5y ago
> 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.

actionfromafar 5y ago

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

pnutjam 5y ago

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.

tomjakubowski 5y ago
what makes xfs better than ext4 as a general purpose filesystem?
- ak217 5y ago
  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.
dotancohen 5y ago
> 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?
- pnutjam 5y ago
  Mostly legacy. I should convert it.
kiririn 5y ago
Lack of support for shrinking in XFS is one reason that regularly comes up for me

andi999 5y ago

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

patrakov 5y ago

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.

nybble41 5y ago
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.
- jml7c5 5y ago
  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.
  - nybble41 5y ago
    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.