[OpenAFS] Re: Large files with 1.6.0pre2

[Ryan C. Underwood]

On Sat, Mar 05, 2011 at 04:49:17PM -0600, Andrew Deason wrote:
> The fileserver storage backend code caches file descriptors, so a
> previous access could have opened it. Either that, or we're somehow
> failing before we get to accessing the file data. But that seems
> unlikely if reads before the 2G mark are fine; you can access the
> beginning of the file, right?
> 
> You could restart the dafileserver process and start strace'ing right
> away, or try to correlate the open file decsriptors in /proc/foo/fd; of
> course, you can't do that if you wait until after the salvage happened,
> since the fileserver won't have it open anymore.

Yes, I did that, in that case I can observe the file being opened
O_RDWR|O_LARGEFILE and operated with 64-bit system calls:

[pid  5360] open("/vicepa/AFSIDat/3=/3=++U/8/L3/Que++6C44", O_RDWR|O_LARGEFILE) = 52
[pid  5360] fstat64(52, {st_mode=S_IFREG, st_size=2147483648, ...}) = 0
[pid  5360] gettimeofday({1299373872, 738840}, NULL) = 0
[pid  5360] ftruncate64(52, 2097152000 <unfinished ...>
....
[pid  5266] pwritev(0x34, 0x989ecda0, 0x10, 0x80000000, 0xffffffff) = -1 EINVAL (Invalid argument)
[pid  5266] fstat64(52, {st_mode=S_IFREG, st_size=2147483648, ...}) = 0

That pwritev() call sure looks interesting... why would the 32-bit
version be used there?

> Also, can you check if /vicepa/AFSIDat/3=/3=++U/8/L3/Que++kB44 is
> actually 2147483648 bytes long? Can you read the contents of the file
> directly from vicepa successfully? (just don't change anything in the
> data or metadata of the file)

Appears so:

valhalla:/vicepa/AFSIDat/3=/3=++U/8/L3# ls -l Que++6C44 
---------- 1 daemon root 2147483648 Mar  5 16:56 Que++6C44

# dd if=Que++6C44 of=/dev/null bs=10M
204+1 records in  
204+1 records out
2147483648 bytes (2.1 GB) copied, 101.624 s, 21.1 MB/s

-- 
Ryan C. Underwood, <nemesis@icequake.net>