5 ms·

I understand the first one may be a genuine pptimization needed. But for the second one: when a file is striped across different physical disks with possibly d

by vkaku 4y ago

I understand the first one may be a genuine pptimization needed. But for the second one: when a file is striped across different physical disks with possibly different characteristics, how would you defrag it without knowing the read access pattern?

Dylan16807 4y ago
> when a file is striped across different physical disks with possibly different characteristics, how would you defrag it without knowing the read access pattern? Looking at a single disk at a time, do your best to make sure all chunks of the same file are in order and adjacent. You could be smarter than that, but just that would do fine. The problem is that ZFS basically can't move things.
- ender341341 4y ago
  > The problem is that ZFS basically can't move things. The one killer feature for me with btrfs is offline deduping (and by extension not having de-duping require a super computer to run). My data has enough duplication that it'd be nice to have, but not worth requiring hundreds of gigs of ram. Being able to fire off a job after importing a large set of data (or maybe yearly-ish) would be awesome and give me a few extra years without having to update my hardware.
- vkaku 4y ago
  That doesn't account for physical disk characteristics at all. You could have disks from different generations all be part of a pool, CMR vs SMR(!) (needs zone resets and large chunk writes), disks could degrade etc. Plus, when you update a file, you literally create new links and update the file out of place (true for any COW FS). So the read won't be sequential if you want to access two versions at the same time. In that case you want to know if you optimize for hardware failure as opposed to for performance. This could be fixed for specific usecases but not all block patterns in general. Just why I posted this.
mappu 4y ago
It's not possible to fix the first one (to merge the ARC with the Linux page cache), because the necessary page cache internals are GPL-only.
- quotemstr 4y ago
  In that case, I'd need ZFS to provide a way to disable ARC: double caching isn't acceptable to me.
  - derkades 4y ago
    You wouldn't want to disable the ARC, since it is much better at caching than the simple kernel page cache
  - nubinetwork 4y ago
    If your system is all zfs, there shouldn't be much in the Linux cache, except for cache from NFS shares... At worst, if your uptime is over month, you could just run sync and echo 1 > /proc/sys/vm/drop_caches (but why, just reboot already, you probably have kernel upgrades anyways)
  - p_l 4y ago
    There's another issue where Linux pagecache doesn't support filesystem blocks larger than single hardware pages (and no large pages allowed), so ZFS would be hard limited to 4kB blocks on x86 etc. Also a lot of other fancy features would be broken by pagecache design, so it's a no-go, and instead project focused on reducing duplication between the two.
    - mappu 4y ago
      This was fixed recently in Linux by Matthew Wilcox and others, in a way that can benefit all Linux filesystems. Folios of pages were added in 5.16, the page cache was converted to use folios in 5.17, and large-folios were in 5.18.

by vkaku 4y ago

Dylan16807 4y ago

> when a file is striped across different physical disks with possibly different characteristics, how would you defrag it without knowing the read access pattern? Looking at a single disk at a time, do your best to make sure all chunks of the same file are in order and adjacent. You could be smarter than that, but just that would do fine. The problem is that ZFS basically can't move things.

ender341341 4y ago
> The problem is that ZFS basically can't move things. The one killer feature for me with btrfs is offline deduping (and by extension not having de-duping require a super computer to run). My data has enough duplication that it'd be nice to have, but not worth requiring hundreds of gigs of ram. Being able to fire off a job after importing a large set of data (or maybe yearly-ish) would be awesome and give me a few extra years without having to update my hardware.
vkaku 4y ago
That doesn't account for physical disk characteristics at all. You could have disks from different generations all be part of a pool, CMR vs SMR(!) (needs zone resets and large chunk writes), disks could degrade etc. Plus, when you update a file, you literally create new links and update the file out of place (true for any COW FS). So the read won't be sequential if you want to access two versions at the same time. In that case you want to know if you optimize for hardware failure as opposed to for performance. This could be fixed for specific usecases but not all block patterns in general. Just why I posted this.

mappu 4y ago

It's not possible to fix the first one (to merge the ARC with the Linux page cache), because the necessary page cache internals are GPL-only.

quotemstr 4y ago
In that case, I'd need ZFS to provide a way to disable ARC: double caching isn't acceptable to me.
- derkades 4y ago
  You wouldn't want to disable the ARC, since it is much better at caching than the simple kernel page cache
- nubinetwork 4y ago
  If your system is all zfs, there shouldn't be much in the Linux cache, except for cache from NFS shares... At worst, if your uptime is over month, you could just run sync and echo 1 > /proc/sys/vm/drop_caches (but why, just reboot already, you probably have kernel upgrades anyways)
- p_l 4y ago
  There's another issue where Linux pagecache doesn't support filesystem blocks larger than single hardware pages (and no large pages allowed), so ZFS would be hard limited to 4kB blocks on x86 etc. Also a lot of other fancy features would be broken by pagecache design, so it's a no-go, and instead project focused on reducing duplication between the two.
  - mappu 4y ago
    This was fixed recently in Linux by Matthew Wilcox and others, in a way that can benefit all Linux filesystems. Folios of pages were added in 5.16, the page cache was converted to use folios in 5.17, and large-folios were in 5.18.