Thomas Suiter wrote:
>
> Maybe I shouldn't say this since nobody is mentioning (maybe some voodo that
> shouldn't be done), but I was able to use "xfs_repair -fn <device>" I might
> have
> even had the same problem as you, check for the "bad hash table... would
> rebuild"
> subject line from 6/19/01. My system froze a couple of times, filesystems
> shutdown, and did other weird things (files disapearing but ls would know
> about
> them), etc. I believe it's something hardware related with me, I haven't had
> the
> time to run it down yet (I ran the memtest86 with no problems, so I'm guessing
> maybe a hd issue).
When I first installed an XFS kernel, which was out of date and
somewhere in the 2.4.2 area, I ran into a similar problem, but the cause
was apparently my tcsh shell. That shell does not properly support large
files, and the file I was testing was over 16 GB. I could see it with
ls, but could not rm it by any means. I had the ability to create a
single tar archive file of an entire main partition from ext2, with the
output being saved on XFS. XFS supported it, so it was able to create
it, but the shell itself did not, and the shell was required to interact
with rm, but not tar. catch 22. The particular kernel did have LFS
support, but on occasion you will still see individual applications that
don't live with it.
D. Stimits, stimits@xxxxxxxxxx
>
> "D. Stimits" wrote:
>
> <lots snipped>
>
> >
> > have no idea if normal journaling would have had any problems coping
> > with it. Is there no way to run xfs_repair with "no actual modify by -n"
> > on a mounted xfs partition, or read-only mounted xfs partition?
> >
> > D. Stimits, stimits@xxxxxxxxxx
|