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
