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.
Do you have a use case where you really do want to create a new way of
creating a shared_blocks file system where the 0.003% savings is
worthwhile?
- Ted
