John Ogness wrote:
> On 2009-10-29, Lino Sanfilippo <[hidden email]> wrote:
> Hmmm. If the too many files are open because there is a huge queue
> waiting to be processed the daemon, we could easily handle this by
> sleeping until the queue gets smaller.
I dont think we have to do this, since userspace should take
care not to open too many files itself.
BUT if dazuko is unable to open a file descriptor (for whatever
reason - and there may be others beside too many open file descriptors,
see below...), it should at least report this to userspace by
means of a proper error code. I dont think that logging is enough,
it should be a real error at application level.
> However, if the process has too many open files because it has opened
> files on its own, then DazukoFS has little chance here. I agree that
> an endless loop of retries is bad, but I am not clear on a good
> solution. I suppose DazukoFS could sleep on a timeout and retry once a
> second or so (while logging the problems to syslog). That would at
> least give the user an idea of what the problem is.
As I said above, a simple error code returned by dazukofs_get_access()
would IMO absolutely be sufficient.
>> Similar problems may occur if you use dazukofs mounted on a
>> rootsquashed nfs, on which dazuko does not have the needed rights to
>> open the files for which it wants to report an access to userspace.
> This is interesting. (I am hearing this for the first time.) Since the
> user process also would get an access denied, it is probably
> appropriate to deny the access in such a case. Agreed?
> John Ognes
I admit that I never tested it myself, but imagine the following situation:
Dazukofs is mounted over an nfs filesystem with the rootsquash
option enabled. That means root is mapped to user "nobody" on this
Now user A has some of his files stored within the nfs mount. User A
tries to open one of his own files with only user read permission set.
Normally he would be allowed to do so, since the file he wants to open
belongs to him.
But first dazuko intercepts the open event, and tries to open the file,
the event to userspace.
But since the daemon that is registered at dazuko is running as root, it
have the rights of "nobody" on this FS. So it is not allowed
to open a filedescriptor since the file is only readable for the owner.
Thus dazuko will try and try again, never being able to open the file
due to the lack of the needed rights. And user A will never be able to open
This is a special situation where dazuko has _fewer_ rights on a filesystem
than the process that perfomed an open.
But it may happen and that is the reason why dazuko really should report
every error that occured while processing an event, to userspace.
Geschäftsführender Gesellschafter: Tjark Auerbach
Sitz der Gesellschaft: Tettnang
Handelsregister: Amtsgericht Ulm, HRB 630992
Es gelten unsere Allgemeinen Geschäftsbedingungen
(AGB). Sie finden sie in der jeweils gültigen Fassung
im Internet unter http://www.avira.de/agb ***************************************************