Re: File transfer speed slows 10x and more after reaching 1TB in size

Update:

I reformatted one of the 4TB drives to XFS, and did another transfer of 
the original 2TB image file from JFS to XFS.

What is interesting, is when I copy the 2TB image file from the JFS 
drive to the XFS drive, I still encountered the same slow down. It was 
doing OK at 1TB, but when I next checked on it, it was thrashing and 
slow at the 1.3TB mark and it persisted until completion, so the problem 
point starts somewhere between 1TB and 1.3TB. I spot checked the CPU 
usage and it was OK the whole time.

My next test was extracting the file system from the image file on the 
XFS drive to the free space on the same XFS drive (same partition), so 
from XFS to XFS. When I last did the file system extraction, it was from 
JFS to JFS, and it would slow down at around the 1TB mark (probably 
between 1TB and 1.3TB), but this time it ran smoothly until completion. 
I think this indicates that it is the reads from the large file are the 
source of the problem.

I have not yet tested transferring from XFS to JFS, but hope to give it 
a try once I find the time.

I think it is now very clear that JFS is the source of the problem, and 
it's the reads that are not working properly starting somewhere between 
1-1.3TB.

 From now on, I'll be using XFS when dealing with very large files.

On 16-02-09 03:07 PM, alanb wrote:
> I think XFS may be the better long term choice for disk imaging, as
> opposed to ext4, because ext4 has a 16TiB file size limit, which may
> already be too small for some disk images. I considered Btrfs, but it
> seems to be too early still for production use which is my situation.
>
> A few years back, I did try XFS but dropped it in favor of JSF because
> at the time JSF clearly performed better and used less resources (in my
> tests anyway). I'm reading that some (or all) of the performance issues
> with XFS have since been solved, so I'll also give XFS a try, at least
> the imaging process.
>
> On 16-02-09 03:00 PM, Jernej Simončič wrote:
>> On Tuesday, February 9, 2016, 22:42:02, alanb wrote:
>>
>>> In my case the CPU usage was normal throughout the whole process. Are
>>> you experiencing high CPU usage when the problem surfaces?
>> Yes, I first noticed that jfsCommit was using around 90-100% of a
>> core, and that the backup suddenly slowed down.
>>
>>> In my case, I noticed that my disk was "thrashing" about while in the
>>> slow state, the noise made by the drive in an open case was very
>>> noticeable. When it was transferring normally, the disk was nearly
>>> inaudible. Also the approximate 1TB threshold seemed to be a sharp
>>> dropping point, performance quickly degraded once that point was reached.
>> I can't speak of disk thrashing, because both computers where I
>> noticed this are in different rooms than where I normally work.
>>
>>> I will need to use something for these large images, the problem makes
>>> JFS unusable and the thrashing may even destroy my HD. My next test is
>>> to switch to ext4 or XFS and do a transfer of the same 2TB image file.
>> I switched to xfs on one computer, and it seems to perform well (one
>> of the backup images is currently 1043GB - I couldn't take this backup
>> with jfs at all, but there was a noticeable speed increase with
>> another, where the base image is 140GB - on jfs it took about an hour
>> to create increments and merge the oldest increment into base, while
>> it now takes about 10-15 minutes).
>>
>
> ------------------------------------------------------------------------------
> Site24x7 APM Insight: Get Deep Visibility into Application Performance
> APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> Monitor end-to-end web transactions and take corrective actions now
> Troubleshoot faster and improve end-user experience. Signup Now!
> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> _______________________________________________
> Jfs-discussion mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/jfs-discussion
>


------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________
Jfs-discussion mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jfs-discussion