Adjust the description of HAMMER's storage limitations. I have rearranged
commit9d75361615f0b3dbcd176b774ef7bf5def753026
authorMatthew Dillon <dillon@dragonflybsd.org>
Fri, 12 Oct 2007 17:17:20 +0000 (12 17:17 +0000)
committerMatthew Dillon <dillon@dragonflybsd.org>
Fri, 12 Oct 2007 17:17:20 +0000 (12 17:17 +0000)
treeb8390cd72f0c91cf477c4358e26982cee4aa18c3
parentd217d4d98ac6fbea8bdd467edead6388cfe1a1c0
Adjust the description of HAMMER's storage limitations.  I have rearranged
the way clusters are organized in order to implement a layered storage
management mechanic within the cluster.  To do this the number of 16K
filesystem buffers in a cluster had to be limited to 4096.  This allows
several layered A-lists to be embedded in the cluster header instead of
just one but limits the cluster size to 64MB instead of 512M.  Without
any other changes this would have limited volumes to 2TB, which is too small.

Add a new super-cluster layer to support volumes larger then 2TB.  Instead
of being limited to 32768 clusters per volume we now have a limit of
16384 super-clusters per volume and 32768 clusters per super-cluster,
resulting in a limit of 32768TB per volume.

A super-cluster is just another 16K filesystem buffer which adds another
A-List layer to the volume's storage management scheme.  It turns out to
be totally trivial to implement.  Cluster allocations will still be optimal
in a super-cluster arrangement simply by caching the last super-cluster
an allocation was made from.
sys/vfs/hammer/hammer.txt