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
Further information: - gentoo kernel 2.6.33-r2 - ext4 driver for ext2
can you show me the output of df -i after you get the 'disk full' message
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?
yes ---- after you get the 'disk full' message
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.
Is this still an issue with the latest 2.6.35 kernel?
This issue seems to have disappeared with gentoo-sources-2.6.34-r6 as well as with 2.6.35-r5.
Closing as there will be no more 2.6.33.X kernel versions and it is fixed in the next two kernel releases.