Skip to content

Commit

Permalink
btrfs-progs: docs: inline files vs tail packing
Browse files Browse the repository at this point in the history
Explain the difference, in case somebody want's to use it as a source to
correct that on Wikipedia.

[ ci skip ]

Signed-off-by: David Sterba <dsterba@suse.com>
  • Loading branch information
kdave committed Sep 17, 2024
1 parent f1e02d9 commit 5d9cebc
Showing 1 changed file with 12 additions and 0 deletions.
12 changes: 12 additions & 0 deletions Documentation/Inline-files.rst
Original file line number Diff line number Diff line change
Expand Up @@ -25,3 +25,15 @@ An inline file can be identified by enumerating the extents, e.g. by the tool
In the above example, the file is not compressed, otherwise it would have the
*encoded* flag. The inline files have no limitations and behave like regular
files with respect to copying, renaming, reflink, truncate etc.

.. note::
This is not `tail packing <https://en.wikipedia.org/wiki/Block_suballocation#Tail_packing>`__,
known e.g. from `ReiserFS <https://en.wikipedia.org/wiki/ReiserFS>`__ . The
whole inline file must fit and is stored in the metadata block. Larger files
have their extents stored in blocks and the last one can be underutilized.
With tail packing such blocks would be stored elsewhere out of order,
possibly mixed with other last blocks from other files.

This was an early design decision not to implement it due to experience with
the complexity in ReiserFS and does not seem justified with the possible
space savings in the data blocks but increased metadata to track the packed blocks.

0 comments on commit 5d9cebc

Please sign in to comment.