[Gluster-users] tailing active files

[Bryan Talbot]

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://supercolony.gluster.org/pipermail/gluster-users/attachments/20090112/eb70cb6f/attachment.html>