Sarah Jelinek schrieb:
Daniel,
To clear up a misconception about MTB UFS. The maximum density of inodes
that can be in a MTB UFS filesystem is 1 inode per megabyte of space.
This does not mean that a megabyte of space is used for every file. It
simply means you cannot have more than a million or so files per
terabyte of storage.
So to fill up such a file system to 100 percent your average file size has to
be 1MB - that's exactly what I said. I didn't say the block size was raised to
1MB.
Since also directories allocate inodes and are rarely filled with
ten-thousands of files, the average file size on MT-UFS has to be even larger
than 1 MB to fill the whole FS.
Luckily the limitation is only enforced in newfs/mkfs. You just have to redefine
#define MTB_NBPI (MB)
in usr/src/cmd/fs.d/ufs/mkfs/mkfs.c, recompile, (re-)newfs and you're done.
The reason for this is simple, it could take days or weeks to fsck the
filesystem.
I think this limit is way too high for "general purpose" use:
Filesystem size used avail capacity Mounted on
/dev/md/dsk/d200 309G 288G 17G 95% /export
Filesystem iused ifree %iused Mounted on
/dev/md/dsk/d200 1535475 1037325 60% /export
BTW a full fsck of above filesystem ran in ~33 Minutes and memory usage of
fsck raised to 46 MB. Most of the time it spent in Phase 1 (Check Blocks and
Sizes) - see below. So it would have been a wiser decision to raise the
block/fragment limit to something larger than 8 kByte.
Phase 1 - Check Blocks and Sizes ~24 Minutes
Phase 2 - Check Pathnames ~9 Minutes
Phase 3 - Check Connectivity <1 Second
Phase 4 - Check Reference Counts <1 Second
Phase 5 - Check Cyl groups <1 Minute
1535473 files, 151212388 used, 10602271 free (223755 frags, 2594629 blocks,
0.1% fragmentation)
Total: 33:12.95
Daniel
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org