| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On a recent Debian/Sid machine, I saw libc retrying stdio writes that
returned write errors. The result is that if an export downcall returns
an error (which it can in normal operation, since it currently
(incorrectly) returns -ENOENT on any negative downcall), then subsequent
downcalls will write multiple lines (including the original line that
received the error).
The result is that the server fails to respond to any rpc call that
refers to an unexported mount point (such as a readdir of a directory
containing such a mountpoint), so client commands hang.
I don't know whether this libc behavior is correct or expected, but it
seems safest to add the __fpurge() (suggested by Neil) to ensure data is
thrown away.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Neil Brown <neilb@suse.de>
|
| |
|
|
|
|
|
| |
With "-g" mountd will listen for uid -> gidlist requests
from the kernel and provide the required mapping.
This is specific to AUTH_USER (aka AUTH_SYS) and is designed
to overcome the 16-gid limit in the AUTH_UNIX protocol.
|
| |
|
|
|
|
|
|
|
|
|
| |
This introduces a new dependancy on libblkid.
If a filesystem being exported has a UUID that libblkid
can extract, then that is passed to the kernel for use
in identifying the filesystem in filehandles.
This means that 'fsid=' is no longer needed to work around the
problem of device numbers changing.
fsid= is still needed for fielsystems that have no device,
and can now be given 16byute uuid instead of just a 32bit one.
|
| |
|
|
|
|
| |
If 'etab' happens to have a timestamp in the future, this will get
copied to the flush-time for various caches, and no exports will
work until that time arrives. So clamp the flushtime to 'now'.
|
| |
|
|
|
|
| |
And make sure that if we fail to export a filesystem in mountd,
then we don't try to get a filehandle on it, or a deadlock
might occur.
|
| |
|
|
| |
Thanks to Michael Halcrow for finding them.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
