Bill Gradwohl wrote:
what did it say?
Here's the script I used:
for ((i=0; i<2100; ++i)); do cp x FILE.$i done
The "x" file is just under 1GB big. I expected the script to fail at roughly
the i=2000 mark.
At the i=1001 point, I just got a string of "... no space left on device."
messages from cp.
BTW - while this loop was executing, I was getting about 1GB/min via the cp
command. You say you're getting 1GB every 10 seconds. How are you doing it?
The box I'm using is a 2 CPU XEON @2.4Ghz with 2G RAM running absolutely
stock FC1 - no patches whatsoever. I don't believe any patches would address
this issue.
I'm doing:
while true; do dd if=/dev/zero of="`date`" bs=1048576 count=1024; done
Because I'm extremely lazy ;-) My system is dual 2.8 GHz Xeon with 2 GB RAM, with two Escalade 7506 controllers, each of which has 8 300 GB drives attached as a RAID 10 - 300GB * 8drives / 2mirrored = 1200 GB / 1024megs-in-a-gig = 1.17 TB. I created my ext3 fs'es with a very large number of inodes (1 per 4K) so the overhead is higher than normal. df -k reports the total size as 1135170164 K = 1.05 TB. I'm also running stock FC1, the only exception being that I did install the 2.4.22 kernel update build 2179.
36 GB to go... I'll wait until it completes to send this...
OK it got done. Final output from df -k is:
/dev/sdc1 1135170164 1135170164 0 100% /export/home /dev/sdd1 1135170164 699617620 376959076 65% /export/data
So the full 1.05 TB got filled up with nary a problem.
Here's my strong suggestion to you: Using fdisk, remove your partition and recreate it. Then remake your ext3 filesystem, and see what happens. I still have this feeling like parted is wack.
Good luck, and please let me know how it goes!
Martin
Oh, also, just to be clear, I created these filesystems before I ever installed that updated kernel RPM... so I don't think that's the problem.
