Hi All
I have a question about current quota implementation.
This is current implementation. There is a rquotad running on same box
as nfsd. Then in quota-tools, it check if file system type is nfs, then
it invoke a rpc call and get that from rquotad.
Another way is to implement the s_qcops in kernel nfs client and thus
quota-tools can use a unified way to get quotactl information.
Any special reason why not use 2nd way to make quota-tools simpler? One
reason I can think of is to put unnecessary code out of kernel. Is there
any other reason?
Thanks!
Ming
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, Mar 12, 2007 at 12:11:49PM -0400, Ming Zhang wrote:
> Hi All
>
> I have a question about current quota implementation.
>
> This is current implementation. There is a rquotad running on same box
> as nfsd. Then in quota-tools, it check if file system type is nfs, then
> it invoke a rpc call and get that from rquotad.
>
> Another way is to implement the s_qcops in kernel nfs client and thus
> quota-tools can use a unified way to get quotactl information.
>
> Any special reason why not use 2nd way to make quota-tools simpler? One
> reason I can think of is to put unnecessary code out of kernel. Is there
> any other reason?
I think it's mostly a historical issue. There was no abstraction
between the quotactl syscall and the default disk based quota implementation
at the time the nfs quote code was written. I'd definitively welcome
a patch adding a kernel interface for nfs quotas.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, 2007-03-12 at 16:35 +0000, Christoph Hellwig wrote:
> On Mon, Mar 12, 2007 at 12:11:49PM -0400, Ming Zhang wrote:
> > Hi All
> >
> > I have a question about current quota implementation.
> >
> > This is current implementation. There is a rquotad running on same box
> > as nfsd. Then in quota-tools, it check if file system type is nfs, then
> > it invoke a rpc call and get that from rquotad.
> >
> > Another way is to implement the s_qcops in kernel nfs client and thus
> > quota-tools can use a unified way to get quotactl information.
> >
> > Any special reason why not use 2nd way to make quota-tools simpler? One
> > reason I can think of is to put unnecessary code out of kernel. Is there
> > any other reason?
>
> I think it's mostly a historical issue. There was no abstraction
> between the quotactl syscall and the default disk based quota implementation
> at the time the nfs quote code was written. I'd definitively welcome
> a patch adding a kernel interface for nfs quotas.
I wouldn't. 'NFS quotas' use a completely different RPC program. We do
not need to interface them to the VFS (the server will enforce quotas
without any client aid), and so the rquotad stuff really only exists in
order to allow users to display their quotas. It belongs in userland.
Cheers
Trond
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, 2007-03-12 at 13:11 -0400, Trond Myklebust wrote:
> On Mon, 2007-03-12 at 16:35 +0000, Christoph Hellwig wrote:
> > On Mon, Mar 12, 2007 at 12:11:49PM -0400, Ming Zhang wrote:
> > > Hi All
> > >
> > > I have a question about current quota implementation.
> > >
> > > This is current implementation. There is a rquotad running on same box
> > > as nfsd. Then in quota-tools, it check if file system type is nfs, then
> > > it invoke a rpc call and get that from rquotad.
> > >
> > > Another way is to implement the s_qcops in kernel nfs client and thus
> > > quota-tools can use a unified way to get quotactl information.
> > >
> > > Any special reason why not use 2nd way to make quota-tools simpler? One
> > > reason I can think of is to put unnecessary code out of kernel. Is there
> > > any other reason?
> >
> > I think it's mostly a historical issue. There was no abstraction
> > between the quotactl syscall and the default disk based quota implementation
> > at the time the nfs quote code was written. I'd definitively welcome
> > a patch adding a kernel interface for nfs quotas.
>
> I wouldn't. 'NFS quotas' use a completely different RPC program. We do
> not need to interface them to the VFS (the server will enforce quotas
> without any client aid), and so the rquotad stuff really only exists in
> order to allow users to display their quotas. It belongs in userland.
>
so it worthy duplicating whole rpc logic in quota-tools instead of a
unified interface via vfs and single quotactl system call?
> Cheers
> Trond
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, Mar 12, 2007 at 01:24:17PM -0400, Ming Zhang wrote:
> so it worthy duplicating whole rpc logic in quota-tools instead of a
There's a lot more rpc logic in userspace than the few kernel bits
we have for nfs :)
> unified interface via vfs and single quotactl system call?
I'd like that also. Then again we don't really have an all that
unified quta syscall API either, as XFS has a much more advanced
quota subsystem which also needs a different userspace API.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, 2007-03-12 at 16:35 +0000, Christoph Hellwig wrote:
> On Mon, Mar 12, 2007 at 12:11:49PM -0400, Ming Zhang wrote:
> > Hi All
> >
> > I have a question about current quota implementation.
> >
> > This is current implementation. There is a rquotad running on same box
> > as nfsd. Then in quota-tools, it check if file system type is nfs, then
> > it invoke a rpc call and get that from rquotad.
> >
> > Another way is to implement the s_qcops in kernel nfs client and thus
> > quota-tools can use a unified way to get quotactl information.
> >
> > Any special reason why not use 2nd way to make quota-tools simpler? One
> > reason I can think of is to put unnecessary code out of kernel. Is there
> > any other reason?
>
> I think it's mostly a historical issue. There was no abstraction
> between the quotactl syscall and the default disk based quota implementation
> at the time the nfs quote code was written. I'd definitively welcome
> a patch adding a kernel interface for nfs quotas.
thx.
sys_quotactl call lookup_bdev() where return an error for device with
MNT_NODEV option. this will prevent nfs from going further.
so why we need to judge MNT_NODEV here in lookup_bdev()? at least from
the function name, it does not say it can not/should not return a bdev
with nodev option. so this function does something it does not claim to
do. will this be a bad practice?
Ming
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, 2007-03-12 at 13:11 -0400, Trond Myklebust wrote:
> On Mon, 2007-03-12 at 16:35 +0000, Christoph Hellwig wrote:
> > On Mon, Mar 12, 2007 at 12:11:49PM -0400, Ming Zhang wrote:
> > > Hi All
> > >
> > > I have a question about current quota implementation.
> > >
> > > This is current implementation. There is a rquotad running on same box
> > > as nfsd. Then in quota-tools, it check if file system type is nfs, then
> > > it invoke a rpc call and get that from rquotad.
> > >
> > > Another way is to implement the s_qcops in kernel nfs client and thus
> > > quota-tools can use a unified way to get quotactl information.
> > >
> > > Any special reason why not use 2nd way to make quota-tools simpler? One
> > > reason I can think of is to put unnecessary code out of kernel. Is there
> > > any other reason?
> >
> > I think it's mostly a historical issue. There was no abstraction
> > between the quotactl syscall and the default disk based quota implementation
> > at the time the nfs quote code was written. I'd definitively welcome
> > a patch adding a kernel interface for nfs quotas.
>
> I wouldn't. 'NFS quotas' use a completely different RPC program. We do
> not need to interface them to the VFS (the server will enforce quotas
> without any client aid), and so the rquotad stuff really only exists in
> order to allow users to display their quotas. It belongs in userland.
>
i thought we already have >1 rpc programs here? so not real a big deal
to have one more in kernel.
rquotad
-S, --setquota
Allow setting of quotas. This option is available only if
utilities were compiled with the rpcsetquota option.
rquotad _does_ allow to set the quota,
now the question is a whether a unified interface worthy the effort.
> Cheers
> Trond
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, 2007-03-12 at 13:24 -0400, Ming Zhang wrote:
> so it worthy duplicating whole rpc logic in quota-tools instead of a
> unified interface via vfs and single quotactl system call?
Yes.
Until the mess that is rquotad is resolved (somebody from the quota
group showing infinite wisdom decreed that Linux should serve up a
"revision" of the rquotad protocol for which there is not even an RFC to
refer to) I will veto any implementation of a client in the kernel.
Private protocols belong in userspace, not kernel space.
Trond
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, 2007-03-12 at 13:39 -0400, Trond Myklebust wrote:
> On Mon, 2007-03-12 at 13:24 -0400, Ming Zhang wrote:
>
> > so it worthy duplicating whole rpc logic in quota-tools instead of a
> > unified interface via vfs and single quotactl system call?
>
> Yes.
>
> Until the mess that is rquotad is resolved (somebody from the quota
> group showing infinite wisdom decreed that Linux should serve up a
> "revision" of the rquotad protocol for which there is not even an RFC to
> refer to) I will veto any implementation of a client in the kernel.
> Private protocols belong in userspace, not kernel space.
o, i did not know this.
>
> Trond
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Mon, 2007-03-12 at 17:27 +0000, Christoph Hellwig wrote:
> On Mon, Mar 12, 2007 at 01:24:17PM -0400, Ming Zhang wrote:
> > so it worthy duplicating whole rpc logic in quota-tools instead of a
>
> There's a lot more rpc logic in userspace than the few kernel bits
> we have for nfs :)
can not agree more. :P
>
> > unified interface via vfs and single quotactl system call?
>
> I'd like that also. Then again we don't really have an all that
> unified quta syscall API either, as XFS has a much more advanced
> quota subsystem which also needs a different userspace API.
i saw you are shifting here. ;)
maybe u are right, "a semi unified interface" (since we can not unify
the xfs here) possibly is not worthy the effort of adding extra code in
kernel.
thanks a lot for all of your explanation.
Ming
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs