That's excellent news, as with the frequency that customers applications go feral and write a whole heap of crap (or they don't watch closely enough with gradual filling) we will forever be getting calls if this functionality is *anything* but transparent...
Most explorers I see have filesystem 100% full messages in them... It will be interesting to see how the current S10_u2 bits go. :) Nathan. On Tue, 2006-07-04 at 02:19, Eric Schrock wrote: > 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 -- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
