The Performance Of EXT4 Then & Now

[Apopas]

I have a question guys.
I have two hard disk drives. One is formatted with XFS and the other one with EXT4.

Whenever I copy a large file (i.e 4GB) from ext4 to xfs, the speed meter of KDE acts like a cardiogram, with a speed from 80 MB/s to 25 and vice versa. Finally the copy time is 58-60 seconds.
When I copy from xfs to ext4 the meter is stable from 67-70 MB/s and the total time is still about one minute.

At first glance I thought the KDE's meter was just a mess, but since it's always stable from xfs to ext4 I suppose this is not the matter.

So what' could be wrong guys?

[val-gaav]

These benchmarks are tough to process by themselves. The older benchmarks are really invalid because the code has a fatal flaw: no data safety. You can make ANY filesystem look fast if you are only pretending to write the data to disk. You might as well benchmark the write performance of /dev/null.

I think that's not correct... It's just that new ext4 settings for data safety are paranoid.

I'm using ext4 for a year now and I have not experienced any problems with 2.6.29-2.6.30 (using it right now).
While I had problems with 2.6.28 to be exact.

I think the settings from 2.6.31 and up are good for a paranoid server admin but not for a regular desktop use. I plan to stay with 2.6.30 for as long as I can but probably at some point new mesa/drm/xorg etc. will force me to upgrade.

[deanjo]

I have a question guys.
I have two hard disk drives. One is formatted with XFS and the other one with EXT4.

Whenever I copy a large file (i.e 4GB) from ext4 to xfs, the speed meter of KDE acts like a cardiogram, with a speed from 80 MB/s to 25 and vice versa. Finally the copy time is 58-60 seconds.
When I copy from xfs to ext4 the meter is stable from 67-70 MB/s and the total time is still about one minute.

At first glance I thought the KDE's meter was just a mess, but since it's always stable from xfs to ext4 I suppose this is not the matter.

So what' could be wrong guys?

I've noticed this too, it seems to behave the same as copying from the local machine to a remote machine. (Buffering to ram maybe?) On a network situation copying from a remote machine to the local displays accurate speeds.

[Apopas]

I've noticed this too, it seems to behave the same as copying from the local machine to a remote machine. (Buffering to ram maybe?) On a network situation copying from a remote machine to the local displays accurate speeds.

I see. That means if for some reason RAM is full or there is not enough of it, it delays the copy?

[deanjo]

I see. That means if for some reason RAM is full or there is not enough of it, it delays the copy?

No it seems more like the initial speed reported is actually dumping to ram then once that is full and the transfer is slower the "meter" then over compensates and reduces the reported speed. Maybe doing it over a network just exaggerates the result even more as initial speeds are well above network capacity.

[Apopas]

So I suppose there is not practical reason for such behaviour and since other filesystems acts correctly, I guess it's a minor bug that should be fixed, right?

[deanjo]

So I suppose there is not practical reason for such behaviour and since other filesystems acts correctly, I guess it's a minor bug that should be fixed, right?

I suppose, I just learned to live with it as one of those things you get used too since the true actual writing performance doesn't seem to suffer.

[Apopas]

Hmmm any possibility to be KDE's bug?

[deanjo]

Hmmm any possibility to be KDE's bug?

I would almost lean towards that as to who's bug it is. I don't think I've ever truthfully seen a true accurate progress meter though on high speed transfers on any OS or desktop though.

[Apopas]

With XFS at least, seems to be normal.
If I submit it as a bug to KDE, are you gonna to confirm it?