[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: mke2fs options for very large filesystems



Markus Peuhkuri wrote:

fragmentation without unmounting fs (as it is not possible to bring system down for any long period of time)?

Thanks Joseph for pointing for filefrag (the system is running woody, that has older e2fsprogs, but found 1.35 from backports.org).


However, I'm a bit unsure how to interept figures (man page is quite short). As I run the filefrag for system, I get on average 1000 extents (for those 500 MB files) and perfection seems to be 2 to 5. I think "extent" is count of "segments" or count of fragments file is stored on disk. Thus average size for a fragment is about half megabyte, while average size of each file ranges from 100 kB to 1.5 MB.

Is that figure bad? Would it help to periodicaly clean disk more? The 90% disk full is to have safe margin in case there are problems with data analysis. If I make sure that all data is analysed properly then I could clean disk more to something below 50% full.

There seems to be a difference between partitions: for the other partition I got quite different figures: average is 1700 extents and minimum average framgent size is 81kB (5627 extents for 450 MB file). Both partitions usage is about the same, the latter one has sligthly larger files.

I also tested defragmenting Berkeley DB files using "cp -rp db db.new": the other db improved quite a lot, but for other it did not help much. Disk was about 87% full.

db/en: 41254 extents found, perfection would be 5 extents
db/ip: 68873 extents found, perfection would be 6 extents
db.new/en: 32606 extents found, perfection would be 5 extents
db.new/ip: 25 extents found, perfection would be 6 extents

Should test timing; it probably helped DB performance quite a lot.

Many disk I have, are mainly for archive purposes, thus a file is stored there once (one at time) and the file will stay there as long as disk works, only read every now and then. I think in that use the fragmentation does not have a lot? Maybe only the few last files are fragmented and have lower performance.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]