Date: Sat, 10 Nov 2012 22:00:00 +0100 From: Mateusz Guzik <mjguzik@gmail.com> To: Chris Rees <utisoft@gmail.com> Cc: freebsd-fs@freebsd.org, Bryan Drewery <bryan@shatow.net> Subject: Re: ZFS can't delete files when over quota Message-ID: <20121110210000.GB19081@dft-labs.eu> In-Reply-To: <CADLo83-mi=ffW-Y846Ga_mT7SEmBFrWSzQn=DY8ftadoDf4_hA@mail.gmail.com> References: <509E79C7.10300@shatow.net> <CADLo83-mZ0v=zXJnHF01%2BtOvCtBWtrOTZpcd-V%2BWTF7qXNMJUg@mail.gmail.com> <CAFMmRNx2Xqo%2B3FZ6cT%2Ben-u26SVAecN%2B9ULfoV==fXRRTG7fDg@mail.gmail.com> <CADLo83_wEvUtYDgzoCoE4oNF7j3AMWe-AX6OvpxM12xd5AzJ7w@mail.gmail.com> <509EA942.9060801@shatow.net> <20121110194759.GA19081@dft-labs.eu> <CADLo83-mi=ffW-Y846Ga_mT7SEmBFrWSzQn=DY8ftadoDf4_hA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Nov 10, 2012 at 08:03:01PM +0000, Chris Rees wrote: > On 10 Nov 2012 19:48, "Mateusz Guzik" <mjguzik@gmail.com> wrote: > > > > On Sat, Nov 10, 2012 at 01:21:38PM -0600, Bryan Drewery wrote: > > > On 11/10/2012 12:55 PM, Chris Rees wrote: > > > > Bryan, > > > > > > > > Please try the patch at [1]; if it works I'll document it. > > > > > > > > Chris > > > > > > > > [1] http://www.bayofrum.net/~crees/patches/bdrewery.diff > > > > > > > > > > Hmm, I'm not a fan of -T. I think it should just work out-of-the-box > here. > > > > > > Something like: > > > > > > http://people.freebsd.org/~bdrewery/rm-quota.txt > > > > > > > I think this approach is incorrect. > > > > If you cannot rm $file due to EDQUOT, but truncate $file && rm $file > > works (and both patches try to do this), then I think this is a > filesystem bug. > > Quite right, but this has been a known issue in ZFS for a while, without a > forthcoming fix. > > I'll do some grovelling in the zfs code tomorrow, wish me luck-- I don't > expect to be productive. > In this case the right fix (whatever it is) may be really non-trivial. I'm in mood for ugly hacks, so: You can think of a workardound in the kernel. If removal fails with EDQUOT and you can guarantee that no thread has this file opened and truncation will allow removal to succeed, you truncate and remove. Determining whether truncation will be able to help (and making sure that these conditions hold until removal is finised) may be non-trivial as well. But I doubt something like this could be accepted. :) My point is that even if this problem persists, changing tools in the basesystem to cope is a bad idea. If you are happy with only rm being able to cope, you can wrap/alias it on your machines. -- Mateusz Guzik <mjguzik gmail.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121110210000.GB19081>