| 1 |
Peter Gordon wrote: |
| 2 |
|
| 3 |
>On Mon, 2005-10-31 at 20:34 -0800, Joshua Schmidlkofer wrote: |
| 4 |
> |
| 5 |
> |
| 6 |
>>For a more sustainable situation, switch to XFS [It involved a |
| 7 |
>>backup/format/restore by whatever means you want] In any case, xfs |
| 8 |
>>has a tool called 'xfs_fsr' Which means 'file system reorganizer'. |
| 9 |
>>It does defragmentation, and balances some other stuff too. I run it |
| 10 |
>>weekly on my production servers, and nightly on most of my |
| 11 |
>>workstations. |
| 12 |
>> |
| 13 |
>> |
| 14 |
> |
| 15 |
>Thus why it is broken by design in my view. A good filesystem should not |
| 16 |
>need to be defragmented. All filesystems will become fragmented over |
| 17 |
>time, but a filesystem which is well-behaved should take minimal, if |
| 18 |
>any, performance loss from it. |
| 19 |
> |
| 20 |
> |
| 21 |
|
| 22 |
The performance impact of fragmentation is unavoidable. It is a simple |
| 23 |
physical fact that seeking the heads on a disk drive and waiting for the |
| 24 |
platter to spin around to a fragment is a time-consuming operation, |
| 25 |
taking between 6ms (on very fast SCSI hard drives) and 20ms (on very |
| 26 |
slow laptop hard drives). The average 7200rpm desktop drive has an |
| 27 |
access time of around 12ms. At that speed, anything smaller than about |
| 28 |
one megabyte can actually take longer to access than it takes to read. |
| 29 |
The only way to avoid the performance impact of fragmentation is to not |
| 30 |
fragment to begin with, which is what most linux filesystems try to do, |
| 31 |
and where Microsoft fails miserably. |
| 32 |
|
| 33 |
The way xfs defends against fragmentation is a bit smarter than ext2/3 |
| 34 |
at this point, because it delays the allocation step until the data is |
| 35 |
actually written to disk. This means that it can wait until the last |
| 36 |
possible moment before deciding where on the disk the file (or fragment |
| 37 |
of a file) should live, and thus should create fewer fragments overall. |
| 38 |
This is assuming that whatever is creating or appending to the file |
| 39 |
doesn't flush after every write of course... |
| 40 |
|
| 41 |
Ext2/3 tackles fragmentation by pre-allocating blocks when a file is |
| 42 |
growing. It is effective, but would be even more effective with delayed |
| 43 |
allocation. Note that this pre-allocation is not preserved when the |
| 44 |
file is closed, it is only active for files that are open and growing. |
| 45 |
|
| 46 |
Based on what the developers presented at the 2005 OLS, delayed |
| 47 |
allocation, and an extents-based format (ext4?) are coming: |
| 48 |
|
| 49 |
http://www.linuxsymposium.org/2005/linuxsymposium_procv1.pdf |
| 50 |
|
| 51 |
-Richard |
| 52 |
|
| 53 |
-- |
| 54 |
gentoo-user@g.o mailing list |
Archives