HAMMER update 06-Feb-2008

Matthew Dillon dillon at apollo.backplane.com
Thu Feb 7 16:01:55 PST 2008

:What is a volume?  Like a disk?  I think we should shoot for considerably=
:more than 256TB per disk.  Looking at the current growth, that's about 10=
:years from now.  And keep in mind that DragonFly already exists over 4=20
:years, so time is running fast.
:Sounds scary, but I think we should really consider if wasting bits is=20
:worth it.
:   simon

    I don't think it will be a big problem.  There are a ton of ways to
    break down the 64 bit offset to give us more bits.  The offset
    space for each virtualized fifo and for named block accesses will
    have to be big enough to hold the whole filesystem, so something
    like this would work:

    0000 vvvvvvvv offset[52] 		Direct access (4096 TB per volume)

    0001 name[36] offset[24]		Access via named large block
					(64 billion 16MB blocks)
    0010 reserved[60]			Fixed FIFO for undo space
    0011 reserved[60]			(reserved)

    0100 offset[60]			Virtualized FIFO for records
					(maps onto named blocks)

    0101 offset[60]			Virtualized FIFO for B-Tree nodes
					(maps onto named blocks)

    0110 reserved[60]			(reserved)
    0111 reserved[60]			(reserved)
    1000 reserved[60]			(reserved)
    1001 reserved[60]			(reserved)
    1010 reserved[60]			(reserved)
    1011 reserved[60]			(reserved)
    1100 reserved[60]			(reserved)
    1101 reserved[60]			(reserved)
    1110 reserved[60]			(reserved)
    1111 reserved[60]			(reserved)

    etc...  Tons of room.  All of these features will be used to improve
    performance.  The initial release will just use a fixed FIFO via
    the direct-access space.


More information about the Kernel mailing list