http://oss.sgi.com/bugzilla/show_bug.cgi?id=258
nathans@xxxxxxx changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |INVALID
------- Additional Comments From nathans@xxxxxxx 2003-07-07 21:37 PDT -------
hi Mike,
So, I have looked into this some more and am currently leaning toward
thinking this is "user error" (no offence, had me confused too).
What is leading you to think your machine is deadlocked? If you leave
it for awhile does it come "back to life"? When I initially ran this, I
too thought my machine was dead, but after awhile it did return and it
successfully completed the program.
What your program is doing is as follows:
- preallocates 10 gigabytes of space. what this equates to is a bunch
of unwritten extents being allocated as backing store for your file.
note: the end of file mark is still at offset zero afterward.
- closes the file. (this step is benign, could use ftruncate next..)
- truncates the file at 10 gigabytes. what this means to XFS is that
all of your allocated, but initialised space must now be initialised.
so, this means we need to zero all unwritten extents from current end
of file to the new end of file (i.e. from 0 to 10 gigabytes). this,
of course, generates _alot_ of IO...
So, what was the original goal here? You could alternatively have used
the ALLOCSP interface, which zeroes all data as its being allocated,
and avoids the extra overhead of converting all unwritten extents into
"written" extents as well. Did you have kdb enabled on your machine?
If so, did you drop into kdb during your test? (doesn't happen to me).
If you do, then there is a real problem here which I'm not seeing yet.
cheers.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
|