On 06/28/05 01:06:54AM +0200, Prakash Punnoor wrote:
>
> So I gave ext3 a try. Very robust, but at the same time slooow. I couldn't
> bear it after some months. So I gave xfs another try. Yes, now it felt much
> better. Still not that fast as reiserfs, IIRC, but better than the first time
> I tried. I am still having xfs on / and it works pretty well, and is rather
> robust against hard locks with about the same amount of data losing as
> reiserfs. But what annoys me very much, is that I have to run xfs_repair by
> hand and by booting from another partition. Even after a hard lock, the
> partition mounts w/o problems and everything seems OK, but it only seems like
> that. In fact after some hours/days of use, you'll notice oddities, like files
> or directories which cannot be removed and things like that. After running
> xfs_repair everything is back in order.
I don't know what was going on with your systems, but I've been using XFS
since the original 1.0 Linux release from SGI and I'd guess that I've had to run
xfs_repair less than 10 times and most of them were on Alpha and Sparc64
before issues with those arches got ironed out.
Right now I have XFS on both Alpha and Sparc64 and I haven't had
any issues on either box. Infact the Sparc64 box's XFS filesystem was
converted from reiser3 because the some part of the filesystem got
mysteriously corrupted in such a way that reiserfsck and the reiser3 driver
both thought it was fine but accessing a certain file would cause a lockup.
I really hope the reiser4 userland tools are a lot better than the reiser3
tools, that's an area that reiserfs has lagged behind hugely IMO.
>
> In between I gave an alpha (or rather several alphas) of reiser4 a try - but
> not on /, just on /usr. Well, I wouldn't say it was extraordinary fast. In
> fact it felt slower than reiserfs V3, but much more space efficient. And to my
> surprise it was very robust as well. Hard-locks were no problem. Only annoying
> then was, that unmounting regularly produced oops but later versions corrected
> that. But nevertheless it didn't survive, as like V3, with time V4 became
> slower and slower. In this case no year was needed, but just one month or
> alike. So end of test...but in fact I'll give V4 another go in the near future.
>
>
> All in all I can say that every fs I tested was able to not smoke all of my
> data, even using an instable machine - but only ext3, reiser v3 and v4 were
> non-annoying. But xfs is majorly annoying in that respect. I hope that new
> versions will be able to keep consistency w/o having to run xfs_repair every
> time after a lock-up...
>
> But what I don't understand is, that sometimes even files, which were only
> opened for reading, got overwritten with @^@^@ after a lock-up. I don't
> understand the logics here, how this could happen.
>
> Thx for your time,
>
> Prakash
Jim.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]