I'm running 1.4rc7 (glusterfs--mainline--3.0--patch-814) and seeing some odd behavior when tailing a file that is being written to by a single process -- a log file in this case. The odd behaviors that I've noticed are that "tail -f" behaves like "tail" and doesn't show any updates. In addition, /usr/bin/less seems to show binary values (at least that's what I assume the "^@" characters are supposed to be) when the bottom of the file "G" accessed instead of the new data added to the file after less was started. Is this a known issue? Is there a work-around? Here's how I'm able to reproduce it. Run the script below and direct the output to a gluster-hosted file. Then attempt to "tail -f" or use /usr/bin/less on the file from another terminal. $> num=0; while [ 1 ]; do echo $((num++)); sleep 1; done > /mnt/ gluster/nums.txt The output from /usr/bin/less ends up looking like this: ... 301 302 303 304 305 306 307 308 309 310 311 ^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ Gluster configs are very basic: ## Server volume brick type storage/posix option directory /glusterfs/export end-volume volume lock type features/posix-locks subvolumes brick end-volume volume export type performance/io-threads subvolumes lock option thread-count 4 # default value is 1 end-volume volume server type protocol/server option transport-type tcp subvolumes export option auth.addr.export.allow 10.10.10.* end-volume ## Client volume volume1 type protocol/client option transport-type tcp/client option remote-host 10.10.10.2 option remote-subvolume export end-volume volume volume2 type protocol/client option transport-type tcp/client option remote-host 10.10.10.3 option remote-subvolume export end-volume volume mirror1 type cluster/afr subvolumes volume1 volume2 end-volume -Bryan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zresearch.com/pipermail/gluster-users/attachments/20090112/eb70cb6f/attachment.htm
