about quota implementation
Subsystems (2)
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
Quoted 8 lines · Ming Zhang
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.
Quoted 6 lines
Another way is to implement the
s_qcopsin 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
Quoted 12 lines · Christoph Hellwig
Quoted 11 lines · Ming Zhang
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_qcopsin kernel nfs client and thus quota-tools can use a unified way to get quotactl information.
Quoted 8 lines
Quoted 3 lines
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
Quoted 22 lines · Trond Myklebust
Quoted 12 lines · Christoph Hellwig
Quoted 11 lines · Ming Zhang
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_qcopsin kernel nfs client and thus quota-tools can use a unified way to get quotactl information.Quoted 8 lines
Quoted 3 lines
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.
Quoted 5 lines
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?
Quoted 3 lines
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
Quoted 1 line · Ming Zhang
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 :)
Quoted 1 line
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
Quoted 5 lines · Christoph Hellwig
Quoted 1 line · Ming Zhang
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
Quoted 6 lines
Quoted 2 lines
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
Quoted 2 lines · Ming Zhang
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
Quoted 5 lines · Trond Myklebust
Quoted 2 lines · Ming Zhang
so it worthy duplicating whole rpc logic in quota-tools instead of a unified interface via vfs and single quotactl system call?
Quoted 7 lines
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.
Quoted 3 lines
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
Quoted 22 lines · Trond Myklebust
Quoted 12 lines · Christoph Hellwig
Quoted 11 lines · Ming Zhang
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_qcopsin kernel nfs client and thus quota-tools can use a unified way to get quotactl information.Quoted 8 lines
Quoted 3 lines
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.
Quoted 5 lines
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.
Quoted 3 lines
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
Quoted 12 lines · Christoph Hellwig
Quoted 11 lines · Ming Zhang
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_qcopsin kernel nfs client and thus quota-tools can use a unified way to get quotactl information.
Quoted 8 lines
Quoted 3 lines
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