Hi Eric, 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.
is this a planned and not yet implemented functionality or why did Tatjana see the "not able to rm" behaviour? Or should she use unlink(1M) in these cases? Best regards, Constantin > > - 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 -- Constantin Gonzalez Sun Microsystems GmbH, Germany Platform Technology Group, Client Solutions http://www.sun.de/ Tel.: +49 89/4 60 08-25 91 http://blogs.sun.com/constantin/ _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss