http://oss.sgi.com/bugzilla/show_bug.cgi?id=258
------- Additional Comments From nathans@xxxxxxx 2003-13-07 15:53 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.
Yes, its certainly not a good thing.
> 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.
That sounds bad. I know of one bug in the unwritten extent code that
I'm trying to find time to look at, perhaps this is a variant on that.
I'll let you know when I have a fix. Still, this issue of yours does
need some other tweaks to make it behave better - I will have a go at
fixing this up too at some point - we shouldn't have to issue this much
IO at all I think.
> 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.
Taa.
> The original goal was just to explore space reservation behavior. It
> seems 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).
Yeah, this is just the way the original XFS code was written, I'll see
if I can make it any better when I can get to it.
thanks.
-- Nathan
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
|