Filesystem recommendations
in [Debian]
|
Prev: overcoming the 32k objects limit is ext3 - which file system to use?
Next: Why is Acroversion not properly updated?
From: Joe Brenner on 29 Apr 2010 15:20 Ron Johnson <ron.l.johnson(a)cox.net> wrote: > B. Alexander wrote: > > Ron Johnson<ron.l.johnson(a)cox.net> wrote: > [snip] > >> 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. I have a space I mount on /media/archive, which has everything > > from mp3/oggs and movies, to books to a bunch of tiny files. This will > > probably be the first victim for the xfs test partition. > > 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. 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?) -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/201004291917.o3TJHSIg000473(a)kzsu.stanford.edu
From: Boyd Stephen Smith Jr. on 29 Apr 2010 15:50 On Thursday 29 April 2010 14:17:28 Joe Brenner wrote: > Ron Johnson <ron.l.johnson(a)cox.net> wrote: > > B. Alexander wrote: > > > Ron Johnson<ron.l.johnson(a)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. Some of that reiserfs performance came from directories-as-hash-tables, which I believe ext3/4 supports and is native for btrfs. Some of that also came from tail-packing, which could come from the extents feature of ext4 and should be in btrfs. The final edge reiserfs had was above-average flushing/caching algorithms, and the development pushes in ext4 and btrfs have likely reduced or eliminated that; I think the unified block-device caching system in the kernel able helped make that not such a big deal. > 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. Reiserfs will probably be maintained in the kernel for a very long time, in that as any interfaces it uses are updated it will be updated to use the new interface. However, ISTR there are open bugs on reiserfs that will not be fixed. Similarly, I expect new bugs that can be blamed on the reiserfs code are less likely to be fixed than bugs than can be blamed on the ext2/3/4 or xfs code. In addition, as file system technology advances, reiserfs will become less attractive for new installs and it will become more attractive to migrate away from it. Unfortunately, migration tools are unlikely to be developed, outside of generic file system migration tools. Compare with btrfs_convert which allows an ext2/3 file system to be converted to btrfs with no data copying; such tools have to be aware of the internal structure of the file system and fewer and fewer developers will even HAVE that knowledge of reiserfs. The source will be available, sure, but even kernel maintainers interested in file systems are not interested in reiserfs. There's no drop-dead date for reiserfs in the kernel (AFAIK), so there's no pressing need to migrate away from it, but there is a lot of work on file systems that should both perform better and be supported better than reiserfs. -- Boyd Stephen Smith Jr. ,= ,-_-. =. bss(a)iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/ \_/
From: Kevin Ross on 29 Apr 2010 16:40 > From: Ron Johnson [mailto:ron.l.johnson(a)cox.net] > Sent: Saturday, April 24, 2010 3:49 PM > > On 04/24/2010 05:31 PM, B. Alexander wrote: > > > > Define "hates sudden power outages"...Is it recoverable? > > > > They got pretty corrupted. Maybe it's been robustified in the > intervening years. Apparently, it has been "robustified". http://old.nabble.com/XFS-data-loss,-and-a-fix-td15876910.html http://xfs.org/index.php/XFS_FAQ#Q:_Why_do_I_see_binary_NULLS_in_some_files_after_recovery_when_I_unplugged_the_power.3F -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/00ac01cae7dc$0242e400$06c8ac00$@net
From: Clive McBarton on 29 Apr 2010 18:00 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stan Hoeppner wrote: > Rob Owens put forth on 4/28/2010 8:26 PM: >> Many/most >> users don't run a UPS and sudden unexpected power loss is a real >> possibility for them. > > Really? I was under the impression that laptops and netbooks are now the > primary computer of well over 50% of users worldwide (not counting smart > phones). Laptops have a built-in UPS. A battery is kinda like an UPS, but not really. Two reasons: Some folks take it out when plugged in. This prolongs its lifetime. Obviously reduces UPS functionality a bit. The battery may not correcly predict running time, hence actually causing the powerdown which the UPS is supposed to protect against. This can happen even when the user "plugged in" their laptop but forgot to connect one end of the cable and does not check the little battery/plug icon on their screen. > sure there are many people who can barely afford a PC let alone a UPS. Used > laptops are a great fit for those users, assuming the batteries aren't shot. But the battery is usually the first thing to go. You can't even get a decently long warranty on a new battery AFAIK. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvZ/7YACgkQ+VSRxYk440/kvACeKOQNdWJEWP9N+S6Vhw+uZCJt ejcAn0pHNocxrdx3/YAgvRvyJi4m5Zrd =Y6hn -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4BD9FFB6.4070203(a)web.de
From: Stan Hoeppner on 29 Apr 2010 20:50
Joe Brenner put forth on 4/29/2010 2:17 PM: > Would you happen to have any links to such benchmarks, unofficial or > otherwise? Here's a somewhat old one from 2006 using Etch and rather old hardware (old then and very old now). The numbers are likely somewhat close to what you'd get with a current kernel on the same hardware given that fs performance typically doesn't make anything close to giant leaps within a major kernel rev, in this case 2.6.x. http://www.debian-administration.org/articles/388 Here's one from 2003 with some Bonnie++ testing: http://everything2.com/index.pl?node_id=1479435 -- Stan -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org Archive: http://lists.debian.org/4BDA283D.50509(a)hardwarefreak.com |