Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 319733 - gentoo-sources-2.6.33-r2: Unable to copy a large file to an ext2 file system
Summary: gentoo-sources-2.6.33-r2: Unable to copy a large file to an ext2 file system
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: AMD64 Linux
: High normal (vote)
Assignee: Gentoo Kernel Bug Wranglers and Kernel Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-14 16:20 UTC by Thomas
Modified: 2010-09-15 17:03 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas 2010-05-14 16:20:15 UTC
Now, this is really weird: I have a 16 GB USB stick (15682304 blocks, in fact) with an ext 2 file system and 8327160 blocks free, 0 % reserved for root.  Now i try to copy a file of 6166280458 bytes to it.  After 5944201216 bytes, cp (or the kernel) claims the drive to be full.  Removing the file, syncing the drive, unmounting, remounting the drives always yield the same result.

If i monitor the cp process with df, after copying just a few hundred megs, the drive mysteriously fills up much faster than the cp process writes data to it.  Stopping the cp process and syncing the drive frees a few gigs of drives space, but kill -cont immediately lets it disappear again.

Right after the cp process fails ("disk full"), there are 2516592 blocks free.  Just to put the remaining data onto the drives, i tried "tail -c +<number> <src> >> <dst>.  After writing just a small amount of data, the free space shrinks to 621776 blocks, after the tail process finishes, there are 2299504 free blocks.

What does the kernel do with the free drive space during the cp process?

Reproducible: Always

Steps to Reproduce:
1. Have a USB drive with 8327160 blocks free
2. Try to copy a file of 6166280458 bytes to it
3. cp fails after writing 5944201216 bytes
4. After cp fails, there are 2516592 blocks free.

Actual Results:  
cp fails with "disk full"

Expected Results:  
cp succeeds
Comment 1 Thomas 2010-05-19 16:43:54 UTC
Further information:
- gentoo kernel 2.6.33-r2
- ext4 driver for ext2
Comment 2 Mike Pagano gentoo-dev 2010-05-19 17:03:04 UTC
can you show me the output of 

df -i

after you get the 'disk full' message
Comment 3 Thomas 2010-05-19 17:50:57 UTC
There are more than enough inodes, except if they mysteriously disappear, too.

This is the state before copying (after removing the file again, to be precise):

thomas # df -i /dev/sdb1
Dateisystem           Inodes   IUsed   IFree IUse% Eingehängt auf
/dev/sdb1              17280     138   17142    1% /mnt/usb

Is this enough information or do you want me to copy the file again, monitoring the inodes this time?
Comment 4 Mike Pagano gentoo-dev 2010-05-19 18:42:16 UTC
yes ---- after you get the 'disk full' message
Comment 5 Thomas 2010-05-19 21:03:58 UTC
No surprise here, during and after the cp:

thomas ~ $ df -i /mnt/usb/
Dateisystem           Inodes   IUsed   IFree IUse% Eingehängt auf
/dev/sdb1              17280     139   17141    1% /mnt/usb

The "lost" disk space reappears only after a sync (or probably after some waiting).

BTW: i was not able to reproduce this strange behaviour with vanilla-kernel 2.6.34.
Comment 6 Mike Pagano gentoo-dev 2010-09-12 14:48:38 UTC
Is this still an issue with the latest 2.6.35 kernel?
Comment 7 Thomas 2010-09-15 09:57:05 UTC
This issue seems to have disappeared with gentoo-sources-2.6.34-r6 as well as with 2.6.35-r5.
Comment 8 Mike Pagano gentoo-dev 2010-09-15 17:03:23 UTC
Closing as there will be no more 2.6.33.X kernel versions and it is fixed in the next two kernel releases.