Bug 103086 - Can't copy from nfs mounted directory to udf directory mounted via loop back device
Can't copy from nfs mounted directory to udf directory mounted via loop back ...
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
9
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-08-26 11:00 EDT by Doro Wiarda
Modified: 2007-04-18 12:57 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-30 11:41:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Doro Wiarda 2003-08-26 11:00:21 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
We have a Dell Precision 360, runinng Redhat 9.0, with
a 2.40 GHZ Pentium 4 (Hyper-threading enabled). It has 
two ethernet cards, one the NIC on the motherboard and an additional
3Com  card.

Among other things we want to burn data DVD discs on the machine.
Therefore I ran the following tests:

Using Redhat 9.0, with all current patches applied and 
the 2.4.20-19.9smp kernel (preliminary tests on the 2.4.20-20.9smp kernel
suggest the same problems as the 2.4.20-19.9smp  kernel): 
1) Run the following commands:
  /bin/dd  if=/dev/zero  bs=1024k count=4450 of=/tmp/Container
  /opt/bin/mkudffs -r 0x0102 --media-type=dvd /tmp/Container
  mount -o loop /tmp/Container /mnt/cdrom1
  
  (The mkudffs is from the udftools-1.0.0b2 package from sourceforge.net)

 Now copy data from a NFS mounted directory (containing  around 4-5 GB of
  data (directory is mounted via automount).

 This crashes the machine with /mnt/cdrom1 ~41% filled

2) Try the same, except substitute the dd command with:
    /bin/dd  if=/dev/zero  bs=1024k count=600 of=/tmp/Container
   and try to copy an NFS mounted directory (again mounted via
   automount) containing ~1GB data.

  This either brings the machine to a crawl (first try) or 
  crashes it (second try).

  /mnt/cdrom1 was about ~20% filled.

3) Do the same as in 2) but substitute ext2 for udf, i.e. issue the
   following commands:
   /bin/dd  if=/dev/zero  bs=1024k count=600 of=/tmp/Container 
   /sbin/mke2fs /tmp/Container
  mount -o loop /tmp/Container /mnt/cdrom1
 
  and copy an NFS mounted directory (again mounted via
   automount) containing ~1GB data.
 
   This works without any problems.

4) Same as 3), but subtitute dd command with:
   /bin/dd  if=/dev/zero  bs=1024k count=4450 of=/tmp/Container

   This works without problems.

Switch to 2.4.20-18.9 kernel. 
Repeat steps in 1), i.e. go back to using udf and DVD sized container file:
    No problems, cp works as expected

Switch to 2.4.20-18.9smp  kernel. 
Repeat steps in 1) - No problems, cp works as expected


Version-Release number of selected component (if applicable):
kernel-2.4.20-18.9

How reproducible:
Always

Steps to Reproduce:
1./bin/dd  if=/dev/zero  bs=1024k count=4450 of=/tmp/Container
2./opt/bin/mkudffs -r 0x0102 --media-type=dvd /tmp/Container
3.mount -o loop /tmp/Container /mnt/cdrom1
4. copy data (4-5GB worth) to /mnt/cdrom1
    

Actual Results:  Machine crashes or becomes unresponsive for minutes,
using the 2.4.20-19.9smp kernel

Expected Results:  Smooth copying of data and machine responsive comparable to 
other copy operations

Additional info:

see description
Comment 1 Bugzilla owner 2004-09-30 11:41:28 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem
persists.

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

Note You need to log in before you can comment on or make changes to this bug.