I just reformatted an 8Gb USB drive as ext3.
While as FAT32, it was reported as having well over 7Gb free (did not note the exact capacity).
I reformatted with mkfs.ext3 /dev/sda1
Now it is reported (oh, this is with properties in Nautilus) as having 6.8Gb capacity (free space actually).
Does this makes sense that ext3 has less available space than fat32?
on 9-25-2008 4:31 PM Robert Moskowitz spake the following:
I just reformatted an 8Gb USB drive as ext3.
While as FAT32, it was reported as having well over 7Gb free (did not note the exact capacity).
I reformatted with mkfs.ext3 /dev/sda1
Now it is reported (oh, this is with properties in Nautilus) as having 6.8Gb capacity (free space actually).
Does this makes sense that ext3 has less available space than fat32?
Ext3 reserves some space for root by default. I think it is like 5 or 10 %. That might be it.
On Thu, Sep 25, 2008 at 19:40, Scott Silva ssilva@sgvwater.com wrote:
Does this makes sense that ext3 has less available space than fat32?
Ext3 reserves some space for root by default. I think it is like 5 or 10 %. That might be it.
5% by default.
You can change it to 1% for your filesystem with this command:
tune2fs -m 1 /dev/sda1
HTH, Filipe
On Thu, 2008-09-25 at 19:31 -0400, Robert Moskowitz wrote:
I just reformatted an 8Gb USB drive as ext3.
While as FAT32, it was reported as having well over 7Gb free (did not note the exact capacity).
I reformatted with mkfs.ext3 /dev/sda1
Now it is reported (oh, this is with properties in Nautilus) as having 6.8Gb capacity (free space actually).
Does this makes sense that ext3 has less available space than fat32?
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>
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 ?
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 ?
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 ?
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>
on 9-25-2008 4:58 PM William L. Maltby spake the following:
On Thu, 2008-09-25 at 19:31 -0400, Robert Moskowitz wrote:
I just reformatted an 8Gb USB drive as ext3.
While as FAT32, it was reported as having well over 7Gb free (did not note the exact capacity).
I reformatted with mkfs.ext3 /dev/sda1
Now it is reported (oh, this is with properties in Nautilus) as having 6.8Gb capacity (free space actually).
Does this makes sense that ext3 has less available space than fat32?
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>
Also, depending on the makeup of the fat32 partition it would develop a lot of slack space (space taken up by the slack in the clusters).
So although fat32 looked like it had more space when empty, it would probably fill up slightly faster.
-
Filipe Brandenburger -
partha chowdhury -
Robert Moskowitz -
Scott Silva -
William L. Maltby