Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 12 Aug 2009 00:16:09 +0000
From:      Naeem Afzal <nafzal@hotmail.com>
To:        <rick-freebsd2008@kiwi-computer.com>
Cc:        freebsd-fs@freebsd.org
Subject:   RE: filesystem size after newfs
Message-ID:  <COL111-W50B8F353BF8FD65761B242D1040@phx.gbl>
In-Reply-To: <20090811191837.GB66530@keira.kiwi-computer.com>
References:  <COL111-W23AF31CB4D2944209932C6D1070@phx.gbl> <20090811191837.GB66530@keira.kiwi-computer.com>

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

Thanks you so much that was good explanation.=20
For some reason using UFS1 or UFS2 did not make any size difference after I=
 changed the block size and fragment size to minimum (4K/512).=20
One more thing=2C I tried to make the same partition as geli with HMAC/SHA2=
56 authentication and it eats up even more space. Without this authenticati=
on=2C usage is pretty close to without geli.
#geli init -a HMAC/SHA256 -P -K da2-64bytes.key /dev/ad1d
# newfs -O 1 -U -l -m 0 -n -o space -f 512 -b 4096 -i 1048576 /dev/ad1d.eli=
/dev/ad1d.eli: 0.2MB (511 sectors) block size 4096=2C fragment size 512    =
    using 1 cylinder groups of 0.25MB=2C 63 blks=2C 32 inodes.        with =
soft updatessuper-block backups (for fsck -b #) at: 32
#df -H /testFilesystem  1K-blocks    Used     Avail Capacity  Mounted on/de=
v/ad1d.eli    228k    512B    228k     0%    /test

ada1.eli should have been 0.5MB=2C but seems like it is reserving some area=
 for geli? How much is needed for HMAC/SHA256? What is allocation scheme if=
 we go for this SHA256 authentication?
regardsnaeem



>
> There are a number of things of which you should be careful. Using UFS1=
=2C
> you won't be able to use bootstrap code larger than 8k and you won't be
> able to use large files (not a problem because your filesystem is only
> 512k). You also won't get snapshots=2C which you apparently don't want.
>
> Specifying inode density can put you in a bind if you need a lot of
> inodes. In my example there are exactly 16 inodes=2C which is somewhat
> limited. The first three inodes are reserved (2 is the root inode) which
> leaves you with a maximum of 13 files and/or directories. I'm assuming
> this isn't a problem since you're using such a small filesystem. The
> smaller block and fragment sizes help reduce the "wasted space" taken up
> by filesystem metadata=2C but will require some tuning if you want more
> inodes. Be sure that only one cylinder group is created=2C or you'll be
> wasting 16k or more for each cylinder group.
>
> I also recommend keeping the 8:1 ratio of blocks to fragments. If you do
> wish to tweak that=2C here are a few things to note. Minimum blocksize is
> 4096 and at least 4 blocks are allocated for each cylinder group (in
> addition to the leading 64k). More blocks are allocated if the inode
> density is higher (specifying a lower number to "newfs -i"). UFS1 can fit
> twice as many inodes in the same space as UFS2=2C which is why I recommen=
d
> using it with very small filesystems. Since filesystem metadata is always
> allocated in blocks=2C it doesn't really help to tweak the fragment size.
>
> At one time I was thinking of writing up a patch to newfs to allow you
> specify the superblock offset=2C so you could save 16-64k per cylinder
> group. But there are limitations=2C since the FFS code searches for
> superblocks at specific offsets=2C namely (in order): 64k=2C 8k=2C 0=2C 2=
56k.
> I also had thoughts about patching it to remove the superblock backup=2C =
so
> that fs_sblkno could be 0 instead of 144 or 32. Because of its structure=
=2C
> at least 16k (8k bootstrap plus 8k initial superblock) is unused for ever=
y
> cylinder group in UFS1 (at least 72k for UFS2).
>
> There isn't much to be gained in such a patch except for very small
> filesystems such as in your case. When you're dealing with 512k=2C that
> extra 16k (or more) is starting to look significant (3%).
>
> HTH=2C
>
> -- Rick C. Petty

_________________________________________________________________
Get free photo software from Windows Live
http://www.windowslive.com/online/photos?ocid=3DPID23393::T:WLMTAGL:ON:WL:e=
n-US:SI_PH_software:082009=



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