Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for FIEMAP #7

Closed
wants to merge 2 commits into from
Closed

Conversation

kakra
Copy link
Contributor

@kakra kakra commented Apr 23, 2017

This patch adds support for FIEMAP and leaves the current FIBMAP
approach in place as a fallback. Instead of trying to guess extents from
FIBMAP block maps, it directly uses extents as fragments.

The logic is similar as it merges adjecent extents as one fragment. It
also detects hole extents and inlined extents and doesn't account those
as fragments similar to the FIBMAP approach.

It optimizes handling filesystems with tail support (e.g., reiserfs) by
not accounting tailed extents as fragments, as the rewrite process
probably would tail the last extent again.

Similarily it tries to optimize for file systems that support shared
extents (xfs, btrfs) by not accounting such extents as fragments. This
helps preventing unsharing accused files and thus increasing space
usage. I pretend that keeping shared extents is more important than
continuous extents, as the operation of deduplicating those extents in
the first place is known to fragment those files.

However, if the heuristics decide to shake the file, extents still
become unshared. I have no idea currently how to optimize for that, thus
it is not part of this patch.

This is also part of my integration branch.


This change is Reviewable

This patch adds support for FIEMAP and leaves the current FIBMAP
approach in place as a fallback. Instead of trying to guess extents from
FIBMAP block maps, it directly uses extents as fragments.

The logic is similar as it merges adjecent extents as one fragment. It
also detects hole extents and inlined extents and doesn't account those
as fragments similar to the FIBMAP approach.

It optimizes handling filesystems with tail support (e.g., reiserfs) by
not accounting tailed extents as fragments, as the rewrite process
probably would tail the last extent again.

Similarily it tries to optimize for file systems that support shared
extents (xfs, btrfs) by not accounting such extents as fragments. This
helps preventing unsharing accused files and thus increasing space
usage. I pretend that keeping shared extents is more important than
continuous extents, as the operation of deduplicating those extents in
the first place is known to fragment those files.

However, if the heuristics decide to shake the file, extents still
become unshared. I have no idea currently how to optimize for that, thus
it is not part of this patch.
@kakra
Copy link
Contributor Author

kakra commented Apr 23, 2017

This should fix issue #1.

@kakra
Copy link
Contributor Author

kakra commented Jun 28, 2017

Brice, I think I need to redo this. Something seems to have gone wrong during rebasing the patch:

  1. fragsize in the FIEMAP branch seems to be always zero while looking at the code
  2. the "goto out" block is there twice now

@kakra
Copy link
Contributor Author

kakra commented Jun 28, 2017

Superseded by #16, closing.

@kakra kakra closed this Jun 28, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant