On Sat, 2 Jun 2012 01:45:05 -0400, you wrote: > In a non-COW filesystem, one would expect that rewriting > an already allocated block would never fail for > out-of-space (ENOSPC). > > But I would expect that it could on ZFS - definitely if > there was a snapshot around, as it would create a > divergence from that snapshot (because both blocks would > be kept). Or if deduplication was in effect, and the new > block contents were unique when the old contents hadn't > been unique.
Not only then. Every block written obeys COW, the previous version is always retained. The new version of the block is always a new allocation. The previous version is released over time, when nothing refers to it anymore. > Could rewriting a block _ever_ fail with ENOSPC if there > _wasn't_ a snapshot present, Yes. > or is the replace old block > with new somehow guaranteed to succeed, so as to avoid > introducing unexpected semantics? (say maybe there's a > reserved amount of free space just for rewrites to avoid > that sort of problem, or some other magic) No. You have to monitor the used capacity of the pool, with alert thresholds of, for example, 80% (warning), 95% (critical) and 98% (fatal). It might make sense to limit the size per filesystem using quota to avoid the pool from filling up completely, protecting one zfs against another zfs. > I would think DBMS developers allowing databases to be > stored on ZFS, as well as folks using mmap(), might > particularly want to be aware of the cases in which an > errno not anticipated from experience with other > filesystems might arise. http://assets.en.oreilly.com/1/event/21/Optimizing%20MySQL%20Performance%20with%20ZFS%20Presentation.pdf -- Regards, Kees Nuyt _______________________________________________ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss