On Wed, Feb 3, 2021 at 10:15 PM Martin Raiber <[email protected]> wrote: > > Hi, > > I've been looking a bit into the btrfs space cache and came to following > conclusions. Please correct me if I'm wrong: > > 1. The space cache mount option only modifies how the space cache is > persisted and not the in-memory structures (hence why I have 2,3 GiB > btrfs_free_space_bitmap slab with a file system mounted with space_cache=v2) > 2. In-memory it is mostly kept as bitmap. Space_cache=v1 persists those > bitmaps directly to disk > 3. If it's mounted with nospace_cache it still gets all the benefits of > "space cache" _after_ those in-memory bitmaps have been filled, it just isn't > persisted > 4. In-memory space cache doesn't react to memory pressure/is unevictable
You got it right. > > This leads me to: > > If one can live with slow startup/initial performance, mounting with > nospace_cache has the highest performance. Yes, there will be less IO during transaction commits since the space caches are not persisted (metadata only for the space_cache=v2 and data + metadata for space_cache=v1). However keep in mind it's not just startup/initial performance - a block group will be cached when we attempt to allocate space from it, so it can happen at any time. > > Especially if I have a 1TB NVMe in a long-running server, I don't really care > if it has to iterate over all block group metadata after mount for a few > seconds, if that means it has less write IOs for every write. The calculus > obivously changes for a hard disk where reading this metadata would talke > forever due to low IOPS. > > Regards, > Martin Raiber > -- Filipe David Manana, “Whether you think you can, or you think you can't — you're right.”
