You don't need to grow the pool. You should always be able truncate the file without consuming more space, provided you don't have snapshots. Mark has a set of fixes in testing which do a much better job of estimating space, allowing us to always unlink files in full pools (provided there are no snapshots, of course). This provides much more logical behavior by reserving some extra slop.
- Eric On Mon, Jul 03, 2006 at 02:23:06PM +0200, Constantin Gonzalez wrote: > Hi, > > of course, the reason for this is the copy-on-write approach: ZFS has > to write new blocks first before the modification of the FS structure > can reflect the state with the deleted blocks removed. > > The only way out of this is of course to grow the pool. Once ZFS learns > how to free up vdevs this may become a better solution because you can then > shrink the pool again after the rming. > > I expect many customers to run into similar problems and I've already gotten > a number of "what if the pool is full" questions. My answer has always been > "No file system should be used up more than 90% for a number of reasons", but > in practice this is hard to ensure. > > Perhaps this is a good opportunity for an RFE: ZFS should reserve enough > blocks in a pool in order to always be able to rm and destroy stuff. > > Best regards, > Constantin > > P.S.: Most US Sun employees are on vacation this week, so don't be alarmed > if the really good answers take some time :). -- Eric Schrock, Solaris Kernel Development http://blogs.sun.com/eschrock _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
