Re: [PATCH] remove 2TB block device limit

[Steve Lord <lord@sgi.com>]

On Wed, 2002-05-15 at 04:41, Hirotaka Sasaki wrote:
> Hi,
> My name is Hirotaka Sasaki and I work for VA Linux Japan.  
> We've had a need for large disk support as well, and so I've developed
> support for 64-bit block numbers and page cache indices. 
> 
> I'm not subscribed to this list so please CC on any responses.
> 
> All development I've done so far has been tested on 2.4.17 w/XFS
>         - linux-2.4.17
>         - xfs-1.0.2
>         - x86 (p3) architecture
> 
> The main revisions my patch includes:
>         - 64-bit page cache indices (doesn't support 64-bit mmap)

You will need to extend this into the xfs code base, particularly pagebuf.

>         - 64-bit block #'s, sector #'s in the block I/O layer
>         - 64-bit block device file (support for block #'s)
>         - raw and direct I/O support for 64-bit block and sector #'s
>         - 64-bit start_sect/nr_sect support in struct hd_struct
>         - 64-bit blk_size table
>         - 64-bit SCSI device sizes (sd_sizes/sr_sizes)
>         - 64-bit loop device
> 
>   This patch at:
>   ftp://ftp.valinux.co.jp/pub/people/sasaki/blk64/va-block64-2.4.17.patch
> 
> Other revisions (not necessarily including the kernel):
> 
> In order to create a file system larger than 2TB on XFS I,
>         - changed ioctl(BLKGETSIZE) to ioctl(BLKGETSIZE64) in mkfs.xfs
>         - in the kernel fixed an error in the handling of ioctl(BLKGETSIZE64)
> 
>   This patches at:
>   ftp://ftp.valinux.co.jp/pub/people/sasaki/blk64/va-blkgetsize64-2.4.17.patch
>   ftp://ftp.valinux.co.jp/pub/people/sasaki/blk64/xfsprogs-1.3.17-blkgetsize64.patch
> 
> In order to display a file system size larger than 16TB using df I,
>         - added a new system call to the kernel, statfs64
>         - added statfs64 to struct super
>         - modified XFS and NFSv3 to support statfs64
>         - created a new library, statvfs64, to use statfs64 which is
>                   then called by df command
> 
>   This patches at:
>   ftp://ftp.valinux.co.jp/pub/people/sasaki/blk64/va-statfs64-2.4.17.patch
>   ftp://ftp.valinux.co.jp/pub/people/sasaki/blk64/va-statfs64_xfs-2.4.17.patch
>   ftp://ftp.valinux.co.jp/pub/people/sasaki/blk64/va-statfs64_nfsd-2.4.17.patch
>   ftp://ftp.valinux.co.jp/pub/people/sasaki/blk64/va-statfs64_nfs-2.4.17.patch        
>   ftp://ftp.valinux.co.jp/pub/people/sasaki/blk64/fileutils-4.1-df_statvfs64.patch
> 
> I ran several tests on XFS by creating a file system and mounting
> it on the loop device.  I noticed that the size of the file system
> is limited to 16TB by XFS_MAX_FILE_OFFSET.  I need to test file systems
> > 16TB so I changed XFS_MAX_FILE_OFFSET to (long long)((1ULL<<63)-1ULL).
> However, XFS internally uses unsigned long's for the page cache indices
> which means everything works great until you mount the file system, but
> after that it all falls apart.

XFS_MAX_FILE_OFFSET on linux was reduced to reflect the maximum
cachable offset in a file. This only affects access to files themselves,
not to metadata. For the metadata end of things you need to look at
_pagebuf_lookup_pages in fs/xfs/pagebuf/page_buf.c. I have not looked
at your patches yet, but abstracting the page index into a special
typedef would be the way to go if you have not already done so.

I am about to totally revamp the XFS I/O path, so you might want to
wait a bit and then pick up the xfs cvs tree from oss.sgi.com.

Steve

-- 

Steve Lord                                      voice: +1-651-683-3511
Principal Engineer, Filesystem Software         email: lord@sgi.com