4 ms·
I mean 5-10 seconds for the free space to be updated doesn't sound extraordinary? With all the accounting ZFS has do, doesn't this sound like something you wou
by mustache_kimono 4y ago
I mean 5-10 seconds for the free space to be updated doesn't sound extraordinary? With all the accounting ZFS has do, doesn't this sound like something you would want running asynchronously in the background? The blog makes a point (with references) of ZFS being transactional, but, as a related matter, it's also COW, one would assume finding/guaranteeing "free" space is much harder than it would be on a traditional filesystem.
- toast0 4y agoIt's clearly not extraordinary, it's normal for ZFS. UFS2 on FreeBSD does is too, it also has snapshots, but isn't generally COW. The first time you delete something bit and it doesn't show up in df right away, it might be surprising though. Or this case where automation deleted more than expected because the author wasn't aware of the need to wait.
- rtp4me 4y agoI have seen the same behavior with BTRFS. We create nightly snapshots on our servers then prune older snapshots. Watching 'top' output shows a 5-8 second delay until the BTRFS cleanup agent starts. The agent could take many seconds (20?) to completely remove the old snapshots
- deleted 4y ago[deleted]
- ilyt 4y ago> I mean 5-10 seconds for the free space to be updated doesn't sound extraordinary? With all the accounting ZFS has do, doesn't this sound like something you would want running asynchronously in the background? If system is busy, sure, batching requests helps performance, especially on spinning rust. In one that it isn't ? Why wait ? Then again checking space after every removed file (which I assume what the problem was here) instead of "generate list of files to remove, remove them, then go to sleep for an hour" is a bit suboptimal in the first place