[Gluster-users] tailing active files

Tue Jan 13 06:35:19 UTC 2009

Same on 1.3.12:  tail -f doesn't -f :

	glusterfs 1.3.12 
	Repository revision: glusterfs--mainline--2.5--patch-797

Here's something interesting though -- it is actually working, it is just 
reading nulls instead of actual data.  Here is the transition from '8', '9' 
to '10', '11':

strace tail -f nums.txt     # .......

nanosleep({1, 0}, NULL)                 = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=422, ...}) = 0
read(3, "\0\0", 8192)                   = 2
read(3, "", 8192)                       = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=422, ...}) = 0
write(1, "\0\0", 2)                     = 2
nanosleep({1, 0}, NULL)                 = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=425, ...}) = 0
read(3, "\0\0\0", 8192)                 = 3
read(3, "", 8192)                       = 0
fstat64(3, {st_mode=S_IFREG|0644, st_size=425, ...}) = 0
write(1, "\0\0\0", 3)                   = 3
nanosleep({1, 0}, NULL)                 = 0

&:-)

On Tuesday 13 January 2009 05:04:53 Keith Freedman wrote:
> this is interesting.
>
> I'm running glusterfs--mainline--3.0--patch-840
>
> using AFR.
> I did your test
> on the local machine, running tail does exactly what you indicated...
> it acts like it was run without the -f.
> on the other replication server, lines show up 2 at a time.
> so it started at 9 or something
> then I got 10 & 11, 2 seconds later, 12, 13, etc...
> the same time tail -f on the server I was running the thing on sat
> there a while then produced some output.
>
> again, the afr machine updated more frequently, but the local machine
> just needed to get past some buffering
>
> what I saw was (you'll notice this faster if you remove the sleep)
> it would show some numbers, then jump and show another batch of
> numbers, then pause then show another batch.
> here's an output from tail -f
> Notice that at 63, there was some weirdness, like it was trying to
> print 1041 and 1860, I'm guessing
> then I got 1861 -.... and then I'd get a jump in numbers.. if I cat
> the file all the numbers are there.
>
> Also, in some of my tests I got input/output errors ----  I belive
> this was due to having tail -f running on the other afr server and
> this code you provided using > which truncates the file.  seems AFR
> has a little bug there if a file is open for reading on the other
> server and is truncated.  the io error went away when I killed the
> tail process on the other machine.
>
> 55
> 56
> 57
> 58
> 59
> 60
> 61
> 62
> 63
> 041
> 60
> 1861
> 1862
> 1863
> 1864
> 1865
> 1866
> 1867
> 1868
> 1869
> 1870
> 1871
> 1872
>
> I also noticed
>
> At 02:25 PM 1/12/2009, Bryan Talbot wrote:
> >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
> >
> >
> >
> >
> >_______________________________________________
> >Gluster-users mailing list
> >Gluster-users at gluster.org
> >http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://zresearch.com/cgi-bin/mailman/listinfo/gluster-users

-- 
Tel +27 11 234 5045
Fax +27 86 552 8833