Subject: values for LFS_N_IBLOCKS/LFS_N_CLUSTERS
To: None <firstname.lastname@example.org, email@example.com>
From: Blair Sadewitz <firstname.lastname@example.org>
Date: 09/05/2007 13:42:01
[NOTE: the system I'm using is NetBSD/amd64 4.99.30, build with
I'm wondering if someone could enlighten me as to what reasonable
values for these should be.
In sys/ufs/lfs/lfs.h, it says that LFS_N_IBLOCKS and LFS_N_CLUSTERS
are "theoretically" segsize/bsize and segsize/maxphys, respectively.
The former is said to be "around 2" in practice--though two is small
enough integer-wise that I'm not sure what "around" means in this
My concern is that one or both of these values do not provide enough
reserved memory blocks for LFS filesystems with "modern-ish" segment
sizes, e.g. >1MB. Segment sizes of 2-3MB are optimal according to
(4*bandwidth*seek_time) for many consumer-grade ATA disks. With the
default block size of 8k, the "theoretical" values of
LFS_N_IBLOCKS/LFS_N_CLUSTERS are 256 and 32, respectively. Now, I
gather from lfs.h's comments that LFS_N_IBLOCKS _might not_ approach
How can I intelligently adjust this value for a given workload? Does
the value of LFS_N_IBLOCKS follow any sort of [logarithmic] curve?
As a data point, I've been using LFS_N_IBLOCKS/LFS_N_CLUSTERS of
128/32 with newfs_lfs defaults (1024k ssize/8k bsize/1k fsize), and
after 48 hours of building packages and the NetBSD source tree, I
haven't had one untoward lockup. If this does indeed correlate with
lfs's stability, I have no idea why.
It's not unlikely that I'm misunderstanding something, but might it be
time to re-evaluate these values?
Any help is appreciated.