On Thu, 2015-11-26 at 23:29 +0000, Duncan wrote: > > but only on meta-data blocks, right? > Yes. Okay... so it'll at most get the whole meta-data for a snapshot separately and not shared anymore... And when these are chained as in ZFS,.. it probably amplifies... i.e. a change deep down in the tree changes all the upper elements as well? Which shouldn't be a too big problem unless I have a lot snapshots or extremely many files. > I think it's whole 4 KiB blocks and possibly whole metadata nodes (16 > KiB), copy-on-write, and these would be relatively small changes > triggering cow of the entire block/node, aka write > amplification. While > not too large in themselves, it's the number of them that becomes a > problem. Ah... there you say it already =) But still it's always only meta-data that is copied, never the data, right?! > IIRC relatime updates once a day on access. If you're doing daily > snapshots, updating metadata blocks for all files accessed in the > last 24 > hours... Yes... Wouldn't it be a way to handle that problem if btrfs allowed to create snapshots for which the atime never gets updated, regardless of any mount option? And additionally, allow people to mount subvols with different noatime/relatime/atime settings (unless that's already working)... that way, they could enable it for things where they want/need it,... and disable it where not. > In my case, I'm on SSD with their limited write cycles, so while the > snapshot thing doesn't affect me since my use-case doesn't involve > snapshots, the SSD write cycle count thing certainly does, and > noatime is > worth it to me for that alone. I'm always a bit unsure about that... I've used to do it as well as for the wear.. but is that really necessary? With relatime, atime updates happen at most once a day... so at worst you rewrite... what... some 100 MB (at least in the ext234 case)... and SSDs seem to bare much more write cycles than advertised. Cheers, Chris.
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
