On Mon, Apr 13, 2020 at 12:03:29PM -0400, Theodore Y. Ts'o wrote: > On Sun, Apr 12, 2020 at 01:25:49AM -0700, Josh Triplett wrote: > > Package: e2fsprogs > > Version: 1.45.6-1 > > Severity: wishlist > > File: /sbin/e2fsck > > > > With a read-only filesystem and the shared_blocks option set, e2fsck > > allows multiply referenced blocks; however, it doesn't like multiple > > references to inode bitmap blocks or block bitmap blocks. > > I suppose, but I'm not sure it's worth the effort. If the block group > is not used, then we won't have an allocation bitmap at all. And in > other cases, it is highly unlikely that we can share the allocation > bitmap unless 100% of the blocks (or inodes) in that block group are > in use. In that case, we'll save 1/32768, netting a space savings of 0.003%. > > That way we actually create a shared_blocks file system today, the > only thing that can get shared is data blocks --- we keep a hashmap of > each block and its checksum, and so we can easily dedup data blocks. > But for allocation bitmaps, we would need to construct the file system > first, and then dedup all blocks, instead of finding duplicates while > we are writing the file system.
It's a read-only filesystem, so the block allocator and inode allocator will never do any allocations. So I made *all* the block and inode bitmaps point to the same block of FFs, unconditionally.
