Re: implications of mixed mode

[Qu Wenruo <quwenruo@cn.fujitsu.com>]

Lukas Pirl wrote on 2015/11/27 12:54 +1300:
> Dear list,
>
> if a larger RAID file system (say disk space of 8 TB in total) is
> created in mixed mode, what are the implications?
>
>  From reading the mailing list and the Wiki, I can think of the following:
>
> + less hassle with "false positive" ENOSPC

If your "false positive" means unbalanced DATA/METADATA chunk 
allocation, then yes.

> - data and metadata have to have the same replication level
>    forever (e.g. RAID 1)
> - higher fragmentation
>    (does this reduce with no(dir)atime?)
>    -> more work for autodefrag

They are also true.

And some extra pros and cons due to fixed(4K) small(compared to 16K 
default) nodesize:

+ A little higher performance
   node/leaf size is restricted to sectorsize, smaller node/leaf,
   smaller range to lock.
   In our SSD test, operations with high concurrency, the performance is
   overall 10% better than 16K nodesize.
   And in extreme metadata operation case, like high concurrency on
   sequence write into small files, it can be 8 times the performance of
   default 16K nodesize.

- Smaller subvolume size
   Since the tree block are smaller, but tree level stays the same(level
   0 - 7), the up limit of a subvolume is reduced hugely be smaller
   node/leaf size.
   Although it's quite hard to hit that up limit though.

- (Possible) less developer interest.
   Other developers are trying remove default mixed-bg, so I'd like to
   consider the trend will be less mixed-bg focused developers.
   And hidden bugs are more and more hard to hit and fixed.

>
> Is that roughly what is to be expected? Any implications on recovery etc.?

As long as your chunk tree and extent tree is OK, it shouldn't be much 
different from normal fs, at least for now.

Thanks,
Qu
>
> In the specific case, the file system usage is as follows:
> * data spread over ~20 subvolumes
>    * snapshotted with various frequencies
>    * compression is used
> * mostly archive storage
>    * write once
>    * read infrequently
> * ~500GB of daily rsync'ed system backup
>
> Thanks in advance,
>
> Lukas
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>