[Gluster-devel] Experience with kernel NFS reexport

[Brent A Nelson]

I hadn't tried nfs-kernel-server with GlusterFS in awhile and thought I'd 
give it a shot to rsync data from an old GlusterFS to my new system 
(2.0.1, 
io-threads->distribute->replicate->ha->client->server->io-threads->posix-locks->posix).

The new system is NFS-exporting to the old, and the old is writing with 
rsync.  The first rsync succeeded without complaint, but when I went back 
to check the data, I found that many files and directories on the copy had 
modification times equal to the time of the transfer, rather than the 
modification time of the original.  Other file and directory copies do, in 
fact, have correct modification times.  Some sort of race when setting 
modification time?

A different rsync has given me an odd error on a couple of tiny files:
rsync: rename "/internal2/sys-archives/neptune-tmp2/hansen/devel/software/pine/pine4.64/..bld.hlp.LkbbI7" 
-> "sys-archives/neptune-tmp2/hansen/devel/software/pine/pine4.64/.bld.hlp": Invalid argument (22)
rsync: rename "/internal2/sys-archives/neptune-tmp2/hansen/devel/software/pine/worked-pine4.64_v0/..bld.hlp.BSSghL" 
-> "sys-archives/neptune-tmp2/hansen/devel/software/pine/worked-pine4.64_v0/.bld.hlp": Invalid argument (22)

These files have "-rw------T" permissions and are only a couple of hundred 
bytes.  The directories also contain a ".bld.args" file, half the size but 
with the same permissions, that caused no complaints.  This quirk seems to 
be quite rare...

Neither issue is necessarily specific to NFS reexport, but that's how I 
encountered them.

Overall, NFS reexport seems to be stable, so far.

Thanks,

Brent