xfs
[Top] [All Lists]

[patch] Re: XFS, Quotas and Samba

To: Jan Kara <jack@xxxxxxx>, Bret Giddings <bret@xxxxxxxxxxx>
Subject: [patch] Re: XFS, Quotas and Samba
From: Nathan Scott <nathans@xxxxxxx>
Date: Sun, 9 Sep 2001 20:57:52 +1100
Cc: linux-xfs@xxxxxxxxxxx, samba-technical@xxxxxxxxxxxxxxx
In-reply-to: <20010906163441.C24754@atrey.karlin.mff.cuni.cz>; from jack@suse.cz on Thu, Sep 06, 2001 at 04:34:41PM +0200
References: <7AC902A40BEDD411A3A800D0B7847B660882F5@sernt14.essex.ac.uk> <20010906105952.B345981@wobbly.melbourne.sgi.com> <20010906123515.A380241@wobbly.melbourne.sgi.com> <20010906163441.C24754@atrey.karlin.mff.cuni.cz>
Sender: owner-linux-xfs@xxxxxxxxxxx
User-agent: Mutt/1.2.5i
hi,

On Thu, Sep 06, 2001 at 04:34:41PM +0200, Jan Kara wrote:
>   Hello,
> 
>   Actually it depends whether the samba code was compiled with
> proper kernel headers. If so the Q_GETQUOTA is defined to be
> right value and so everything should work fine. Ok, to be more
> precise the utils probably won't compile in that case as struct dqblk
> is no more and mem_dqblk should be used instead... But anyway it shouldn't
> break silently.

Hmm ... I can't see any case where the new VFS quota code will
work (ie. Jan's patches/AC kernels/Redhat 7.1+) with the smbd
code, even if the kernel headers happened to correspond to the
running kernel.  As I understand it, the new code returns a u64
byte count in one field (curspace) where before there was a u32
block count (curblocks).  Is that correct?  If so, smbd is in a
bit of strife here cos it peeks at that field in particular...

I took a stab at implementing the fix for this problem and for
XFS quota - the XFS code should be correct, the VFS quota code
(v1/v2 stuff) should be too, but I'm less certain on that - see
attached patch.  The approach is basically to attempt the old
Linux quotactl for non-XFS filesystems - if that fails, try
the new version.  And for XFS filesystems, always use the XFS
quotactl command, which is always the right thing to do.

Bret - could you let me know if this helps you?

cheers.

> 
> > Just a quick followup - this is what I mentioned in my earlier
> > mail to you.  I think your new VFS quota code (as in Alan Cox's
> > series of 2.4 kernels, for the Samba folk) will have exactly the
> > same problem as XFS.  This "grep" would seem to confirm it - but
> > you'll know better than I here:
> > 
> > 11:31 nathans@troppo ~/cvs/quota-tools 73> grep GETQUOTA dqblk*h
> > dqblk_rpc.h:#define Q_RPC_GETQUOTA      0x0300  /* get limits and usage */
> > dqblk_v1.h:#define Q_V1_GETQUOTA        0x300
> > dqblk_v2.h:#define Q_V2_GETQUOTA        0x0D00  /* Get limits and usage */
> > dqblk_xfs.h:#define Q_XFS_GETQUOTA      Q_XGETQUOTA
> > 11:31 nathans@troppo ~/cvs/quota-tools 74> 
> > 
> > The samba code does a good old Q_GETQUOTA (ie. your V1 above).
> > 
> > cheers.
> > 
> > 
> > On Thu, Sep 06, 2001 at 10:59:52AM +1100, Nathan Scott wrote:
> > > hi,
> > > 
> > > On Wed, Sep 05, 2001 at 02:57:39PM +0100, Giddings, Bret wrote:
> > > > I am investigating whether I can replace my expensive Compaq Alphas file
> > > > servers with cheaper (and invariably faster given my budget) Intel based
> > > > ones. I have so far been pleased with the ease with which xfs has 
> > > > installed
> > > > and run on my hardware of choice. To make my life easier, I have picked 
> > > > up
> > > > the pre-built RedHat kernels with xfs support. Everything appears to be 
> > > > fine
> > > > except that when connecting to a share from Samba, the amount of free 
> > > > space
> > > > reported is the amount of free disk space left on the device rather 
> > > > than the
> > > > amount of free space in the users quota (this is on a disk mounted with
> > > > usrquota and a quota set for the users). The usual tools (edquota, 
> > > > setquota
> > > > work as expected).
> > > > 
> > > > I have downloaded the source rpm for samba and it appears that RedHat 
> > > > build
> > > > their smbd to support quotas. I have also checked whether
> > > > /usr/include/sys/quota.h is modified by installing your updated quota 
> > > > rpm
> > > > (quota-3.01pre8) and it isn't. So, is there another reason why quotas 
> > > > don't
> > > > appear to work with xfs/samba?
> > > 
> > > The samba code needs to be updated to support XFS quota under
> > > Linux.  There was someone on the list a little while ago who
> > > was looking to add in the samba support for XFS quota, but I
> > > don't know how far they got.
> > > 
> > > I know very little about samba unfortunately, but it should be
> > > quite simple to add this stuff for XFS - the disk_quotas()
> > > routine in samba-2.2.1a/source/smbd/quotas.c is all that needs
> > > to be changed, by the look of things.
> > > 
> > > For XFS filesystems on Linux this needs to:
> > > - have logic to handle getmntent's of type "xfs" separately;
> > > - issue a quotactl(QCMD(Q_XGETQUOTA,USRQUOTA), ..., &xdq) where
> > >   xdq is of type "struct fs_disk_quota_t" from <linux/xqm.h>
> > > - set *bsize to 512 for XFS
> > > - refer to the code later in that same file for dealing with XFS
> > >   on IRIX - basically, do exactly the same thing and it should
> > >   just work.
> > > - to do it properly, the configure scripts will need to check
> > >   for linux/xqm.h (or might be simpler to keep a local copy? -
> > >   I dunno what sort of policy the samba folk have on this sort of
> > >   thing, but this header isn't going to change and probably isn't
> > >   going to appear in the libc headers for quite awhile...)
> > > 
> > > cheers.
> > > 
> > > -- 
> > > Nathan
> > 
> > -- 
> > Nathan
> --
> Jan Kara <jack@xxxxxxx>
> SuSE Labs

-- 
Nathan

Attachment: smbd+quota.patch
Description: Text document

<Prev in Thread] Current Thread [Next in Thread>