On Thursday 29 April 2010 20:03:20 Joe Brenner wrote: > Boyd Stephen Smith Jr. <b...@iguanasuicide.net> wrote: > > Joe Brenner wrote: > > > Ron Johnson <ron.l.john...@cox.net> wrote: > > > > B. Alexander wrote: > > > > > Ron Johnson<ron.l.john...@cox.net> wrote: > > > > >> XFS is the canonical fs for when you have lots of Big Files. I've > > > > >> also seen simple benchmarks on this list showing that it's faster > > > > >> than ext3/ext4. > > > > > > > > > > Thats cool. What about Lots of Little Files? That was another of > > > > > the draws of reiser3. > > > > > > > > That same unofficial benchmark showed surprising small-file speed by > > > > xfs. > > > > > > Would you happen to have any links to such benchmarks, unofficial or > > > otherwise? > > > > > > My experience has been that whenever I look at filesystem benchmarks, > > > they skip the many-small-files case. I've always had the feeling that > > > most of the big filesystems cared a lot about scaling up in file-size, > > > but not too much about anything else. > > > > NB: This is my best recollection; I'm not looking this up right now. > > Please check my facts, I'd love to know if I'm wrong. > > Like I said, I *have* looked at filesystem comparisons a number of times.
So have I. I didn't mean to imply otherwise. I looked at them for deciding on reiserfs, then I replicated the results on my own hardware using bonnie++ before restoring my backups. I also look around for results about once a year, to see if much has changed, or if there are new file systems I should look at. Less often, I'll try and run my own bonnie++ tests, but not rigorously; they occur on my system under whatever load I happen to be running. > It's my problem to check your assertions? Trust, but verify. The note was only indicative that I wasn't didn't have data or analysis in front of me, so I was running off of memory. Usually, that's fine, but I was talking about specific file system implementation features in multiple file systems. Since I don't implement or debug file systems every day, I thought an idle warning was in order. > Why isn't it your problem to > check my assertions? It is. > > > I'm a Reiser3 user myself, and I've never had any problems with it. > > > > > > (The trouble with it being "long in the tooth" is mostly hypothetical, > > > isn't it?) > > > > Not really. > > Outside of one mention of "bugs on reiserfs that will not be fixed", > you're pretty much just describing the theory. I do understand that > using relatively unsupported software, even if it's pretty mature > software, can have it's problems. That's not a theory; or that least it is not hypothetical. It's proven true over and over, and software ranging from OSes to libraries to RDBMSes to desktop applications. > Just doing a few quick websearches, I'm reading about ReiserFS bugs > fixed as recently as 2006, 2007... It's not like it's not getting any > attention from developers. Took me a little while, but I see bug-fix patches from this year. It's not be abandoned quite as quickly as I was lead to believe. I still don't recommend it for new installs, but there's a-priori reason to migrate away from it right now. > > In addition, as file system technology advances, reiserfs will become > > less attractive for new installs and it will become more attractive to > > migrate way from it. > > I think you're better off if you rely on really well-tested migration > tools (e.g. "tar"). These have significant overhead over file system-specific methods. They are the both universal and fairly conservative, so your advocacy is well- justified. It's also pretty easy to do them wrong, or get a poorly performing file system out of them. It's easy to forget extended attributes and ACLs when using cp/tar/rsync; there may be other file system data that needs to be preserved, too (HPFS+ forks?). Taking a kernel tarball from a ext3 file system and extracting it on a reiserfs file system takes much longer than taking a kernel tarball from a reiserfs file system and extracting to on a reiserfs file system. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
signature.asc
Description: This is a digitally signed message part.
