From: Andreas Dilger <adilger@clusterfs.com>
Date: Thu, 1 Aug 2002 11:48:56 -0600
To: jpiszcz@lucidpixels.com
Cc: linux-kernel@vger.kernel.org, lftp@uniyar.ac.ru, lftp-devel@uniyar.ac.ru,
       apiszcz@mitre.org, ext2-devel@lists.sourceforge.net
Subject: Re: Nasty ext2fs bug!
Message-ID: <20020801174856.GA29562@clusterfs.com>
Mail-Followup-To: jpiszcz@lucidpixels.com, linux-kernel@vger.kernel.org,
	lftp@uniyar.ac.ru, lftp-devel@uniyar.ac.ru, apiszcz@mitre.org,
	ext2-devel@lists.sourceforge.net
References: <Pine.LNX.4.44.0208011150310.17729-100000@lucidpixels.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.44.0208011150310.17729-100000@lucidpixels.com>
User-Agent: Mutt/1.4i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2162
Lines: 46

On Aug 01, 2002  12:54 -0400, jpiszcz@lucidpixels.com wrote:
>  Summary: When using lftp with the pget -n option for large files, once the
>           file is complete the problem begins.  If you try to copy, ftp, or
>           pretty much anything that involves reading the file, it is "stuck"
>           at a rate of 800KB/s to 1600KB/s.

The problem is obvious - there are many threads writing to the same
file, and the filesystem cannot really do a good job of allocating
blocks for these threads.  When you are reading the file back, the
disk is seeking like crazy to read the data from the disk.

It would be possible, even desirable, to have the block allocation
algorithm try and keep enough empty space on the disk for sparsely
written files, but this is a rather uncommon usage.

If you copy from this fragmented file to a new file, then the new file
is layed out contiguously on disk so readahead works and no seeking is
involved when reading the new file.

>  Problem: The pget -n feature of lftp is very nice if you want to maximize
>           your download bandwidth, however, if getting a large file, such
>           as the one I am getting, once the file is successfully
>           retrived, transferring it to another HDD or FTPing it to another
>           computer is very slow (800KB-1600KB/s).

I find it hard to believe that this would actually make a huge
difference, except in the case where the source is throttling bandwidth
on a per-connection basis.  Either your network is saturated by the
transfer, or some point in between is saturated.  I could be wrong, of
course, and it would be interesting to hear the reasoning behind the
speedup.

Cheers, Andreas

PS - thanks for the very detailed bug report - if only all bug reports
     were so full of useful information...
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/