Hi Chris,
first off, thank you for the detailled explanations!
On 2016-08-26 01:04, Chris Murphy wrote:
No, it's not a file, directory or subvolume specific command. It
applies to a whole volume.
You are right, but all I was after in the first place was a way to
change the mode for new data on the whole volume.
But I understand now that there is no simple switch for that. (And to be
honest it's not overly important, I was just being curious.)
If I add another file, I'll get another data chunk allocated, and
it'll be added to the chunk tree as item 5, and it'll have its own
physical offset on each device.
And this chunk just uses the same profile as the last one (or the parent
in the tree), I suppose.
So the point now is, in order to change the profile of a chunk, it has
to be completely rewritten.
That makes sense.
To do what you want is planned, with no work picked up yet as far as I
know. It'd probably involve some work to associate something like an
xattr to let the allocator know which profile the user wants for the
data, and then to allocate it to the proper existing chunk or create a
new chunk with that profile as needed.
I see.
I think it would be very nice to have something like that for the
different compression modes. For example, use LZ4 for daily use but LZMA
for the subvolume that stores backups, and no compression at all for
/boot, so the bootloader doesn't have to know about all the different
compression algorithms.
Speaking of which, I read here:
https://btrfs.wiki.kernel.org/index.php/Compression#Why_does_not_du_report_the_compressed_size.3F
that du will not tell me the compressed size of a file. This is very
counter-intuitive, isn't it?
The reason stated is that some tools apparently determine the
sparse-ness of a file by comparing the size with the stat.st_blocks
value.
I do not know if there is a better way to do that, so maybe my argument
falls apart right here, BUT: this looks to me like working around one
bug by introducing another. Wouldn't it be better to have a mount option
"make_du_lie_for_buggy_tools" for those that really need it? BTW, which
tools would an honest du break, and how? (What harm is there in thinking
that a compressed file is sparse?)
Thanks!
Gert
--
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
