64-bit capable block device layer

64-bit capable block device layer

[Rik van Riel]

Hi Linus,

how would you feel about having the block device layer 64-bit
capable, so Linux can have block devices of more than 2GB in
size ?

I know that 64-bit arithmetic is expensive on 32-bit platforms,
but I have the idea there is a way around that for people who
don't want 64-bit capable block devices.

1. use blkoff_t for all block number arithmetic

2. in some header file, have

#ifdef CONFIG_BLKDEV_64BIT
typedef long long blkoff_t
#else
typedef long blkoff_t
#endif

This way, people running smaller&slower machines can chose to
do the cheaper 32-bit arithmetic and only the people using huge
block devices will have to do the 64-bit arithmetic.

(yes, basically the same trick as we're using for PAE)

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

Re: 64-bit capable block device layer

[Jens Axboe]

On Wed, Mar 07 2001, Rik van Riel wrote:
> Hi Linus,
> 
> how would you feel about having the block device layer 64-bit
> capable, so Linux can have block devices of more than 2GB in
> size ?
> 
> I know that 64-bit arithmetic is expensive on 32-bit platforms,
> but I have the idea there is a way around that for people who
> don't want 64-bit capable block devices.
> 
> 1. use blkoff_t for all block number arithmetic
> 
> 2. in some header file, have
> 
> #ifdef CONFIG_BLKDEV_64BIT
> typedef long long blkoff_t
> #else
> typedef long blkoff_t
> #endif
> 
> This way, people running smaller&slower machines can chose to
> do the cheaper 32-bit arithmetic and only the people using huge
> block devices will have to do the 64-bit arithmetic.
> 
> (yes, basically the same trick as we're using for PAE)

I already did this here, or something similar at least. Using
a sector_t type that is 64-bit, regardless of platform. Is it
really worth it to differentiate and use 32-bit types for old
machines?

-- 
Jens Axboe

Re: 64-bit capable block device layer

[Rik van Riel]

On Wed, 7 Mar 2001, Jens Axboe wrote:
> On Wed, Mar 07 2001, Rik van Riel wrote:

> > how would you feel about having the block device layer 64-bit
> > capable, so Linux can have block devices of more than 2GB in
> > size ?
>
> I already did this here, or something similar at least. Using
> a sector_t type that is 64-bit, regardless of platform. Is it
> really worth it to differentiate and use 32-bit types for old
> machines?

Wonderful !

I'm not sure how expensive 64-bit arithmetic would be on
eg. 386, 486 or 68k machines, or how much impact the extra
memory taken would have.

OTOH, I'm not sure what problems it could give to make this
a compile-time option...

regards,

Rik
--
Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml

Virtual memory is like a game you can't win;
However, without VM there's truly nothing to lose...

		http://www.surriel.com/
http://www.conectiva.com/	http://distro.conectiva.com/

Re: 64-bit capable block device layer

[Jens Axboe]

On Wed, Mar 07 2001, Rik van Riel wrote:
> > > how would you feel about having the block device layer 64-bit
> > > capable, so Linux can have block devices of more than 2GB in
> > > size ?
> >
> > I already did this here, or something similar at least. Using
> > a sector_t type that is 64-bit, regardless of platform. Is it
> > really worth it to differentiate and use 32-bit types for old
> > machines?
> 
> Wonderful !
> 
> I'm not sure how expensive 64-bit arithmetic would be on
> eg. 386, 486 or 68k machines, or how much impact the extra
> memory taken would have.
> 
> OTOH, I'm not sure what problems it could give to make this
> a compile-time option...

Plus compile time options are nasty :-). It would probably make
bigger sense to completely skip all the merging etc for low end
machines. I think they already do this for embedded kernels (ie
removing ll_rw_blk.c and elevator.c). That avoids most of the
64-bit arithmetic anyway.

-- 
Jens Axboe

Re: 64-bit capable block device layer

[David Weinehall]

On Wed, Mar 07, 2001 at 07:53:23PM +0100, Jens Axboe wrote:
> On Wed, Mar 07 2001, Rik van Riel wrote:
> > > > how would you feel about having the block device layer 64-bit
> > > > capable, so Linux can have block devices of more than 2GB in
> > > > size ?
> > >
> > > I already did this here, or something similar at least. Using
> > > a sector_t type that is 64-bit, regardless of platform. Is it
> > > really worth it to differentiate and use 32-bit types for old
> > > machines?
> > 
> > Wonderful !
> > 
> > I'm not sure how expensive 64-bit arithmetic would be on
> > eg. 386, 486 or 68k machines, or how much impact the extra
> > memory taken would have.
> > 
> > OTOH, I'm not sure what problems it could give to make this
> > a compile-time option...
> 
> Plus compile time options are nasty :-). It would probably make
> bigger sense to completely skip all the merging etc for low end
> machines. I think they already do this for embedded kernels (ie
> removing ll_rw_blk.c and elevator.c). That avoids most of the
> 64-bit arithmetic anyway.

My 386/486 and m68k-machines with 4/8/16 MB's of memory would be happy
for any and all options to remove code only needed by larger machines.
I'm pretty sure none of my 386:en will ever have 2GB of swap, 2GB of
blockdevices or 2TB filesystems...

Of course, for embedded kernels, being able to exclude block-devices
might be an idea. Or?


/David Weinehall
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Project MCA Linux hacker        //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: 64-bit capable block device layer

[Stephen C. Tweedie]

Hi,

On Wed, Mar 07, 2001 at 07:53:23PM +0100, Jens Axboe wrote:
> > 
> > OTOH, I'm not sure what problems it could give to make this
> > a compile-time option...
> 
> Plus compile time options are nasty :-). It would probably make
> bigger sense to completely skip all the merging etc for low end
> machines. I think they already do this for embedded kernels (ie
> removing ll_rw_blk.c and elevator.c). That avoids most of the
> 64-bit arithmetic anyway.

It's not just a sector-number and ll_rw_blk/elevator issue.  The limit
goes all the way up to the users of the block device, be they the
filesystem, buffer cache or block read/write layer.  

This is especially true for filesystems like XFS which need a 512-byte
blocksize.  At least with ext2 you can set the blocksize to 4kB and
get some of the benefit of larger block devices without having to
overflow the 32-bit block number.

Cheers,
 Stephen

Re: 64-bit capable block device layer

[Ingo Oeser]

On Wed, Mar 07, 2001 at 07:53:23PM +0100, Jens Axboe wrote:
> Plus compile time options are nasty :-). It would probably make
> bigger sense to completely skip all the merging etc for low end
> machines. I think they already do this for embedded kernels (ie
> removing ll_rw_blk.c and elevator.c). That avoids most of the
> 64-bit arithmetic anyway.

Do you know of any patches to do so?

Thanks and regards

Ingo Oeser
-- 
10.+11.03.2001 - 3. Chemnitzer LinuxTag <http://www.tu-chemnitz.de/linux/tag>
         <<<<<<<<<<<<       come and join the fun       >>>>>>>>>>>>