http://oss.sgi.com/bugzilla/show_bug.cgi?id=258
------- Additional Comments From mikes@xxxxxx 2003-10-07 19:29 PDT -------
Hi Nathan,
You're right, the machine does come back after a while (more than couple hours).
The system is very unresponsive during that time (it seems that it only responds
to ping, and nothing else). I don't know if this qualifies as a problem. The
other weird thing is that most of the time the disk LEDs don't show any io
activity, and the drives are "silent". There were only handful brief io activity
periods during that time. Writing 10G file onto this raid0 array usually takes
around couple minutes (~80 MB/sec).
The result of the program was the file with preallocated extents (du -h showed
10GB), and ls -l showed 0 length (logical EOF). I was unable to delete the file,
rm hanged with bdflush using 100% of 1 cpu, I waited couple hours and then did
hard reset. The same program with 1GB file size doesn't seem to cause the
problem.
I'll try to run this test on a different raid or machine, just to verify that
this behavior is not caused by some hardware problem.
The original goal was just to explore space reservation behavior. It seem
converting holes (sparse files) into unwritten extents is pretty fast, and
doesn't cause lots of io (truncate(10GB); ioctl(XFS_IOC_RESVSP, 10G)) (looks
like the fs just marks the extents), but reverse order of the operations
(ioctl(XFS_IOC_RESVSP, 10G); truncate(10GB)) causes lots of io (extents zeroed
out, instead of just being marked as unwritten).
Thanks,
-- Mike.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
|