On Tue, Jan 29, 2002 at 02:42:12PM -0600, Eric Sandeen wrote:
> On Tue, 2002-01-29 at 14:17, Andi Kleen wrote:
> > On Tue, Jan 29, 2002 at 01:56:41PM -0600, Eric Sandeen wrote:
> > > Yep, I just saw that. And FWIW, the stated limit for the filesystem
> > > size w/o XFS_BIG_FILESYSTEMS isn't quite right*. I think these are
> > > correct (these are internal XFS limitations):
> > >
> > > File size:
> > > o Without XFS_BIG_FILES, the max filesize is 1<<40, or 2TiB.
> >
> > I misread blockno in xfs_types.h as byteno. It should be 2^31 * blocksize,
> > which would be 2^43 with 4K blocks or more with bigger block size.
> > I don't see any other limit.
> >
> > How do you get to 2^40 ?
>
> in xfs_inode.h:
>
> #if XFS_BIG_FILES
> #define XFS_MAX_FILE_OFFSET ((long long)((1ULL<<(32+PAGE_SHIFT))-1ULL))
> #else
> #define XFS_MAX_FILE_OFFSET ((1LL<<40)-1LL)
> #endif
>
> and XFS_MAX_FILE_OFFSET is used to set sb->s_maxbytes
> (the latter case is stock XFS, the former is something I changed, might
> be off by a factor of 2? hm....)
>
> The comment blurb says
> * if XFS_BIG_FILES [...]
> * else 2^40 - 1 (40=31+9) (might be an int holding a block #)
>
> Not quite sure where this comes from, actually.
The 'int' is embedded in the block device interface in 2.4. It
applies to the filesystem, not the files
(but will hopefully change with the 64bit sector_t in 2.5/bio)
If you're sure that XFS doesn't use ints then it would be safe.
But anyways 2^40 < 2^43. It makes no sense to support files > the maximum
allowed size of block devices right now.
So in general my logic should be right and you could just drop a lot of long
long usage on 32bit linux (probably saving you a lot of headache with compiler
bugs and some binary bloat too :)
> > Also Linux/32bit is VM limited to 2^31 * PAGE_SIZE, so assuming PAGE_SIZE==
> > blocksize XFS_BIG_FILES should not be needed at all on 32bit linux.
>
> Does the VM actually enforce this limit? I thought I had a case where I
> could create a too-large file if XFS allowed it. Also I thought the
> limit was 2^32 * PAGE_SIZE... /me goes back to look.
llseek doesn't enforce it, but the VM only uses 32bit page index variables,
so it would wrap if it didn't enforce it. The checking has to be done
in generic_file_write, but of course in XFS you had to check yourself
because you don't use that.
>
> > On 64bit it probably makes sense to hardcode them both to 1.
> >
> > Where I am wrong ?
> >
> > > o With XFS_BIG_FILES, the max filesize is 1<<63-1.
> > > However, Linux can only handle 1<<(32+PAGE_SHIFT), or
> >
> > 2^(31+PAGE_SHIFT)
>
> Whoops... so the page cache index is signed...?
The page index in kernel is not, but some of the ABI. e.g. the mmap64
passes its signed offset argument as PAGE_INDEX, which limits it to
LLONG_MAX instead of ULONG_MAX.
Also it's generally safe to not challenge the mighty sign extension @)
-Andi
|