the previous version was absolutely fine.  this current version performs
extremely badly.  basically what happened on the previous version was that
a sparse file was created.  this version however does something incredibly
stupid: they create an initially-blank but full-sized file.  as that can
sometimes involve writing out a 1gbyte or a 4gbyte file it absolutely
hammers any system, rendering it completely unusable for several seconds
due to the I/O overload.

At 33.9 percent it would have been checking inodes in the inode table.
Assuming you are using the textual completion bar (as opposeed to some
fancy-shamcy graphical completion bar, which I don't think Debian
supports), there's really nothing that can go wrong.  At one point, I
believe Ubuntu had some scheme where it was getting the completion
information and displaying it on the graphical init screen.  If that
is hanging for some reason, that would be a bug in the fancy graphical
boot up display system, and it's not a bug in e2fsprogs.  You'll need
to figure out what graphical boot up system you are using, and file
your bug against that.

If you are seeing a textual completion bar, i.e, something which
looked like this:

/dev/lambda/backup: |==============                                  - 28.4%

Then the only explanation I can think of is either a very badly
corrupted file system (but then you would have seen lots of error
messages scrolling buy), or some kind of hardware fault.

In any case, there really isn't anything I can do about this, so I'm
closing the bug report.

Regards,

					- Ted

Hi,

On 31-12-13 07:30, Theodore Ts'o wrote:
 > If you are seeing a textual completion bar, i.e, something which
 > looked like this:
 >
 > /dev/lambda/backup: |==============
- 28.4%
 >
 > Then the only explanation I can think of is either a very badly
 > corrupted file system (but then you would have seen lots of error
 > messages scrolling buy), or some kind of hardware fault.
 >
 > In any case, there really isn't anything I can do about this, so I'm
 > closing the bug report.

I was looking at the textual completion bar and there were no errors
shown on the screen during the long delay.

I am not experiencing any hardware faults.

However, I understand there's not much you can do...

AFAIK there are two possible reasons for this behaviour:
1) In Preferences->Download the option 'Pre-allocate disk space for all
files' is checked (but that's not the default).
2) The option above is not checked but the download folder is within a
filesystem that doesn't support sparse files (at least on Linux) like FAT32
and exFAT. Assuming that sequential download is not checked, when a torrent
piece located GB away from the file beginning is received, the file has to
be extended by physically writing zeros to seek to that position and write
the piece.

When downloading to filesystems with sparse file support (like ext4 for
example) I could not observe such I/O overload, even with file
preallocation (at least with recent versions of libtorrent-rasterbar).

OTOH the issue is still present for downloads to certain filesystems (i.e.
FAT32, etc) and can cause severe performance issues especially with slow
storage.

Regards

BZ