Messages in this thread | | | Date | Mon, 27 Jun 2005 21:07:28 -0400 | From | Jim Crilly <> | Subject | Re: reiser4 plugins |
| |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |