Am Sat, 16 Sep 2017 09:39:33 -0400 schrieb Rich Freeman <ri...@gentoo.org>:
> On Sat, Sep 16, 2017 at 8:06 AM, Kai Krakow <hurikha...@gmail.com> > wrote: > > > > But I guess that btrfs doesn't use 10G sized extents? And I also > > guess, this is where autodefrag jumps in. > > > > It definitely doesn't use 10G extents considering the chunks are only > 1GB. (For those who aren't aware, btrfs divides devices into chunks > which basically act like individual sub-devices to which operations > like mirroring/raid/etc are applied. This is why you can change raid > modes on the fly - the operation takes effect on new chunks. This > also allows clever things like a "RAID1" on 3x1TB disks to have 1.5TB > of useful space, because the chunks essentially balance themselves > across all three disks in pairs. It also is what causes the infamous > issues when btrfs runs low on space - once the last chunk is allocated > it can become difficult to rebalance/consolidate the remaining space.) Actually, I'm running across 3x 1TB here on my desktop, with mraid1 and draid 0. Combined with bcache it gives confident performance. > I couldn't actually find any info on default extent size. I did find > a 128MB example in the docs, so presumably that isn't an unusual size. > So, the 1MB example would probably still work. Obviously if an entire > extent becomes obsolete it will lose its reference count and become > free. According to bees[1] source code it's 128M actually if I remember right. > Defrag was definitely intended to deal with this. I haven't looked at > the state of it in ages, when I stopped using it due to a bug and some > limitations. The main limitation being that defrag at least used to > be over-zealous. Not only would it free up the 1MB of wasted space, > as in this example, but if that 1GB file had a reflink clone it would > go ahead and split it into two duplicate 1GB extents. I believe that > dedup would do the reverse of this. Getting both to work together > "the right way" didn't seem possible the last time I looked into it, > but if that has changed I'm interested. > > Granted, I've been moving away from btrfs lately, due to the fact that > it just hasn't matured as I originally thought it would. I really > love features like reflinks, but it has been years since it was > "almost ready" and it still tends to eat data. XFS has gained reflinks lately, and I think they are working on snapshots currently. Kernel 4.14 or 4.15 promises new features for XFS (if they get ready by then), so maybe that will be snapshots? I'm not sure. I was very happy a long time with XFS but switched to btrfs when it became usable due to compression and stuff. But performance of compression seems to get worse lately, IO performance drops due to hogged CPUs even if my system really isn't that incapable. What's still cool is that I don't need to manage volumes since the volume manager is built into btrfs. XFS on LVM was not that flexible. If btrfs wouldn't have this feature, I probably would have switched back to XFS already. > For the moment I'm > relying more on zfs. How does it perform memory-wise? Especially, I'm currently using bees[1] for deduplication: It uses a 1G memory mapped file (you can choose other sizes if you want), and it picks up new files really fast, within a minute. I don't think zfs can do anything like that within the same resources. > I'd love to switch back if they ever pull things > together. The other filesystem I'm eyeing with interest is cephfs, > but that still is slightly immature (on-disk checksums were only just > added), and it has a bit of overhead until you get into fairly large > arrays. Cheap arm-based OSD options seem to be fairly RAM-starved at > the moment as well given the ceph recommendation of 1GB/TB. arm64 > still seems to be slow to catch on, let alone cheap boards with 4-16GB > of RAM. Well, for servers, XFS is still my fs of choice. But I will be evaluating btrfs for that soon, maybe compare it to zfs. When we evaluated the resource usage, we will buy matching hardware and setup a new server, mainly for thin-provisioning container systems for web hostings. I guess, ZFS would be somewhat misused here as DAS. If XFS gets into shape anytime soon with snapshotting features, I will of course consider it. Using it since years and it was extremely reliable, surviving power losses, not degrading in performance. Something I cannot say the same about for ext3, apparently. Also, XFS gives good performance with JBOD because allocations are distributed diagonally across the whole device. This is good for cheap hardware as well as hardware raid controllers. [1]: https://github.com/Zygo/bees -- Regards, Kai Replies to list-only preferred.
