On 2017-09-27 20:00, Qu Wenruo wrote:
On 2017年09月28日 00:20, David Sterba wrote:
On Mon, Sep 25, 2017 at 07:15:30AM -0400, Austin S. Hemmelgarn wrote:
On 2017-09-24 10:08, Goffredo Baroncelli wrote:
On 09/24/2017 12:10 PM, Anand Jain wrote:
A lot of points in this thread, let me address them here.
I don't want to remove --rootdir functionality, the fix that's being
proposed removes the minimalization -- feature that was not well known,
but I understand it's useful (and already used).
I'd like to fix that in another way, eg. as an option to mkfs or a
separate tool.
I'm not worried about adding more code or code complexity. If we do it
right it's not a problem in the long run. But people for some reason
like to delete other people's code or functionality.
Regarding guessing number of users, this is always hard. So if there's
one vocal enough to let us know about the usecase, it's IMHO good time
to explore the it, code-wise and documentation-wise, and fix it or
improve.
So, what next. I'd like to get rid of the custom chunk allocator, namely
because of the known 1MB area misuse and duplication.
Implementing the minimalization might need some preparatory work and I
don't have a realistic ETA now.
Well, if using over-reserve-then-shrink method, it could be done,
without much hassle.
It _should_ be possible to compute the exact size required though. As
outlined in one of my other replies, an absolute minimal filesystem
should in theory consist of the following space usage:
1. 1MB (for the reserved space at the beginning).
2. However many superblocks it should have given the size.
3. The total amount of file data and extended attribute data to be
included, rounding up for block size
4. The exact amount of metadata space needed to represent the tree from
3, also rounding up for block size.
5. The exact amount of system chunk space needed to handle 3 and 4, plus
enough room to allocate at least one more chunk of each type (to
ultimately allow for resizing the filesystem if desired).
6. Exactly enough reserved metadata space to resize the FS
(alternatively, the standard space for the GlobalReserve, which should
be enough and then some).
Computing this is non-trivial for a human, and even with a computer
requires knowledge of how the chunk allocator is implemented. mkfs
should have that knowledge though, so in theory it is reasonably well
positioned to just compute this, allocate that much space, and then
generate the filesystem. The complaints I have about trying to do this
manually in two passes are that:
1. Computing the above by hand is not easy.
2. Computing it by hand and then running mkfs on the resultant file
doesn't work most of the time.
As a result, I would think this could easily be handled in the following
steps:
1. Scan the contents of the --rootdir option to determine total size needed.
2. Compute the required allocation and allocate it.
3. Generate the filesystem image.
This has an inherent TOCTOU race, but it's one that a lot of archiving
tools (tar being a prime example) already have, and it's not likely that
people will hit it since you're not likely to be using a changing
directory for --rootdir.
However ETA maybe delayed to middle of Oct, as I'm going to enjoy my
holiday during 1st Oct to 7th Oct.
Entirely understandable, enjoy your time off!
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
