Just out of curiosity:
On Wed, 2017-08-16 at 09:12 -0400, Chris Mason wrote: > Btrfs couples the crcs with COW because this (which sounds like you want it to stay coupled that way)... plus > It's possible to protect against all three without COW, but all > solutions have their own tradeoffs and this is the setup we > chose. It's > easy to trust and easy to debug and at scale that really helps. ... this (which sounds more you think the checksumming is so helpful, that it would be nice in the nodatacow as well). What does that mean now? Things will stay as they are... or it may become a goal to get checksumming for nodatacow (while of course still retaining the possibility to disable both, datacow AND checksumming)? > In general, production storage environments prefer clearly defined > errors when the storage has the wrong data. EIOs happen often, and > you > want to be able to quickly pitch the bad data and replicate in good > data. Which would also rather point towards getting clear EIOs (and thus checksumming) in the nodatacow case. > My real goal is to make COW fast enough that we can leave it on for > the > database applications too. Obviously I haven't quite finished that > one > yet ;) Well the question is, even if you manage that sooner or later, will everyone be fully satisfied by this?! I've mentioned earlier on the list that I manage one of the many big data/computing centres for LHC. Our use case is typically big plain storage servers connected via some higher level storage management system (http://dcache.org/)... with mostly write once/read many. So apart from some central DBs for the storage management system itself, CoW is mostly no issue for us. But I've talked to some friend at the local super computing centre and they have rather general issues with CoW at their virtualisation cluster. Like SUSE's snapper making many snapshots leading the storage images of VMs apparently to explode (in terms of space usage). For some of their storage backends there simply seem to be no de- duplication available (or other reasons that prevent it's usage). From that I'd guess there would be still people who want the nice features of btrfs (snapshots, checksumming, etc.), while still being able to nodatacow in specific cases. > But I'd rather keep the building block of all the other btrfs > features in place than try to do crcs differently. Mhh I see, what a pity. Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature
