ZFS can't delete files when over quota

Garrett Cooper yanegomi at gmail.com
Sat Nov 10 21:24:09 UTC 2012


On Sat, Nov 10, 2012 at 1:03 PM, Mateusz Guzik <mjguzik at gmail.com> wrote:

> On Sat, Nov 10, 2012 at 11:55:14AM -0800, Garrett Cooper wrote:
> > On Sat, Nov 10, 2012 at 11:48 AM, Mateusz Guzik <mjguzik at 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.
> > >
> >
> > Perhaps. This is kind of an implementation/compatibility issue because of
> > how ZFS (and other COW-based FSes) work.
>
> Except this is not about being unable to rm because of EDQUOT (whether
> ZFS can do something about that or not I have no idea). This is about being
> able to remove just after truncation, which clearly shows that zfs can in
> principle remove this file on its own.
>

    You're probably right. My guess is that the fix would be to ignore
EDQUOT in the unlink VOP handler.
Thanks,
-Garrett


More information about the freebsd-fs mailing list