On Fri, 2008-09-26 at 07:50 +0530, partha chowdhury wrote: > William L. Maltby wrote: > > > Yes, for the reasons the others posted. However, if you know the > > "profile" of what you'll have on there, a substantial amount of space > > can be recovered by 1) make sure you have large block size and 2) > > reducing the i-nodes allocated to suit. > > > > Do a little thinking before you make these adjustments. I've used these > > (along with the reducing root-reserved) for years w/o problems. But if > > you get too radical and/or miss the reality with your profile > > substantially, you'll be in a "rework" scenario. > > > >> <snip sig stuff> > > > > i just used the tune2fs command to recover space on my secondary drive. > Afterwards i unmounted the drive and ran a e2fsck -f <device>. No error > was reported. Actually i used the tune2fs when the device was mounted so > i just became paranoid. now the e2fsck reported no error does that mean > my filesystem is still intact and no potential harm has been done ? Assuming you only used the -m or -r features, s/b OK. I *think* (un)setting the sparse feature also is OK. > > when i remount the drive and run df -h i see an extra 6G of free space. > > does e2fsck also check for data corruption or data integrity ? No. It only handles file system structure issues. Free counts, multiple links to the same block, directory consistency, etc. > > William, can you please tell in details if more space can be recovered > by using your two options and lastly is tweaking the default options of > file system a good thing or bad thing ? First, be sure to "man mke2fs" or "info mke2fs". Now, I only do the two things I mentioned: reduce reserved space and reduce i-nodes. Many things related to fragment size, etc. are just two esoteric and risky for a TDU (Typical Dumb User) like me. And the risk of severely increased maintenance effort increases the further you wander from a base install. Up front there are a few things to do. Get a record of how the current file system was constructed by running "tune2fs -l <your FS>" and a "mke2fs -n <other params you used when making it> <your FS>" (assuming that a default mke2fs was run or you know the parameters you used when originally making the FS. Make sure you DON'T FORGET THE -n! Run a "df" and "df -i" on the FS. Get a count of files (for large FS with lots of files we won't worry about whether a "file" is really a symlink or hardlink - s/b minimal impact) and a distribution of file sizes in the FS. The "find" command with various parameters is useful for this. Use all this to determine how many i-nodes you really want to have, allowing for FS activity (growth, shrinkage, "peak" size requirement periods, ...), "average" file size (I prefer to use the middle 80% median), and add a fudge factor of some %. The larger your "average" file size relative to the number of files, the fewer i-nodes you need. Then use the "-N" with mke2fs to specify number of i-nodes. Mke2fs will automatically adjust the i-node-to-blocks ratio. THIS WILL DESTROY WHATEVER IS ON THE FS! Use another partition or have excellent, tested backup and recovery routines in place. As mentioned, there is more tuning that can be done but I haven't found the need (or, unusual for me, the interest) to dig deeper and play with those items. I don't like high-maintenance women or systems! ;-) That's about it. Good luck and hoped this helped. > <snip> -- Bill