Messages in this thread |  | | From | Daniel Phillips <> | Subject | Re: 512 byte magic multiplier (was: Large File support and blocks) | Date | Fri, 01 Sep 2000 20:49:14 +0200 |
| |
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/
|  |