lkml.org 
[lkml]   [2000]   [Sep]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: 512 byte magic multiplier (was: Large File support and blocks)
Date
Alexander Viro wrote:
>
> On Fri, 1 Sep 2000, Daniel Phillips wrote:
>
> > Linda Walsh wrote:
> > > It may not matter too too much, but blocks are being passed around as
> > > 'ints'. On the ia32 architecture, this implies a maximum of 512*2G->1T
> > > disk size. Probably don't need to worry about this today, but in a few
> > > years? Should we be changing the internal interfaces to use a long (or
> > > a long unsigned -- why signed?) Maybe for 2.5/2.6 timeframe? Just
> > > curious...
> >
> > As far as the VFS goes, this is only in the fs-dependent part of the
> > inode. The practical effect is the same.
> >
> > What I'd like to add is: while we're at it, how about losing the 512
> > byte magic multiplier and go with the filesystem block size? That way
> > Ext2 file size automatically goes up by a factor of 8 every time we
> > manage to double the filesystem block size (blocksize*2 and triple
> > indirect => 2**3).
>
> And what, pray tell, is the fs block size when you do tar cf /dev/hdc?
> Or fsck /dev/hdc1, for that matter...
>
> Device layer has no business to know about the filesystem. Really.

Sorry, I should have been more precise. I was thinking of Ext2 and I
was refering to this field:

struct ext2_inode {
...
__u32 i_blocks; /* Blocks count */
....
};

Curiously, this field is measured in 512 byte units, giving a 2TB Ext2
filesize limit. That's starting to look uncomfortably small - I can
easily imagine a single database file wanting to be bigger than that.
One way to fix this would be to add a superblock flag indicating that
this field is to be interpreted in units of filesystem blocks.

--
Daniel
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.079 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site