Hi Greg -
Sorry, I didn't explain things very well, let me try to do better. :)
XFS preallocates space at the end of the file, assuming that you'll
probably use it, and things will be more efficient that way. When you
close the file, this "extra" space is removed.
Somehow, some files on your filesystem seem to be in the state where
these preallocated blocks are still hanging out there past EOF. This
isn't really a problem, everything is consistent, there are just more
blocks than need to be there for the data. The next time you open &
close the file, those blocks will be removed...
... unless you magically transport those files to a read-only device, as
in the case of your snapshot. In that case, when you open & close the
file, xfs was trying to clean up after itself, but the I/O failed (due
to the readonly nature of the device) and the fs shut down. (And the
kernel apparently oopsed after that... which is a different problem...
So, this new kernel will not try to clean up these past-EOF-blocks on a
The original files may still be on the "live" filesystem in this state,
for whatever reason. They can be "fixed up" by opening & closing them,
as tarring up the whole "live" filesystem would do.
IOW, your new CVS kernel is only avoiding the problem on the readonly
device; if you open & close the original files with either kernel, the
problem will go away, and either kernel should work again with the
On Thu, 2002-10-31 at 12:34, Greg Freemyer wrote:
> Thanks Eric,
> Current CVS kernel does indeed allow my backup to run.
> It is obvious that you guys have made a number of improvements in XFS/LVS
> integration in the last several months.
> I'm looking forward to the real 1.2 release.
> One question: do I still have an unusual data/meta-data problem on my LV that
> this kernel handles better Or did this kernel fix the on disk data itself
> and now I could go back to the old kernel?
Eric Sandeen XFS for Linux http://oss.sgi.com/projects/xfs
sandeen@xxxxxxx SGI, Inc. 651-683-3102