Hide Forgot
[Migrated from savannah BTS] - bug 26282 [https://savannah.nongnu.org/bugs/?26282] Tue 21 Apr 2009 11:03:20 PM GMT, original submission: I ran into a problem with the latest rc release of gluster where read-subvolume only appears to work for only one machine. Here's my volume file: volume posix type storage/posix option directory /tmp/gluster end-volume volume locks type features/locks subvolumes posix end-volume volume brick type performance/io-threads option thread-count 8 subvolumes locks end-volume volume server type protocol/server option transport-type tcp option auth.addr.brick.allow * subvolumes brick end-volume volume machine1 type protocol/client option transport-type tcp option remote-host machine1 option remote-subvolume brick end-volume volume machine2 type protocol/client option transport-type tcp option remote-host machine2 option remote-subvolume brick end-volume volume replicate type cluster/replicate option read-subvolume `hostname` subvolumes machine1 machine2 end-volume In this cluster I've got a 1gb file of random data that I've verified via md5sum is on both machines. On machine1, I can copy the file to > /dev/null while watching dstat, and see that the file is being read completely locally. If I do the same on machine2 though, the file is read from machine1. Only if I kill glusterfsd on machine1 then it'll read the local copy. I've also found that If I change this line: subvolumes machine1 machine2 to subvolumes machine2 machine1 The behavior swaps. machine2 now will read the file locally and machine1 will read it remotely. Any idea what's going on?
Fixed in release 2.0 and later. Commit 75c70231fe7e13a68239dac889568d243a79a75e. Verified with the above specfile that read-subvolume is honored.