> On Thu, Jun 05, 2008 at 09:13:24PM -0600, Keith > Bierman wrote: > > On Jun 5, 2008, at 8:58 PM 6/5/, Brad Diggs > wrote: > > > Hi Keith, > > > > > > Sure you can truncate some files but that > effectively corrupts > > > the files in our case and would cause more harm > than good. The > > > only files in our volume are data files. > > > > So an rm is ok, but a truncation is not? > > > > Seems odd to me, but if that's your constraint so > be it. > > Neither will help since before the space can be freed > a transaction must > be written, which in turn requires free space. > > (So you say "let ZFS save some just-in-case-space for > this," but, how > much is enough?)
If you make it a parameter, that's the admin's problem. Although since each rm of a file also present in a snapshot just increases the divergence, only an rm of a file _not_ present in a snapshot would actually recover space, right? So in some circumstances, even if it's the admin's problem, there might be no amount that's enough to do what one wants to do without removing a snapshot. Specifically, take a snapshot of a filesystem that's very nearly full, and then use dd or whatever to create a single new file that fills up the filesystem. At that point, only removing that single new file will help, and even that's not possible without a just-in-case reserve of enough to handle worst case metadata(including system attributes, if any) update+transaction log+\ any other fudge I forgot, for at least one file's worth. Maybe that's a simplistic view of the scenario, I dunno... This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
