xfs
[Top] [All Lists]

Re: [PATCH] Re: Files >4GB in XFS realtime partition

To: Chris Elston <celston@xxxxxxxxxxx>
Subject: Re: [PATCH] Re: Files >4GB in XFS realtime partition
From: Eric Sandeen <sandeen@xxxxxxx>
Date: Mon, 31 Oct 2005 15:13:49 -0600
Cc: linux-xfs@xxxxxxxxxxx, nathans@xxxxxxx, jchapman@xxxxxxxxxxx
In-reply-to: <200510311812.j9VICiO0030280@xxxxxxxxxxx>
References: <200510311812.j9VICiO0030280@xxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.6-1.1.fc4 (X11/20050720)
Chris Elston wrote:
This problem also does not occur on XFS data partitions because they make
use of allocation groups, across which extents records may not span.
Allocation groups have a maximum size of just under 4Gb.

FWIW, this is not the case any longer; AGs can now be > 4Gb.

However, I still haven't shown this problem on the data subvol...

I made a fs with 2 AGs, first is 5gb. Then I pre-allocated 5G into a file, and got -almost- 1 extent ;-) but first extent is nearly 5g. I wrote "1" to 0 bytes and "2" to 2^32+4097 bytes, and read it back. Seems ok, oddly enough.

penguin3:~ # ./allocsp /mnt/test/bigfile
pwrite at offset 0
pwrite at offset 4294972296
penguin3:~ # xfs_bmap -v /mnt/test/bigfile
/mnt/test/bigfile:
 EXT: FILE-OFFSET           BLOCK-RANGE        AG AG-OFFSET           TOTAL 
FLAGS
   0: [0..10485663]:        96..10485759        0 (96..10485759)   10485664 
10000
   1: [10485664..10485759]: 10506304..10506399  1 (20544..20639)         96 
10000
penguin3:~ # hexdump /mnt/test/bigfile
0000000 0031 0000 0000 0000 0000 0000 0000 0000
0000010 0000 0000 0000 0000 0000 0000 0000 0000
*
100001380 0000 0000 0000 0000 0032
100001389
penguin3:~ #


<Prev in Thread] Current Thread [Next in Thread>