This problem is becoming a real pain to us again and I was wondering if there has been in the past few month any known fix or workaround.
I normally create zfs fs's like this: zfs create -o quota=131G -o reserv=131G -o recsize=8K zpool1/newvol and then just nfs export through /etc/dfs/dfstab. We deal with lots of small image files in our MRI data which is the reason for small recsize. On Fri, 30 May 2008, Joe Little wrote: > On Fri, May 30, 2008 at 7:43 AM, Paul Raines <[EMAIL PROTECTED]> wrote: >> >> It seems when a zfs filesystem with reserv/quota is 100% full users can no >> longer even delete files to fix the situation getting errors like these: >> >> $ rm rh.pm6895.medial.V2.tif >> rm: cannot remove `rh.pm6895.medial.V2.tif': Disk quota exceeded >> >> (this is over NFS from a RHEL4 Linux box) >> >> I can log in as root on the Sun server and delete the file as root. >> After doing that, the user can then delete files okay. >> >> Is there anyway to workaround this does not involve root intervention? >> Users are filling up their volumes all the time which is the >> reason they must have reserv/quota set. > > Well, with the Copy-on-right filesystem a delete actually requires a > write. That said, there have been certain religious arguments on the > list about whether the "quota" support presented by ZFS is sufficient. > In a nutshell, per user quotas are not implemented, and the suggested > workaround is the per-user filesystem with quota/reservations. Its > inelegant at best since the auto-mount definitions become their own > pain to maintain. > > The other unimplemented feature is the soft and hard quota limits. > Most people have gotten around this by actually presenting only UFS > volumes held inside ZFS zvols to end users, but that defeats the > purpose of providing snapshots directly to end users, etc. > > However, since snapshots are only available at the filesystem level, > you still are restricted to one filesystem per user to use snapshots > well, but I would argue hard/soft limits on the quota are the > unanswered problem that doesn't have a known workaround. > > > >> >> -- >> --------------------------------------------------------------- >> Paul Raines email: raines at nmr.mgh.harvard.edu >> MGH/MIT/HMS Athinoula A. Martinos Center for Biomedical Imaging >> 149 (2301) 13th Street Charlestown, MA 02129 USA >> >> >> _______________________________________________ >> zfs-discuss mailing list >> zfs-discuss@opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/zfs-discuss >> > > > -- --------------------------------------------------------------- Paul Raines email: raines at nmr.mgh.harvard.edu MGH/MIT/HMS Athinoula A. Martinos Center for Biomedical Imaging 149 (2301) 13th Street Charlestown, MA 02129 USA _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
