[OpenIndiana-discuss] ZFS; what the manuals don't say ...

[Jan Owoc]

On Sun, Oct 28, 2012 at 6:42 AM, Robin Axelsson
<gu99roax at student.chalmers.se> wrote:
> As I understand, fragmentation occurs when you remove files and rewrite
> files to a storage pool a large enough number of times. So if I have a
> fragmented storage pool and copy all files to a new empty storage pool, the
> new storage pool would not be fragmented. So I take it what you are saying
> is that the way the files are organized in the new storage pool is sometimes
> *worse* than the way they are organized in the old fragmented storage pool?

Robin, I think you missed this part by Jim:

On Thu, Oct 25, 2012 at 4:21 AM, Jim Klimov <jimklimov at cos.ru> wrote:
> This was discussed several times, with the outcome being that with
> ZFS's data allocation policies, there is no one good defrag policy.
> The two most popular options are about storing the current "live"
> copy of a file contiguously (as opposed to its history of released
> blocks only referenced in snapshots) vs. storing pool blocks in
> ascending creation-TXG order (to arguably speed up scrubs and
> resilvers, which can consume a noticeable portion of performance
> doing random IO).
>
> Usual users mostly think that the first goal is good - however,
> if you add clones and dedup into the equation, it might never be
> possible to retain their benefits AND store all files contiguously.

There are two important points:
1) if 'dedup=on' or you have clones, there is no way to defragment the
files unless you turn off dedup, and make two entirely separate
filesystems for your clones...
2) as soon as your newly-created filesystem has a snapshot and you
change some data, there are at least two 'right' answers for what
should be 'contiguous': the original snapshot, or the current 'live'
filesystem, with good arguments on both sides. You seem to feel the
latter, while for my usage I feel the former (see... even we can't
agree :-)).

Jan