Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 2 Apr 2000 10:41:40 -0700 (PDT)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc:        Bruce Evans <bde@zeta.org.au>, "Justin T. Gibbs" <gibbs@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG
Subject:   Re: cvs commit: src/sys/kern kern_mib.c vfs_bio.c src/sys/sys buf.h 
Message-ID:  <200004021741.KAA49471@apollo.backplane.com>
References:   <14634.954691700@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help

:In message <Pine.BSF.4.21.0004030144330.1715-100000@alphplex.bde.org>, Bruce Ev
:ans writes:
:
:>"struct bio" is unfortunately even more block-specific than "struct buf",
:>since it doesn't have anything like "off_t b_offset".  b_offset is
:>currently used mainly in the acd driver to handle weird block sizes.
:
:Well, I have b_offset in my cross-hair, because I know sos will roast
:me if I don't handle that case also :-)
:
:As far as I know, b_offset is only really used for physio and the only
:two drivers who understand non DEV_BSIZE multiple requests are the
:scsi-tape and atapi-cd drivers.
:
:This ties in somewhat with Justins email where he restates the idea
:Bruce half-jokingly proposed about a year ago: use struct uio for
:io carrier.
:
:The question at the heart of this is really: do we want to suffer
:the overhead of converting from byte offsets to sector number all
:the time or do we want to optimize for the predominantly used
:concept of sectors ?
:
:--
:Poul-Henning Kamp             FreeBSD coreteam member
:phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
:FreeBSD -- It will take a long time before progress goes too far!

    I had a conversation with Greg Lehey on -hackers a month and a half ago
    where we discussed the block-number-vs-offset issue.  I have included two
    exerpts below.

    I agree with Greg's assessment that 32 bit block numbers are starting to
    get a bit thin, and given the choice between going to 64 bit block numbers
    and 64 bit offsets, he (and I) would rather go to 64 bit offsets.

    Right now the kernel has serious problems with block translations due
    to different parts of the kernel expecting different block sizes.  The
    logical layer, for example, likes to assume 512 byte block sizes.  The
    physical layer depends on the device.  The fact that we often translate
    back and forth between block sizes alone is enough to move to a 64 bit
    offset and be done with it.  The code would probably wind up being 
    faster, and it would certainly be less confusing.

    512 byte block number translations limits the effective media size to
    about a terrabyte and any sort of block number translation will result
    in media size limits based on the block size.  Going to a 64 bit offset
    would make the limits more uniform and more easily understood.

    I would also appreciate it, Poul, if you are going to be so rabid about
    me getting my stuff reviewed, that you at the very least get your stuff 
    reviewed as well.  I don't have any problem with this commit, but 
    considering the fact that there are three people actively working on the
    VFS/BIO subsystem (you, Kirk, and me), doing commits in a vacuum 
    is not being a team player.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>

:From:     Greg Lehey <grog@lemis.com>
:Subject:  Re: Filesystem size limit?
:To:       Matthew Dillon <dillon@apollo.backplane.com>
:Cc:       Joe Greco <jgreco@ns.sol.net>, Kenny Drobnack <kdrobnac@mission.mvnc.e
:du>,
:        hackers@FreeBSD.ORG
:Date:     Thu, 17 Feb 2000 13:18:39 +1030
:
:
:On Tuesday, 15 February 2000 at 16:12:36 -0800, Matthew Dillon wrote:
:>> sure your amount of metadata that needs checking is reasonably low.
:>>
:>>>     Also, it seems like 64 bit processors will be in use before 1 TB
:>>> filesystems are common. Won't the filesystem need to be 64-bitted for
:>>> that?
:>>
:>> I would guess.  Matt Dillon commented on this already, though, and is much
:>> better suited to having an opinion about it.
:>
:>     Personally I think going to 64 bit block numbers is overkill.  32 bits
:>     is plenty (for the next few decades) and, generally, people running
:>     filesystems that large tend to be in the 'fewer larger files' category
:>     rather then the 'billions of tiny files' category, so using a large
:>     block size is reasonable.   At the moment the filesystem block size is
:>     the kernel's minimum disk I/O (at least when accessing portions backed
:>     by full blocks), but it is far more likely that we change the kernel
:>     to do less then full block reads then it is that we bump up the block
:>     number to 64 bits.
:
:I think that at some point we'll need larger block numbers than will
:no longer fit in 32 bits.  I'd rather we went to byte offsets, though,
:rather than block numbers.
:
:Greg



:Subject:  Re: Filesystem size limit?
:To:       Greg Lehey <grog@lemis.com>
:Cc:       Joe Greco <jgreco@ns.sol.net>, Kenny Drobnack <kdrobnac@mission.mvnc.e
:du>,
:        hackers@FreeBSD.ORG
:Date:     Wed Feb 16 20:49:53 2000
:
:
:
::I think that at some point we'll need larger block numbers than will
::no longer fit in 32 bits.  I'd rather we went to byte offsets, though,
::rather than block numbers.
::
::Greg
:
:    Good point.  When we are faced with having to move from 32 to 64 bit
:    block numbers, I agree completely that we should probably turn them 
:    into 64 bit byte offsets.
:
:						-Matt



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200004021741.KAA49471>