Re: Feature requests: online backup - defrag - change RAID level

webmaster
2019-09-10T23:58:41Z

Quoting "Austin S. Hemmelgarn" <ahferroin7@gmail.com>:

>> Also, I don't quite understand what the poster means by "the
>> snapshot duplication of defrag only affects the fragmented
>> portions". Possibly it means approximately: if a file wasn't
>> modified in the current (latest) subvolume, it doesn't need to be
>> unshared. But, that would still unshare all the log files, for
>> example, even all files that have been appended, etc... that's
>> quite bad. Even if just one byte was appended to a log file, then
>> defrag will unshare the entire file (I suppose).
>>
> What it means is that defrag will only ever touch a file if that
> file has extents that require defragmentation, and will then only
> touch extents that are smaller than the target extent size (32M by
> default, configurable at run-time with the `-t` option for the
> defrag command) and possibly those directly adjacent to such extents
> (because it might merge the small extents into larger neighbors,
> which will in turn rewrite the larger extent too).

Umm... it seems to me that it's quite a poor defrag you got there.

> * There's almost no net benefit to not defragmenting when dealing
> with very large files that mostly see internal rewrites (VM disk
> images, large databases, etc) because every internal rewrite will
> implicitly unshare extents anyway.

Ok, so if you have a database, and then you snapshot its subvolume,
you might be in trouble because of all the in-place writes that
databases do, right?

It would almost be better if you could, manually, order the database
file to be unshared and defragmented. So, that would be the use-case
for defrag-unsharing. Interesting. Ok, I would agree with that. So,
there needs to be the operation called defrag-unshare, but that has
nothing to do with the real defrag.

I mean, this defrag-unsharing is just a glorified copy operation, but
there are a few twists, because it must be consistent, as opposed to
online copy, which would fail the consistency criteria.

But, you and other developers here seem to be confusing this
defrag-unshare with the real defrag. I bet you haven't even considered
what it means to "defrag without usharing" in terms of: what the final
result of such defrag should be, when it is done perfectly.