Re: Filesystem recommendations
On Mon, Apr 26, 2010 at 11:22 AM, Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote: It's an aggressive migration plan, but reiser3 is just barely maintained in the kernel Would that be due to the system's creator having current living conditions unconducive to helping maintain his creation? http://en.wikipedia.org/wiki/Hans_reiser Or are there other reasons for the lack of maintenance of the reiserfs? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/l2n5cf6328d1005032355gafca63d7s609ac8c0fdf02...@mail.gmail.com
Re: Filesystem recommendations
On 05/04/2010 01:55 AM, Scarletdown wrote: On Mon, Apr 26, 2010 at 11:22 AM, Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote: It's an aggressive migration plan, but reiser3 is just barely maintained in the kernel Would that be due to the system's creator having current living conditions unconducive to helping maintain his creation? http://en.wikipedia.org/wiki/Hans_reiser Or are there other reasons for the lack of maintenance of the reiserfs? Few others have the desire and the knowledge. -- Dissent is patriotic, remember? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bdfcb10.2060...@cox.net
Re: Filesystem recommendations
On Tuesday 04 May 2010 01:55:08 Scarletdown wrote: On Mon, Apr 26, 2010 at 11:22 AM, Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote: It's an aggressive migration plan, but reiser3 is just barely maintained in the kernel Would that be due to the system's creator having current living conditions unconducive to helping maintain his creation? http://en.wikipedia.org/wiki/Hans_reiser Mr. Reiser stopped contributing to reiserfs3 some time before he murdered his own wife. He was contributing to reiserfs4, but his interactions with the kernel developers did not always encourage others to help address the technical issues that prevent reiserfs4 from being in the mainline kernel. Or are there other reasons for the lack of maintenance of the reiserfs? Mostly, fewer of the file system kernel hackers are interested in it. XFS, ext3/4, btrfs, and others have more advocates and active developers. -- 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.
More brtfs reporting (was: Re: Filesystem recommendations)
On Monday 03 May 2010 12:10:24 Boyd Stephen Smith Jr. wrote: On Monday 26 April 2010 16:34:38 Boyd Stephen Smith Jr. wrote: It doesn't appear to be a file system issue, but rather a problem with the initramfs scripts. It could also be rooted in my configuration. I know that my root= kernel parameter has to differ from the device name in my /etc/fstab in order to get the initramfs to correctly initialize LVM. I wanted to report that I was able to diagnose and solve this. The problem was that /lib/udev/vol_id in my initramfs could not identify a btrfs file system, which caused the scripts to try and mount the root file system using '-t unknown' as part of the command-line arguments. I upgraded initramfs-tools and udev to the Sid versions. This should cause a initramfs rebuild as part of the postinst, but if it doesn't do so on your system, be sure to run (update-initramfs -k all -u). Now my system boots unattended with a btrfs '/'. So, at this time, btrfs can be used for non-'/' file systems with the tools from lenny-backports. However, newer udev/initramfs-tools are required to boot with a btrfs '/'. I hope they are included in the Squeeze release. I have not, and probably will not test a btrfs '/boot'. I have also been encountering issues with suspend and resume on this new install. I don't currently believe these are btrfs-related, either, but fair warning. They were, again, not btrfs related. Initially mouse and keyboard were mostly dying on resume from RAM. (Alt+SysRq continued to work.) Upgrading acpid to lenny-backports resolved this issue for the most part. After that, the framebuffer was corrupted on resume from RAM. If I restarted X through Alt+SysRq+K (I use kdm), I could continue to use X, but all the other virtual consoles were unusable. I believed this to be an issue with xserver-xorg-video-intel, so I upgraded it to testing. At this point, normal booting would hang the GPU when starting kdm; no chance to address suspend/resume. Some troubleshooting indicated that if the vbesave init script from acpi-support were run prior to the kdm init script, that would cause the hang. If the vbesave init script was not run, the system operated normally. I purged acpi-support, since it was not a strong dependency of anything installed on the system. Boot worked normally. Suspend to RAM / resume works. Suspend to disk / resume works. Suspend to both (manually running /usr/sbin/s2both) and resume (from RAM) works. As you might guess, there were a number of unclean reboots during this time. btrfs never had issues that prevented booting. The journal replay / recovery is a bit less verbose that reiserfs and ext3, but it did occur and had to make some of the same corrections (unlinking 27 orphans). At one point, I did slightly suspect btrfs, so I ran a btrfsck while the file system was mounted. It could also benefit from being slightly more verbose, but it completed fairly quickly and reported no errors. I also did an on-line defragment of the whole file system around the same time. It took longer than I would like, since it gave no progress indication; again, more verbosity (or at least an *option*) would be appreciated. -- 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.
Re: Filesystem recommendations
On Monday 26 April 2010 16:34:38 Boyd Stephen Smith Jr. wrote: On Monday 26 April 2010 16:05:31 B. Alexander wrote: On Mon, Apr 26, 2010 at 2:22 PM, Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote: I'm also a current reiser3 user. I find the ability to shrink the filesystem to be something I am not willing to do without. You know, I said the same thing, but then as the kernel and GRUB and the like advanced, I noticed that my reiserfs partitions would have to replay the journal every time I rebooted, even after a clean shutdown. I started calculating how many times I shrunk any of my partitions in the last 8 years, and I can only recall twice. And since I have several terabytes around the house, I figure I can migrate data and delete/recreate partitions if I really need to reduce it. That doesn't seem right. I have been using reiser3 since 2005, and my system does not require a journal replay if I do a clean shutdown/reboot. A forced reboot through Alt+SysRq+B does trigger a journal replay (as it should). I also have 4+ tebibytes but most of them are allocated to filesystems. I've had to shrink filesystems dozens of times since 2005, during or after a data move. I don't use partitions (much), having been using LVM happily for everything except /boot. I'm hoping to be able to move that onto LVM once I move to GRUB2 and GPT. I have not read the rest of the thread, but my off-the-cuff recommendation would be to start migration to btrfs. Now that the on-disk format has stabilized, I am going to start testing it for filesystems other than /usr/local, /var, and /home. Assuming I can keep those running well for 6-12 months, I will migrate /usr/local, /var, and then /home, in that order, with a 1-3 month gap in between migrations. I might play with it for some non-critical partitions, or ones that I can mirror on an established filesystem, even if it is only to use in an Archive Island scenario, where I have a LV that I can mount, sync and umount. However, btrfs is not included in the kernel, is it? As I recall, nilfs2 has kernel support, but that was the only one of the new filesystems, at the time when I started looking at this. btrfs is included in 2.6.31.12-0.2-default in openSUSE 11.2. It is also included in linux-image-2.6-686 and linux-image-2.6-amd64 for lenny-backports, testing, and sid. I don't normally deal with other architectures/distributions, so it might also be available there. I've already encountered an issue related to btrfs in my very isolated deployments. The initramfs created by update-initramfs does not appear to mount it properly. Instead I am given an '(initramfs)' prompt and I have to mount the filesystem manually (a simple two-argument mount command suffices) and continue the boot process. That is enough to give me pause... It doesn't appear to be a file system issue, but rather a problem with the initramfs scripts. It could also be rooted in my configuration. I know that my root= kernel parameter has to differ from the device name in my /etc/fstab in order to get the initramfs to correctly initialize LVM. I wanted to report that I was able to diagnose and solve this. The problem was that /lib/udev/vol_id in my initramfs could not identify a btrfs file system, which caused the scripts to try and mount the root file system using '-t unknown' as part of the command-line arguments. I upgraded initramfs-tools and udev to the Sid versions. This should cause a initramfs rebuild as part of the postinst, but if it doesn't do so on your system, be sure to run (update-initramfs -k all -u). Now my system boots unattended with a btrfs '/'. So, at this time, btrfs can be used for non-'/' file systems with the tools from lenny-backports. However, newer udev/initramfs-tools are required to boot with a btrfs '/'. I hope they are included in the Squeeze release. I have not, and probably will not test a btrfs '/boot'. I have also been encountering issues with suspend and resume on this new install. I don't currently believe these are btrfs-related, either, but fair warning. -- 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.
Re: Filesystem recommendations
On 04/29/2010 02:17 PM, Joe Brenner wrote: Ron Johnsonron.l.john...@cox.net wrote: B. Alexander wrote: Ron Johnsonron.l.john...@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? They were posted to this list (within the last 6 months, I think). My experience has been that whenever I look at filesystem benchmarks, they skip the many-small-files case. It also did small file testing. 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. Yes, that's what xfs was designed for, and where it's strength always lay. But the benchmarks I refer to showed good results for xfs even with small files. 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?) It's certainly not suffering yet suffering from bit-rot. However, while ext4, xfs and btrfs are *definitely* being continuously improved I doubt that ReiserFS 3.5 is. (As usual, I could be totally wrong.) -- Dissent is patriotic, remember? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bdf837d.7060...@cox.net
Re: Filesystem recommendations
On 04/26/2010 03:25 AM, Stan Hoeppner wrote: [snip] If it took only 2 weeks for the bulk of this effort, I can't imagine they had to modify a ton of XFS code. IRIX was written in C as is Linux, so the changes in XFS were probably fairly minor. Windows is written in C, Linux is written in C. Thus, it should be trivial to port Windows drivers to Linux? Obviously not. Bottom line: just because two OSs are written in C doesn't mean that (even if they are both Unix work-alikes) they have the same guts (data structures, assumptions, etc). I'd venture to guess that the most significant Linux XFS changes were those for the 32bit X86 code base. IRIX and thus XFS were born on 64bit MIPS RISC CPUs. I *know* that part of what you wrote is wrong, since SGI started using MIPS chips in 1986 and the MIPS 4000 is from 1991. http://en.wikipedia.org/wiki/IRIX#History http://en.wikipedia.org/wiki/SGI_IRIS_4D http://en.wikipedia.org/wiki/MIPS_architecture#CPU_family XFS is from 1994, so it did have it's genesis on a 64-bit platform. -- Dissent is patriotic, remember? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bdfa1fe.1020...@cox.net
Re: Filesystem recommendations
Ron Johnson put forth on 5/3/2010 9:16 PM: On 04/29/2010 02:17 PM, Joe Brenner wrote: Would you happen to have any links to such benchmarks, unofficial or otherwise? They were posted to this list (within the last 6 months, I think). I've posted a few in the very recent past, although the content of the last two below is rather old, 2006 and 2003. Very recent raw data FS benchmark results for 2.6.34-rc3, includes all filesystems supported in the kernel: http://btrfs.boxacle.net/repository/raid/2010-04-14_2004/2.6.34-rc3/2.6.34-rc3.html Some older XFS benchmark/reviews with OP summary/recommendations: http://www.debian-administration.org/articles/388 http://everything2.com/index.pl?node_id=1479435 It's interesting that both OPs come to the same conclusion, that XFS is the best all 'round file system for a small business or home server. This is very ironic given that XFS was designed as a filesystem for storing and moving vast amounts of large file scientific visualization data. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bdfa875.5070...@hardwarefreak.com
Re: Filesystem recommendations
Ron Johnson put forth on 5/3/2010 11:26 PM: On 04/26/2010 03:25 AM, Stan Hoeppner wrote: [snip] If it took only 2 weeks for the bulk of this effort, I can't imagine they had to modify a ton of XFS code. IRIX was written in C as is Linux, so the changes in XFS were probably fairly minor. Windows is written in C, Linux is written in C. Thus, it should be trivial to port Windows drivers to Linux? Obviously not. They had it up and running in a couple of weeks. A couple of weeks to me would seem to say they didn't have to modify a ton of code. Or, maybe they're just really efficient programmers. The truth probably lies somewhere in between. Bottom line: just because two OSs are written in C doesn't mean that (even if they are both Unix work-alikes) they have the same guts (data structures, assumptions, etc). I made no such statements about the guts being the same or similar. I simply stated that because both the Linux kernel and XFS were written in C that the XFS code changes were probably fairly minor. They didn't rewrite it from the ground up. I've never found any documentation that details the changes and I don't have access to the original IRIX 6.5.x source code so I can't do a diff on the XFS code. I can only guess. And knowing what I do, I'm guessing I'm probably close to being on the money. I'd venture to guess that the most significant Linux XFS changes were those for the 32bit X86 code base. IRIX and thus XFS were born on 64bit MIPS RISC CPUs. I *know* that part of what you wrote is wrong, since SGI started using MIPS chips in 1986 and the MIPS 4000 is from 1991. You are correct. IRIX predates XFS by half a decade. IRIX was developed and released on the 32bit MIPS CPUs, the 2xxx and 3xxx series. http://en.wikipedia.org/wiki/IRIX#History http://en.wikipedia.org/wiki/SGI_IRIS_4D http://en.wikipedia.org/wiki/MIPS_architecture#CPU_family XFS is from 1994, so it did have it's genesis on a 64-bit platform. And that's the only point I was making about the 32bit x86 work. Even if XFS wasn't originally developed on MIPS64 in 1992/93, the XFS code base in 2001 was fully 64 bit and had been for many many years. Porting IRIX from 64bit MIPS to 64bit Itanium and other 64bit arches such as Alpha was far less of an effort than down porting it to 32bit x86, which came some years later, IIRC. Such a project requires changing a ton of data structures from 8 bytes wide to 4 bytes wide. The down port to 32bit x86 and the porting to other architectures was, TTBOMK, required to get XFS into the mainline kernel. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bdfb151.4060...@hardwarefreak.com
Re: Filesystem recommendations
Stan Hoeppner put forth on 5/4/2010 12:32 AM: 2001 was fully 64 bit and had been for many many years. Porting IRIX from 64bit MIPS to 64bit Itanium and other 64bit arches such as Alpha was far Self correction. That should read, top right, Porting XFS from -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bdfb582.9040...@hardwarefreak.com
Re: Filesystem recommendations
On 4/29/2010 7:36 AM, Stan Hoeppner wrote: In the U.S., given the numbers of cheap APC, Triplite, and Belkin UPS on the shelves at $big_box_store I'd say most U.S. desktop users have a UPS. I know I do. Naw. It ain't so. Most US users don't even know what a UPS is. APC quit calling their equipment a UPS, and now just call it a backup battery because of alphabet soup fatigue. And Jane Church-Secretary still doesn't know what it is or what it's for. Or or Jack Retired-Contractor. Joe Average. MAA -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bdaeb14.7000...@allums.com
Re: Filesystem recommendations
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 Johnsonron.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.
Re: Filesystem recommendations
On Thu, Apr 29, 2010 at 3:24 AM, Rob Owens row...@ptd.net wrote: On Mon, Apr 26, 2010 at 01:56:21PM +0200, Javier Barroso wrote: Hello Stan, Why Debian Installer doesn't change its default filesystem to xfs if it is better than ext3 / ext4? I think always is better stick to defaults if it is possible I've read articles which state that ext3 has superior resilience to sudden power loss. That sentiment has been echoed in this thread, by Stan I think, with statements like (paraphrasing): XFS is good for production servers which have uninterruptible power supplies. Good to know, thanks I will take a look! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/i2x81c921f31004282356xf4c875bcpf88220aa45102...@mail.gmail.com
Re: Filesystem recommendations
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. In the U.S., given the numbers of cheap APC, Triplite, and Belkin UPS on the shelves at $big_box_store I'd say most U.S. desktop users have a UPS. I know I do. Pretty much every computer user I know personally has a UPS. In other parts of the world I'm 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. Don't read me wrong. I'm not advocating XFS on laptops, although I do know of many folks who use it on laptops. For the average user there would be little performance benefit. For power users it's a valid possible choice. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd97d57.6010...@hardwarefreak.com
Re: Filesystem recommendations
Stan Hoeppner I'd say most U.S. desktop users have a UPS. I'd say most home desktop users and the majority of small businesses don't. I know I do. I don't. I can't afford it (and I've never lost important data in a power failure (but then I have little important data to lose)). Pretty much every computer user I know personally has a UPS. No non-power-user I know has one. Most don't know what one is. -- John Hasler -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87633a5rwr@thumper.dhh.gt.org
Re: Filesystem recommendations
On Thu, Apr 29, 2010 at 07:36:39AM -0500, 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. In the U.S., given the numbers of cheap APC, Triplite, and Belkin UPS on the shelves at $big_box_store I'd say most U.S. desktop users have a UPS. I know I do. Pretty much every computer user I know personally has a UPS. In other parts of the world I'm 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. I only know for sure of one friend who has a UPS. He's the sysadmin for his company. I don't even have one, and I know better! Good point about laptops and netbooks, though. By the way, I use XFS on my MythTV storage drive and I haven't had any problem w/ data loss due to power outages. It has happened to me several times, though, when I was using JFS. That's why I switched to XFS. (I chose JFS and XFS over EXT3 in this case, due to their ability to very quickly delete large files). -Rob -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100429134508.ga10...@aurora.owens.net
Re: Filesystem recommendations
On Thu, 29 Apr 2010 09:07:00 -0400 (EDT), John Hasler wrote: Stan Hoeppner wrote: I'd say most U.S. desktop users have a UPS. I'd say most home desktop users and the majority of small businesses don't. I know I do. I don't. I can't afford it (and I've never lost important data in a power failure (but then I have little important data to lose)). Pretty much every computer user I know personally has a UPS. No non-power-user I know has one. Most don't know what one is. I agree with John. Stan must hobnob with an elite crowd. I don't have a UPS at home either, and I don't know anyone that does. I do have one at work, but even there most desktop systems aren't on it. The only reason that my desktop system uses the UPS is that my cubicle is on raised floor inside the computer room and I connected it myself. Most desktop users, even at the office, are not so privileged. And my employer is a very big entity, financially. It's not a small business. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1610864438.83570.1272549043508.javamail.r...@md01.wow.synacor.com
Re: Filesystem recommendations
On Wednesday 28 April 2010 20:26:46 Rob Owens wrote: On Mon, Apr 26, 2010 at 08:28:37AM -0500, Stan Hoeppner wrote: Javier Barroso put forth on 4/26/2010 6:56 AM: Why Debian Installer doesn't change its default filesystem to xfs if it is better than ext3 / ext4? I think always is better stick to defaults if it is possible If one disk filesystem was better than all the others in all ways, then Linus would only allow one FS in the kernel tree. As of 2.6.33 there are no less than 7 stable primary disk filesystems offered in the kernel. Your question is a bit simplistic, and not really valid. There is no single perfect filesystem. IMO, for servers anyway, XFS is pretty close. Newbies _should_ always stick to defaults. Experts install with expert mode, and choose exactly what they want/need. I didn't write the Debian installer so I can't tell you why EXT is the default. I can only speculate. Thankfully the installer offers us expert mode so we can do whatever we want. In this regard, I guess the Debian team considers EXT the best choice for non-experts. If I'm right that EXT3 has superior resilience to power loss (see my othe post in this thread) , then that fact alone makes it a good choice for default filesystem. Ext3 basically syncs to disk every 5 seconds or so. Ext4 didn't, but it's possible that has been / will be put back. XFS uses longer gaps between disk syncs by default, but it is tunable. You could always use the sync file system option to avoid the whole issue. If that's no good enough, a simple shell script (while sleep 5; do sync; done) running as root (perhaps started from init) will fill basically the same role. Both XFS and Ext3/4 recover through journal replay, and it is usually enough. Rarely, a manual filesystem check will be required, and xfs_check is usually much faster than fsck.ext3 or even fsck.ext4. -- 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.
Re: Filesystem recommendations
Stephen Powell put forth on 4/29/2010 8:50 AM: I agree with John. Stan must hobnob with an elite crowd. Not really. A computer educated crowd maybe, but by no means elite for most definitions of elite. I don't have a UPS at home either, and I don't know anyone that does. Be the first. Even something like this will get you through browns and sags without a burb from the PC, and will give you 5-20 minutes to do a proper shutdown with an average mini tower in the case of total outages due to the occasional storm or line crew replacing a transformer, etc. Less than $50 at WorstBuy: http://www.bestbuy.com/site/CyberPower+-+425VA+SL-Series+Battery+Back-Up+System/6201585.p?id=1069297060711skuId=6201585 A better choice IMO would be something like this: http://www.bestbuy.com/site/APC+-+900VA+Battery+Back-Up+System/7842588.p?id=1142298456537skuId=7842588 Provides surge protection for PC, dsl modem, coax; long battery runtime for a single home PC. Keeps the cordless phone base working during a storm along with a desk lamp so you're not in total darkness. They're great for the living room home theater system too. Allows you to watch the local weather during a storm when the power is out. I do have one at work, but even there most desktop systems aren't on it. The only reason that my desktop system uses the UPS is that my cubicle is on raised floor inside the computer room and I connected it myself. Most desktop users, even at the office, are not so privileged. And my employer is a very big entity, financially. It's not a small business. In the U.S. most business facilities have more stable power than residential areas. Most offices have transformers inside the building and buried cable to the building, unlike residential which, if not fairly new, has all above ground cabling and multiple houses on one transformer up on a power pole. The latter is a magnet for falling tree limbs due to wind in the summer and ice in the winter. Most offices don't suffer from browns and sags due to having dedicated transformers. Usually when office power goes out it's due to a major component failure at a substation or an overhead line somewhere in between that got clipped by a boom truck or the like. In short, office desktops usually don't need a UPS, especially if user data is stored on network shares on UPS backed servers. If power goes out it just garbles local temp files--unless it's a Windows PC and the registry was held open, as it usually is, even though it's not supposed to be... Anyway, the way I've always looked at the residential side of the UPS debate is to ask myself this question: Is it worth spending $100 to surge and power backup protect my $1000 PC and printer? For me that answer is an emphatic yes. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd9a53c.50...@hardwarefreak.com
Re: Filesystem recommendations
On Thu, Apr 29 at 9:50, Stephen Powell penned: I agree with John. Stan must hobnob with an elite crowd. I don't have a UPS at home either, and I don't know anyone that does. I do have one at work, but even there most desktop systems aren't on it. The only reason that my desktop system uses the UPS is that my cubicle is on raised floor inside the computer room and I connected it myself. Most desktop users, even at the office, are not so privileged. And my employer is a very big entity, financially. It's not a small business. I don't have one on my home workstation - I do on the server, and I keep anything important on it. I've also found that UPSes can fail eventually, and you might not know until the brown-out from which it doesn't protect you. I use ext3 on the server, which has fine erformance for my needs. I use the OS Which Must Not Be Named on my workstation. (I don't have a good reason not to have a UPS on my workstation - basically laziness.) As far as I know, no one at my mid-sized company has a UPS on his or her workstation. The expectation, again, is that important data goes on the fileserver, although for various reasons that expectation is not always correct. We do have the option of requesting backups for particular directories on our workstations, but I think they're nightly at best. I've actually asked about getting a UPS here and there, but given that no one else has one and that we rarely get brownouts, let alone blackouts, I haven't pushed the question. I do see a lot of non-techie people using laptops as their only computer; none of those people run linux or would recognize the term filesystem. Among the techie people I know (in the US, so relatively privileged), very few use a laptop as their primary computer; it's usually a supplement to a beefier desktop machine. But regardless, this is back to one of those eternal tradeoffs - performance vs. data integrity. I see no reason I shouldn't use a UPS *and* a journalling filesystem when the performance of that filesystem is adequate for my needs. -- monique -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100429161607.gg25...@mail.bounceswoosh.org
Re: Filesystem recommendations
On Thu, Apr 29 at 10:26, Stan Hoeppner penned: In the U.S. most business facilities have more stable power than residential areas. Probably true, but I've been living in my house maybe two years longer than I've been in this office, and I've had fewer power problems at home than at work. To be fair, there haven't been many in either case. So as always, YMMV. -- monique -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100429162059.gh25...@mail.bounceswoosh.org
Re: Filesystem recommendations
Rob Owens wrote: The resilience is due to the way the journal is written, if I understand correctly. Maybe somebody on this list who understands it better can confirm or deny. There is a journal_data_writeback option for ext3 which will speed up writes to the filesystem, but reduce its resilience to power loss. With this option enabled, I recall reading that the ext3 benchmarks are pretty similar to XFS. Yep. As always, LWN probably has the best word on it [1]. Short answer: ext3 is outdated, ext4 is current and can still be configured to get the same better data resilience without losing all its benefits. XFS should also be able to do so. Criticising ext4 for data resilience problems and praising XFS is a fallacy, both go in the same direction. Now the debate is around the default configuration of modern filesystems (basically performance vs safety). As YMMVVM (very much), one should probably just ignore the debate, take 30m to learn about the issue, and configure his filesystem properly. Well, opinions. ;-) For stable users using ext3, writeback can theoretically offer better throughput, as it doesn't force data to be be pushed on the platters before the metadata has been committed to the journal. It still keeps the filesystem consistent (the only thing a journal is supposed to do), but the risk of corrupting the data is greater. I, personally, don't seek to minimize that risk, I want it to be zero -- no filesystem can help here, and no filesystem will ever do. That's one reason why I don't like to see ext3 recommended for its data resilience: it gives the user the illusion of safety. Of course, it still makes sense to minimize the risk in certain scenarios where it can't be eliminated; but again, modern filesystems can be configured to do so. -thib [1] http://lwn.net/Articles/322823/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd9d34c.1010...@stammed.net
RE: Filesystem recommendations
From: Boyd Stephen Smith Jr. [mailto:b...@iguanasuicide.net] Sent: Thursday, April 29, 2010 7:20 AM Both XFS and Ext3/4 recover through journal replay, and it is usually enough. Rarely, a manual filesystem check will be required, and xfs_check is usually much faster than fsck.ext3 or even fsck.ext4. They only journal filesystem metadata, not the file data iself. If changes to a file haven't been flushed to disk before the power goes out, you'll end up with a perfectly consistent filesystem (thanks to the journal), but with a file or two (or more) with garbage in it. This is why at the beginning of this thread I recommended a filesystem that uses copy-on-write and preferably checksums your data. However, I don't follow my own advice, probably because I've been using XFS for so long (since 2.4 kernel when you had to download the patches from SGI). I personally haven't had a problem with data loss from power outage as a result of XFS corrupting my files. I believe this is because if a regular file (not a database) is in the process of being written when the power goes out, even if every write is synced to disk, unless whatever was writing to it has finished writing, then the contents of the file are invalid anyway, and no filesystem will protect you from that. For example, if my MythTV backend is recording a TV show and the power goes out in the middle of the recording, I will delete it and let MythTV re-record at a later date. It makes no difference if every byte in that file is correct or not up to the point of the power failure. The window of failure is when the process doing the writing closes the file, and if the power now goes out before everything is synced to disk, then you will have a corrupted file that otherwise wouldn't have been. BTW, regarding UPS's. The number of times my computer was improperly shut down as a result of a power outage is far less than the number of times other problems have caused improper shutdowns: e.g. hardware failures such as a power supply going bad, system overheating, kernel crashes, or other system lockups that require you to hit the reset button. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/007201cae7cd$3af7a2e0$b0e6e8...@net
Re: Filesystem recommendations
Ron Johnson ron.l.john...@cox.net wrote: B. Alexander wrote: Ron Johnsonron.l.john...@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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201004291917.o3tjhsig000...@kzsu.stanford.edu
Re: Filesystem recommendations
On Thursday 29 April 2010 14:17:28 Joe Brenner wrote: Ron Johnson ron.l.john...@cox.net wrote: B. Alexander wrote: Ron Johnsonron.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. 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. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/ signature.asc Description: This is a digitally signed message part.
RE: Filesystem recommendations
From: Ron Johnson [mailto:ron.l.john...@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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/00ac01cae7dc$0242e400$06c8ac...@net
Re: Filesystem recommendations
-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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd9ffb6.4070...@web.de
Re: Filesystem recommendations
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-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bda283d.50...@hardwarefreak.com
Re: Filesystem recommendations
Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote: Joe Brenner wrote: Ron Johnson ron.l.john...@cox.net wrote: B. Alexander wrote: Ron Johnsonron.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. It's my problem to check your assertions? Why isn't it your problem to check my assertions? 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. 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. 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). -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201004300103.o3u13kch005...@kzsu.stanford.edu
Re: Filesystem recommendations
On Mon, Apr 26, 2010 at 01:56:21PM +0200, Javier Barroso wrote: On Mon, Apr 26, 2010 at 11:53 AM, Stan Hoeppner s...@hardwarefreak.com wrote: Mark Allums put forth on 4/26/2010 3:22 AM: On 4/26/2010 2:14 AM, Stan Hoeppner wrote: Mark Allums put forth on 4/25/2010 1:19 AM: Sorry Stan, Your defense of XFS has put me into troll mode. It's a reflex. I don't buy it, but I shouldn't troll. I think you are confusing what is with what should be. A'ight, you forced me to pull out the big gun. Choke on it. The master penguin himself, kernel.org, has run on XFS since 2008. Sorry for the body slam. Is your back ok Mark? ;) Pretty sure I just won this discussion. Err, actually, XFS wins. ;) BTW, the main Debian mirror in the U.S. is actually housed in kernel.org last I checked. Thus, the files on your system were very likely originally served from XFS. The Linux Kernel Archives A bit more than a year ago (as of October 2008) kernel.org, in an ever increasing need to squeeze more performance out of it's machines, made the leap of migrating the primary mirror machines (mirrors.kernel.org) to XFS. We site a number of reasons including fscking 5.5T of disk is long and painful, we were hitting various cache issues, and we were seeking better performance out of our file system. After initial tests looked positive we made the jump, and have been quite happy with the results. With an instant increase in performance and throughput, as well as the worst xfs_check we've ever seen taking 10 minutes, we were quite happy. Subsequently we've moved all primary mirroring file-systems to XFS, including www.kernel.org , and mirrors.kernel.org. With an average constant movement of about 400mbps around the world, and with peaks into the 3.1gbps range serving thousands of users simultaneously it's been a file system that has taken the brunt we can throw at it and held up spectacularly. http://www.xfs.org/index.php/XFS_Companies#The_Linux_Kernel_Archives Hello Stan, Why Debian Installer doesn't change its default filesystem to xfs if it is better than ext3 / ext4? I think always is better stick to defaults if it is possible I've read articles which state that ext3 has superior resilience to sudden power loss. That sentiment has been echoed in this thread, by Stan I think, with statements like (paraphrasing): XFS is good for production servers which have uninterruptible power supplies. The resilience is due to the way the journal is written, if I understand correctly. Maybe somebody on this list who understands it better can confirm or deny. There is a journal_data_writeback option for ext3 which will speed up writes to the filesystem, but reduce its resilience to power loss. With this option enabled, I recall reading that the ext3 benchmarks are pretty similar to XFS. I'm not an expert, so don't take my word for it. Do some research on it yourself, or wait for the real experts to chime in and correct me :) -Rob -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100429012405.ga8...@aurora.owens.net
Re: Filesystem recommendations
On Mon, Apr 26, 2010 at 08:28:37AM -0500, Stan Hoeppner wrote: Javier Barroso put forth on 4/26/2010 6:56 AM: Hello Stan, Why Debian Installer doesn't change its default filesystem to xfs if it is better than ext3 / ext4? I think always is better stick to defaults if it is possible Thanks for your explications ! If one disk filesystem was better than all the others in all ways, then Linus would only allow one FS in the kernel tree. As of 2.6.33 there are no less than 7 stable primary disk filesystems offered in the kernel. Your question is a bit simplistic, and not really valid. There is no single perfect filesystem. IMO, for servers anyway, XFS is pretty close. Newbies _should_ always stick to defaults. Experts install with expert mode, and choose exactly what they want/need. I didn't write the Debian installer so I can't tell you why EXT is the default. I can only speculate. Thankfully the installer offers us expert mode so we can do whatever we want. In this regard, I guess the Debian team considers EXT the best choice for non-experts. If I'm right that EXT3 has superior resilience to power loss (see my othe post in this thread) , then that fact alone makes it a good choice for default filesystem. Many/most users don't run a UPS and sudden unexpected power loss is a real possibility for them. -Rob -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100429012646.gb8...@aurora.owens.net
Re: Filesystem recommendations
Kevin Ross put forth on 4/24/2010 9:46 PM: So if Btrfs were more mature, or if ZFS were included in the kernel, I'd recommend either of those. But as it is, I think JFS is the way to go. Except for the fact that JFS has almost zero development and/or bug fix activity these days. The project appears idle: http://sourceforge.net/mailarchive/forum.php?forum_name=jfs-commit XFS on the other hand enjoys serious, sustained, active development: http://xfs.org/index.php/XFS_Status_Updates XFS has been very mature, stable, and performant for many years, and continues to become even better little by little. I'm on the mailing list and I see dozens of patches submitted _per day_. There's nothing inherently wrong with JFS, but if it's not being maintained/developed why use it? All the principals are IBM employees, and they're doing no work on it. On top of that, they aren't allowing outside developers. The JFS project is pretty much dying on the vine for all practical purposes. The stale code will linger on in the kernel until IBM abandons it or the project allows in developers who really want to work on it. I'm guessing that Linus will boot it from the tree after it lingers without substantial changes for a few years. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd5327c.4080...@hardwarefreak.com
Re: Filesystem recommendations
Mark Allums put forth on 4/25/2010 1:19 AM: (Why? ext3 and 4 are exceptionally well supported by Linux and GNU. XFS will be, too, probably.) Are you kidding? XFS already is all of the things you mention. You apparently need a history lesson. XFS went into production systems starting in 1993 on SGI's Indy workstations. XFS was GPL'd by SGI in 2000, and was in Linux mainline just before EXT3, since mid 2001 in kernel 2.4. It was used almost exclusively on the IA64 Altix machines. It took a while before non SGI customers starting trying out XFS on i386 hardware. EXT3 arrived in mainline in Nov 2001, a few months _after_ XFS. Both have been in the mainline kernel for almost 9 years. You talk as if XFS is somehow new to Linux lol. I'd guess that XFS has been in mainline longer than many subscribers to this list have been using Linux. I'd also guess that XFS seems new to a lot of people because it's never been the default filesystem for any major Linux distro on i386/AMD64. Lack of exposure to something doesn't mean it's new. XFS has had just as much development support in Linux as EXT3/4 have, possibly more in some areas. It predates all Linux filesystems with the exception of the original EXT. XFS has been in production systems since 1993, less than a year after Linus announced his very first Linux code was available for download via ftp, when he was still in college. That's 17 years ago! EXT3 is young, and EXT4 is an infant compared to XFS. XFS is older than EXT2 and older than many Linux users. Did I forget to mention that XFS is pretty old? 17 years old. And that it's fully supported by the kernel community? I'm not sure what you mean by supported by GNU. XFS is compiled by the GNU tool chain just like everything else in Linux is. It's released under the GNU GPL. It's available and fully supported under Debian/GNU Linux. I should know, because that's what I run on my servers, with XFS. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd53d53.9050...@hardwarefreak.com
Re: Filesystem recommendations
On 04/26/2010 02:14 AM, Stan Hoeppner wrote: Mark Allums put forth on 4/25/2010 1:19 AM: (Why? ext3 and 4 are exceptionally well supported by Linux and GNU. XFS will be, too, probably.) Are you kidding? XFS already is all of the things you mention. You apparently need a history lesson. XFS went into production systems starting in 1993 on SGI's Indy workstations. XFS was GPL'd by SGI in 2000, and was in Linux mainline just before EXT3, since mid 2001 in kernel 2.4. It was used almost exclusively on the IA64 Altix machines. It took a while before non SGI customers starting trying out XFS on i386 hardware. [snip] They couldn't have directly take the Irix code and brought it directly to Linux. It just wouldn't work, and Linus wouldn't allow such shimmed code into the mainline. So, while there's an XFS which is 17 years old, the Linux xfs code is only 9-10 years old. -- Dissent is patriotic, remember? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd542d0.2070...@cox.net
Re: Filesystem recommendations
Mike Castle put forth on 4/25/2010 10:29 AM: On Sat, Apr 24, 2010 at 10:53 AM, B. Alexander stor...@gmail.com wrote: Does anyone have suggestions and practical experience with the pros and cons of the various filesystems? Google is switching (has switched by now?) all of it's servers over to ext4. A web search will turn up more details on the subject. But they are mostly lots of big files. If it weren't for the live migration requirement, I read this to say that Google would be using XFS due to its superior performance: In a mailing list post, Google engineer Michael Rubin provided more insight into the decision-making process that led the company to adopt Ext4. The filesystem offered significant performance advantages over Ext2 _and nearly rivaled the high-performance XFS filesystem_ during the company's tests. Ext4 was ultimately chosen over XFS because it would allow Google to do a live in-place upgrade of its existing Ext2 filesystems. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd54389.1030...@hardwarefreak.com
Re: Filesystem recommendations
On 4/26/2010 2:14 AM, Stan Hoeppner wrote: Mark Allums put forth on 4/25/2010 1:19 AM: (Why? ext3 and 4 are exceptionally well supported by Linux and GNU. XFS will be, too, probably.) Are you kidding? XFS already is all of the things you mention. You apparently need a history lesson. No, XFS is not well-supported. Sorry, it's not. If you need rescuing. you are up that famous creek without any means of propulsion. A 40-year veteran would recover. A Freshman would say screw it, and reformat. To ext3. MAA -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd549c2.7000...@allums.com
Re: Filesystem recommendations
On 4/26/2010 2:14 AM, Stan Hoeppner wrote: I'd also guess that XFS seems new to a lot of people because it's never been the default filesystem for any major Linux distro on i386/AMD64. I wonder why. _ Older is not better. MAA -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd54a43.4050...@allums.com
Re: Filesystem recommendations
On 4/26/2010 2:14 AM, Stan Hoeppner wrote: XFS has had just as much development support in Linux as EXT3/4 have, possibly more in some areas. What does this prove? Development does not equal support. MAA -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd54a7f.5010...@allums.com
Re: Filesystem recommendations
On 4/26/2010 2:14 AM, Stan Hoeppner wrote: Did I forget to mention that XFS is pretty old? 17 years old. So what's your point? MAA -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd54ac0.10...@allums.com
Re: Filesystem recommendations
On 4/26/2010 2:14 AM, Stan Hoeppner wrote: Mark Allums put forth on 4/25/2010 1:19 AM: Sorry Stan, Your defense of XFS has put me into troll mode. It's a reflex. I don't buy it, but I shouldn't troll. I think you are confusing what is with what should be. MAA -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd54d42.3030...@allums.com
Re: Filesystem recommendations
Ron Johnson put forth on 4/26/2010 2:37 AM: On 04/26/2010 02:14 AM, Stan Hoeppner wrote: Mark Allums put forth on 4/25/2010 1:19 AM: (Why? ext3 and 4 are exceptionally well supported by Linux and GNU. XFS will be, too, probably.) Are you kidding? XFS already is all of the things you mention. You apparently need a history lesson. XFS went into production systems starting in 1993 on SGI's Indy workstations. XFS was GPL'd by SGI in 2000, and was in Linux mainline just before EXT3, since mid 2001 in kernel 2.4. It was used almost exclusively on the IA64 Altix machines. It took a while before non SGI customers starting trying out XFS on i386 hardware. [snip] They couldn't have directly take the Irix code and brought it directly to Linux. It just wouldn't work, and Linus wouldn't allow such shimmed code into the mainline. So, while there's an XFS which is 17 years old, the Linux xfs code is only 9-10 years old. Absolutely correct. I wasn't trying to imply the same exact code has been around for 17 years. Hell if that was the case I wouldn't be using it. Whilst the initial Linux porting effort was more than a simple recompile, I don't believe it was a herculanean effort. Far more changes to the XFS code have been made since inclusion in mainline than the changes required to get from IRIX to Linux. I actually saw a brief video interview of one of the SGI IRIX devs quite some time ago in which he described the initial Linux port effort to get it running on SGI's big Origin 3000 MIPS machines. They had to do this to start validating how everything would run under Linux because they didn't have the first Itanium Altix systems manufactured yet. IIRC their testbed was a 32 processor Origin 3000 running MIPS R14K processors. This was back before the Linux MIPS port project existed so they were in essence creating the first Linux MIPS port as part of their effort. He clearly stated that developing/maintaining a Linux MIPS port was not in the cards for SGI, that this effort was strictly a validation effort. He said it took about a week to get Linux booting on the Origin system, and another week to get it stable. The first XFS port to Linux was part of this effort. If it took only 2 weeks for the bulk of this effort, I can't imagine they had to modify a ton of XFS code. IRIX was written in C as is Linux, so the changes in XFS were probably fairly minor. I'd venture to guess that the most significant Linux XFS changes were those for the 32bit X86 code base. IRIX and thus XFS were born on 64bit MIPS RISC CPUs. Moving that to a Linux 64bit Itanium environment was probably relatively straight forward. Moving down to a 32bit platform probably required a lot of code changes, as did the initial Linux 64bit ports up to Alpha, HPPA, Itanium, and eventually MIPS64. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd54de6.9060...@hardwarefreak.com
Re: Filesystem recommendations
Mark Allums put forth on 4/26/2010 3:10 AM: On 4/26/2010 2:14 AM, Stan Hoeppner wrote: XFS has had just as much development support in Linux as EXT3/4 have, possibly more in some areas. What does this prove? Development does not equal support. I thought you were talking about developer support, as in XFS devs getting support from other kernel devs and/or support directly from Linus and/or Alan. I've seen posts on the xfs mailing list from both Linus and Alan. XFS is very much a mainline supported filessytem. Don't forget there are a few companies who _require_ XFS to work well on Linux. If you're talking about end user support, the XFS mailing list members, whilst mostly engaged in dev stuff, are very gracious with helping XFS end users who are having problems. As far as getting help with an XFS problem here on debian-user, of course you're possibly SOL. From what I've seen, most of the OPs on debian-user are desktop or mobile users, not server OPs. Of the server OPs on here, most aren't dealing with multi-hundred terabyte filesystems on big FC SAN storage that need the massive throughput and the backup, restore, freeze to snapshot, and other features of XFS. I'd venture to guess that most of the systems using XFS around the world are running SLES just because of the vendor support deals. SLES ships on SGI's machines which use XFS by default. IBM bundles SLES on many of its X86 and Power machines, as well as on zSeries as a VM. There's plenty of hardware vendor and OS vendor support for XFS if you buy one of these machines and use SLES. I freely admit that XFS penetration in the Debian world, or any other non-big-vendor backed Linux, is going to be sparse. The need that would drive XFS adoption just doesn't exist for the hobbyist or average Debian server OP. The other available filesystems mostly meet their needs. XFS does have many features/advantages that could benefit many Debian systems. But, yes, the OP wouldn't likely get help for it here. That said, I can't recall too many emergency cries here for help with any filesystem problem. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd55670.3050...@hardwarefreak.com
Re: Filesystem recommendations
Mark Allums put forth on 4/26/2010 3:22 AM: On 4/26/2010 2:14 AM, Stan Hoeppner wrote: Mark Allums put forth on 4/25/2010 1:19 AM: Sorry Stan, Your defense of XFS has put me into troll mode. It's a reflex. I don't buy it, but I shouldn't troll. I think you are confusing what is with what should be. A'ight, you forced me to pull out the big gun. Choke on it. The master penguin himself, kernel.org, has run on XFS since 2008. Sorry for the body slam. Is your back ok Mark? ;) Pretty sure I just won this discussion. Err, actually, XFS wins. ;) BTW, the main Debian mirror in the U.S. is actually housed in kernel.org last I checked. Thus, the files on your system were very likely originally served from XFS. The Linux Kernel Archives A bit more than a year ago (as of October 2008) kernel.org, in an ever increasing need to squeeze more performance out of it's machines, made the leap of migrating the primary mirror machines (mirrors.kernel.org) to XFS. We site a number of reasons including fscking 5.5T of disk is long and painful, we were hitting various cache issues, and we were seeking better performance out of our file system. After initial tests looked positive we made the jump, and have been quite happy with the results. With an instant increase in performance and throughput, as well as the worst xfs_check we've ever seen taking 10 minutes, we were quite happy. Subsequently we've moved all primary mirroring file-systems to XFS, including www.kernel.org , and mirrors.kernel.org. With an average constant movement of about 400mbps around the world, and with peaks into the 3.1gbps range serving thousands of users simultaneously it's been a file system that has taken the brunt we can throw at it and held up spectacularly. http://www.xfs.org/index.php/XFS_Companies#The_Linux_Kernel_Archives -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd562a7.3050...@hardwarefreak.com
Re: Filesystem recommendations
On 4/26/2010 4:53 AM, Stan Hoeppner wrote: Mark Allums put forth on 4/26/2010 3:22 AM: On 4/26/2010 2:14 AM, Stan Hoeppner wrote: Mark Allums put forth on 4/25/2010 1:19 AM: Sorry Stan, Your defense of XFS has put me into troll mode. It's a reflex. I don't buy it, but I shouldn't troll. I think you are confusing what is with what should be. A'ight, you forced me to pull out the big gun. Choke on it. I was trying to apologize. This is the user list. Of Debian. Not the SA list of IRIX. I am holding my opinion as a *user*. Other people come here, ask questions, I assume they are asking from the POV of a desktop user, unless they say otherwise. Sometimes I miss the introductions, or otherwise miss the point. Then I give bad advice. Hold silly opinions. From the POV of Joe Hobbyist, XFS is not suitable. From the POV of a Server Administrator, it might well be very suitable. YMMV. MAA -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd56f4e.3090...@allums.com
Re: Filesystem recommendations
On Mon, Apr 26, 2010 at 11:53 AM, Stan Hoeppner s...@hardwarefreak.com wrote: Mark Allums put forth on 4/26/2010 3:22 AM: On 4/26/2010 2:14 AM, Stan Hoeppner wrote: Mark Allums put forth on 4/25/2010 1:19 AM: Sorry Stan, Your defense of XFS has put me into troll mode. It's a reflex. I don't buy it, but I shouldn't troll. I think you are confusing what is with what should be. A'ight, you forced me to pull out the big gun. Choke on it. The master penguin himself, kernel.org, has run on XFS since 2008. Sorry for the body slam. Is your back ok Mark? ;) Pretty sure I just won this discussion. Err, actually, XFS wins. ;) BTW, the main Debian mirror in the U.S. is actually housed in kernel.org last I checked. Thus, the files on your system were very likely originally served from XFS. The Linux Kernel Archives A bit more than a year ago (as of October 2008) kernel.org, in an ever increasing need to squeeze more performance out of it's machines, made the leap of migrating the primary mirror machines (mirrors.kernel.org) to XFS. We site a number of reasons including fscking 5.5T of disk is long and painful, we were hitting various cache issues, and we were seeking better performance out of our file system. After initial tests looked positive we made the jump, and have been quite happy with the results. With an instant increase in performance and throughput, as well as the worst xfs_check we've ever seen taking 10 minutes, we were quite happy. Subsequently we've moved all primary mirroring file-systems to XFS, including www.kernel.org , and mirrors.kernel.org. With an average constant movement of about 400mbps around the world, and with peaks into the 3.1gbps range serving thousands of users simultaneously it's been a file system that has taken the brunt we can throw at it and held up spectacularly. http://www.xfs.org/index.php/XFS_Companies#The_Linux_Kernel_Archives Hello Stan, Why Debian Installer doesn't change its default filesystem to xfs if it is better than ext3 / ext4? I think always is better stick to defaults if it is possible Thanks for your explications ! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/r2g81c921f31004260456z3c6f41ddg86e45cdae1257...@mail.gmail.com
Re: Filesystem recommendations
On Mon, 26 Apr 2010 13:56:21 +0200, Javier Barroso wrote: Why Debian Installer doesn't change its default filesystem to xfs if it is better than ext3 / ext4? I think always is better stick to defaults if it is possible XFS (and ReiserFS) were having (still have?) problems with GRUB legacy bootloader so defaulting the filsesystem to any of them could be a bit risky. I mean, not only performance is a key factor to determine a default filesystem :-) Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2010.04.26.13.09...@gmail.com
Re: Filesystem recommendations
Javier Barroso put forth on 4/26/2010 6:56 AM: Hello Stan, Why Debian Installer doesn't change its default filesystem to xfs if it is better than ext3 / ext4? I think always is better stick to defaults if it is possible Thanks for your explications ! If one disk filesystem was better than all the others in all ways, then Linus would only allow one FS in the kernel tree. As of 2.6.33 there are no less than 7 stable primary disk filesystems offered in the kernel. Your question is a bit simplistic, and not really valid. There is no single perfect filesystem. IMO, for servers anyway, XFS is pretty close. Newbies _should_ always stick to defaults. Experts install with expert mode, and choose exactly what they want/need. I didn't write the Debian installer so I can't tell you why EXT is the default. I can only speculate. Thankfully the installer offers us expert mode so we can do whatever we want. In this regard, I guess the Debian team considers EXT the best choice for non-experts. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd59505.30...@hardwarefreak.com
Re: Filesystem recommendations
On Saturday 24 April 2010 12:53:25 B. Alexander wrote: I have a question on filesystems. Back in the day, I started using reiser3. It was faster than ext3, and it could be extended without umounting the filesystem (which has since been fixed in ext3), plus, unlike any filesystem I have encountered, it could be reduced in size. I'm also a current reiser3 user. I find the ability to shrink the filesystem to be something I am not willing to do without. I have not read the rest of the thread, but my off-the-cuff recommendation would be to start migration to btrfs. Now that the on-disk format has stabilized, I am going to start testing it for filesystems other than /usr/local, /var, and /home. Assuming I can keep those running well for 6-12 months, I will migrate /usr/local, /var, and then /home, in that order, with a 1-3 month gap in between migrations. It's an aggressive migration plan, but reiser3 is just barely maintained in the kernel, and btrfs is the only filesystem I have heard of that even advertises all the features I need. I've already encountered an issue related to btrfs in my very isolated deployments. The initramfs created by update-initramfs does not appear to mount it properly. Instead I am given an '(initramfs)' prompt and I have to mount the filesystem manually (a simple two-argument mount command suffices) and continue the boot process. This is fine for my laptop, but servers (and even my desktop) need to be able to boot unattended; I am still investigating the issue, which may just be due to my configuration. -- 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.
Re: Filesystem recommendations
On Monday 26 April 2010 13:22:19 Boyd Stephen Smith Jr. wrote: On Saturday 24 April 2010 12:53:25 B. Alexander wrote: I have a question on filesystems. [M]y off-the-cuff recommendation would be to start migration to btrfs. Btrfs may not be right for you. The on-disk format has stabilized, but it is still very much in development. If it isn't, I recommend moving to ext3 (NOT ext4) as a temporary measure. Once btrfs matures to your comfort level, you can use btrfs_convert to change from ext3 to btrfs in place. The conversion process even creates a snapshot which can use used to roll back to the original ext3 filesystem. -- 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.
Re: Filesystem recommendations
Boyd Stephen Smith Jr. wrote: [snip] I recommend moving to ext3 (NOT ext4) [snip] Here we go again? :-) -thib -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd5e416.7050...@stammed.net
Re: Filesystem recommendations
On Mon, Apr 26, 2010 at 2:22 PM, Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote: I'm also a current reiser3 user. I find the ability to shrink the filesystem to be something I am not willing to do without. You know, I said the same thing, but then as the kernel and GRUB and the like advanced, I noticed that my reiserfs partitions would have to replay the journal every time I rebooted, even after a clean shutdown. I started calculating how many times I shrunk any of my partitions in the last 8 years, and I can only recall twice. And since I have several terabytes around the house, I figure I can migrate data and delete/recreate partitions if I really need to reduce it. I have not read the rest of the thread, but my off-the-cuff recommendation would be to start migration to btrfs. Now that the on-disk format has stabilized, I am going to start testing it for filesystems other than /usr/local, /var, and /home. Assuming I can keep those running well for 6-12 months, I will migrate /usr/local, /var, and then /home, in that order, with a 1-3 month gap in between migrations. I might play with it for some non-critical partitions, or ones that I can mirror on an established filesystem, even if it is only to use in an Archive Island scenario, where I have a LV that I can mount, sync and umount. However, btrfs is not included in the kernel, is it? As I recall, nilfs2 has kernel support, but that was the only one of the new filesystems, at the time when I started looking at this. It's an aggressive migration plan, but reiser3 is just barely maintained in the kernel, and btrfs is the only filesystem I have heard of that even advertises all the features I need. I've already encountered an issue related to btrfs in my very isolated deployments. The initramfs created by update-initramfs does not appear to mount it properly. Instead I am given an '(initramfs)' prompt and I have to mount the filesystem manually (a simple two-argument mount command suffices) and continue the boot process. This is fine for my laptop, but servers (and even my desktop) need to be able to boot unattended; I am still investigating the issue, which may just be due to my configuration. That is enough to give me pause... --b
Re: Filesystem recommendations
On Monday 26 April 2010 16:05:31 B. Alexander wrote: On Mon, Apr 26, 2010 at 2:22 PM, Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote: I'm also a current reiser3 user. I find the ability to shrink the filesystem to be something I am not willing to do without. You know, I said the same thing, but then as the kernel and GRUB and the like advanced, I noticed that my reiserfs partitions would have to replay the journal every time I rebooted, even after a clean shutdown. I started calculating how many times I shrunk any of my partitions in the last 8 years, and I can only recall twice. And since I have several terabytes around the house, I figure I can migrate data and delete/recreate partitions if I really need to reduce it. That doesn't seem right. I have been using reiser3 since 2005, and my system does not require a journal replay if I do a clean shutdown/reboot. A forced reboot through Alt+SysRq+B does trigger a journal replay (as it should). I also have 4+ tebibytes but most of them are allocated to filesystems. I've had to shrink filesystems dozens of times since 2005, during or after a data move. I don't use partitions (much), having been using LVM happily for everything except /boot. I'm hoping to be able to move that onto LVM once I move to GRUB2 and GPT. I have not read the rest of the thread, but my off-the-cuff recommendation would be to start migration to btrfs. Now that the on-disk format has stabilized, I am going to start testing it for filesystems other than /usr/local, /var, and /home. Assuming I can keep those running well for 6-12 months, I will migrate /usr/local, /var, and then /home, in that order, with a 1-3 month gap in between migrations. I might play with it for some non-critical partitions, or ones that I can mirror on an established filesystem, even if it is only to use in an Archive Island scenario, where I have a LV that I can mount, sync and umount. However, btrfs is not included in the kernel, is it? As I recall, nilfs2 has kernel support, but that was the only one of the new filesystems, at the time when I started looking at this. btrfs is included in 2.6.31.12-0.2-default in openSUSE 11.2. It is also included in linux-image-2.6-686 and linux-image-2.6-amd64 for lenny-backports, testing, and sid. I don't normally deal with other architectures/distributions, so it might also be available there. I've already encountered an issue related to btrfs in my very isolated deployments. The initramfs created by update-initramfs does not appear to mount it properly. Instead I am given an '(initramfs)' prompt and I have to mount the filesystem manually (a simple two-argument mount command suffices) and continue the boot process. This is fine for my laptop, but servers (and even my desktop) need to be able to boot unattended; I am still investigating the issue, which may just be due to my configuration. That is enough to give me pause... It doesn't appear to be a file system issue, but rather a problem with the initramfs scripts. It could also be rooted in my configuration. I know that my root= kernel parameter has to differ from the device name in my /etc/fstab in order to get the initramfs to correctly initialize LVM. I don't mind being a first adopter for this in particular; I hope to be able to report good things about btrfs by this time next year. -- 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.
Re: Filesystem recommendations
On Mon, Apr 26, 2010 at 5:34 PM, Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote: On Monday 26 April 2010 16:05:31 B. Alexander wrote: On Mon, Apr 26, 2010 at 2:22 PM, Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote: I'm also a current reiser3 user. I find the ability to shrink the filesystem to be something I am not willing to do without. You know, I said the same thing, but then as the kernel and GRUB and the like advanced, I noticed that my reiserfs partitions would have to replay the journal every time I rebooted, even after a clean shutdown. I started calculating how many times I shrunk any of my partitions in the last 8 years, and I can only recall twice. And since I have several terabytes around the house, I figure I can migrate data and delete/recreate partitions if I really need to reduce it. That doesn't seem right. I have been using reiser3 since 2005, and my system does not require a journal replay if I do a clean shutdown/reboot. A forced reboot through Alt+SysRq+B does trigger a journal replay (as it should). No, this is a result of sync;sync;shutdown -r now. I also have 4+ tebibytes but most of them are allocated to filesystems. I've had to shrink filesystems dozens of times since 2005, during or after a data move. I've had to extend on the fly many more times than I have had to reduce. I don't use partitions (much), having been using LVM happily for everything except /boot. As am I. In fact, I even recreated a several of the reiser partitions on my workstation to see if it was something legacy that may have crept into the works. The next step is to rebuild, but there are a number of dependencies before I do that (I want to build 64-bit now that it seems ready for prime time, but I want to get a higher-end multicore chip, etc etc.) I'm hoping to be able to move that onto LVM once I move to GRUB2 and GPT. You know, /boot on bare drive has never bothered me, especially since I use encrypted filesystems on everything but VMs. On laptops, I had it set up so /boot lived on a thumb drive...So I'm cool with it. I have not read the rest of the thread, but my off-the-cuff recommendation would be to start migration to btrfs. Now that the on-disk format has stabilized, I am going to start testing it for filesystems other than /usr/local, /var, and /home. Assuming I can keep those running well for 6-12 months, I will migrate /usr/local, /var, and then /home, in that order, with a 1-3 month gap in between migrations. I might play with it for some non-critical partitions, or ones that I can mirror on an established filesystem, even if it is only to use in an Archive Island scenario, where I have a LV that I can mount, sync and umount. However, btrfs is not included in the kernel, is it? As I recall, nilfs2 has kernel support, but that was the only one of the new filesystems, at the time when I started looking at this. btrfs is included in 2.6.31.12-0.2-default in openSUSE 11.2. It is also included in linux-image-2.6-686 and linux-image-2.6-amd64 for lenny-backports, testing, and sid. I don't normally deal with other architectures/distributions, so it might also be available there. It's not going to live anywhere that I am going to be experimenting on it other than 686 or amd64 (e.g. my firewall (SPARC), my N810 (ARM) or my WAP (MIPS)). I've already encountered an issue related to btrfs in my very isolated deployments. The initramfs created by update-initramfs does not appear to mount it properly. Instead I am given an '(initramfs)' prompt and I have to mount the filesystem manually (a simple two-argument mount command suffices) and continue the boot process. This is fine for my laptop, but servers (and even my desktop) need to be able to boot unattended; I am still investigating the issue, which may just be due to my configuration. That is enough to give me pause... It doesn't appear to be a file system issue, but rather a problem with the initramfs scripts. It could also be rooted in my configuration. I know that my root= kernel parameter has to differ from the device name in my /etc/fstab in order to get the initramfs to correctly initialize LVM. I don't mind being a first adopter for this in particular; I hope to be able to report good things about btrfs by this time next year. -- Boyd Stephen Smith Jr. ,= ,-_-. =. b...@iguanasuicide.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.net/\_/
Re: Filesystem recommendations
On Monday 26 April 2010 16:48:09 B. Alexander wrote: On Mon, Apr 26, 2010 at 5:34 PM, Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote: On Monday 26 April 2010 16:05:31 B. Alexander wrote: On Mon, Apr 26, 2010 at 2:22 PM, Boyd Stephen Smith Jr. b...@iguanasuicide.net wrote: I'm also a current reiser3 user. I find the ability to shrink the filesystem to be something I am not willing to do without. You know, I said the same thing, but then as the kernel and GRUB and the like advanced, I noticed that my reiserfs partitions would have to replay the journal every time I rebooted, even after a clean shutdown. That doesn't seem right. I have been using reiser3 since 2005, and my system does not require a journal replay if I do a clean shutdown/reboot. A forced reboot through Alt+SysRq+B does trigger a journal replay (as it should). No, this is a result of sync;sync;shutdown -r now. Well, WFM. Do you have a log of the shutdown messages that appear on the console? They might tell us why your filesystem is not getting cleanly re-mounted read-only. I also have 4+ tebibytes but most of them are allocated to filesystems. I've had to shrink filesystems dozens of times since 2005, during or after a data move. I've had to extend on the fly many more times than I have had to reduce. Yes. Many, many more times. A filesystem that can't grow is beyond useless for me. Luckily btrfs support growing and shrinking and it can do both while mounted. On-line shrinking is a trick I couldn't get reiser3 to perform. I'm hoping to be able to move that onto LVM once I move to GRUB2 and GPT. You know, /boot on bare drive has never bothered me, especially since I use encrypted filesystems on everything but VMs. On laptops, I had it set up so /boot lived on a thumb drive...So I'm cool with it. Well, I will still have to have a partition for GRUB to embed stage 1.5 if I go with GPT. However, it won't contain files per se. I like having as much as possible on LVM because it makes it easier to migrate to new storage media and retire the old media. -- 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.
Re: Filesystem recommendations
On 04/24/2010 12:53 PM, B. Alexander wrote: Hi, So now, I would like to slowly start replacing my reiser3 partitions with...something else. There are two options, the old standards, e.g. ext3/4, xfs, etc, and then there are a slew of new filesystems, such as nilfs2, btrfs and exofs. You probably want ext3 now, and ext4 soon. Midterm, you will want ext4 and XFS. Longer term, btrfs will be the wasp's nipples, if it pans out. (Linus uses it now, allegededly.) I wanted to like ZFS, but Sun is now Oracle, and thus over it hangs a dark cloud. Besides, we can almost get the benefits of ZFS with Linux RAID plus LVM2. MAA (Why? ext3 and 4 are exceptionally well supported by Linux and GNU. XFS will be, too, probably.) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd3deef.7050...@allums.com
ZFS in Linux (was Re: Filesystem recommendations)
On 04/25/2010 01:19 AM, Mark Allums wrote: I wanted to like ZFS, but Sun is now Oracle, and thus over it hangs a dark cloud. Besides, we can almost get the benefits of ZFS with Linux RAID plus LVM2. Even were Sun not owned by Oracle, the likelihood of ZFS in Linux is zero. http://kerneltrap.org/node/8066 Sure there might be (is?) a FUSE implementation, but it'll be woefully slower than an in-kernel implementation. -- Dissent is patriotic, remember? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd43317.8000...@cox.net
Re: ZFS in Linux (was Re: Filesystem recommendations)
On 4/25/2010 7:18 AM, Ron Johnson wrote: On 04/25/2010 01:19 AM, Mark Allums wrote: I wanted to like ZFS, but Sun is now Oracle, and thus over it hangs a dark cloud. Besides, we can almost get the benefits of ZFS with Linux RAID plus LVM2. Even were Sun not owned by Oracle, the likelihood of ZFS in Linux is zero. http://kerneltrap.org/node/8066 Actually, bringing ZFS to Linux is *more* likely under Oracle, since Oracle is not so Linux-paranoid, but I think that for the next year or two, everything Sun is completely up-in-the-air. Sure there might be (is?) a FUSE implementation, but it'll be woefully slower than an in-kernel implementation. FUSE on what I consider reasonable hardware is tolerable, but, yeah, it could be better. MAA -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd44c5d.8050...@allums.com
Re: ZFS in Linux (was Re: Filesystem recommendations)
On 04/25/2010 09:06 AM, Mark Allums wrote: On 4/25/2010 7:18 AM, Ron Johnson wrote: On 04/25/2010 01:19 AM, Mark Allums wrote: I wanted to like ZFS, but Sun is now Oracle, and thus over it hangs a dark cloud. Besides, we can almost get the benefits of ZFS with Linux RAID plus LVM2. Even were Sun not owned by Oracle, the likelihood of ZFS in Linux is zero. http://kerneltrap.org/node/8066 Actually, bringing ZFS to Linux is *more* likely under Oracle, since Oracle is not so Linux-paranoid, but I think that for the next year or two, everything Sun is completely up-in-the-air. With all those patents, the kernel team won't allow it. -- Dissent is patriotic, remember? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd4519b.5010...@cox.net
Re: Filesystem recommendations
On Sat, Apr 24, 2010 at 10:53 AM, B. Alexander stor...@gmail.com wrote: Does anyone have suggestions and practical experience with the pros and cons of the various filesystems? Google is switching (has switched by now?) all of it's servers over to ext4. A web search will turn up more details on the subject. But they are mostly lots of big files. mrc -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/j2v537f90651004250829j1b0cb458y681b1732c2c2d...@mail.gmail.com
Re: ZFS in Linux (was Re: Filesystem recommendations)
On 4/25/2010 9:28 AM, Ron Johnson wrote: On 04/25/2010 09:06 AM, Mark Allums wrote: On 4/25/2010 7:18 AM, Ron Johnson wrote: On 04/25/2010 01:19 AM, Mark Allums wrote: I wanted to like ZFS, but Sun is now Oracle, and thus over it hangs a dark cloud. Besides, we can almost get the benefits of ZFS with Linux RAID plus LVM2. Even were Sun not owned by Oracle, the likelihood of ZFS in Linux is zero. http://kerneltrap.org/node/8066 Actually, bringing ZFS to Linux is *more* likely under Oracle, since Oracle is not so Linux-paranoid, but I think that for the next year or two, everything Sun is completely up-in-the-air. With all those patents, the kernel team won't allow it. Well, yeah. It's not bloody likely. I'm rooting for software patent reform, a movement which may be gaining momentum. But I'm not holding my breath. MAA -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd46995.6010...@allums.com
Re: Filesystem recommendations
On Sat, 24 Apr 2010 19:46:51 -0700 Kevin Ross ke...@familyross.net wrote: ... There's also JFS, which has been around for a number of years, and is mature. It doesn't checksum your files, but it does use copy-on-write (as do Btrfs and ZFS), which goes a long way to keeping your data from getting corrupted, something XFS does not do. FWIW, there is apparently an ext3 COW project, but it seems a bit stagnant: http://www.ext3cow.com/Welcome.html Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100425170739.007f82ee.cele...@gmail.com
Re: Filesystem recommendations
Ron Johnson put forth on 4/24/2010 2:11 PM: On 04/24/2010 12:53 PM, B. Alexander wrote: Does anyone have suggestions and practical experience with the pros and cons of the various filesystems? 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. I've been very happy with XFS for all file sizes and counts, but my server isn't heavy duty by any means. It handles multiple 50-60MB mbox files with ease as well as serving Samaba shares containing 5000+ files per dir. Given that the large mbox files become fairly fragmented over time due to constant appends, having an online file defragmenter, xfs_fsr, is very handy. The myth that certain filesystems don't fragment files and thus don't need a defrag tool are just that, myths. I've run with mbox on both EXT2 and XFS, and the larger mbox files always fragment over time regardless of filesystem. Prior to my last xfs_fsr run, I had 10 mbox files (a single user) that ranged from 10-35 fragments each. Those in the 20-35 fragment range were 40-60MB files. I don't have empirical data to show how much this negatively affected performance, but my mail client did seem a bit snappier after defragging. nilfs2, btrfs and exofs are *definitely* still beta or even alpha. I've not played with any of these myself, but what I'm seeing on the various mailing lists suggests what Ron states here. xfs and ext[34] can all be extended. For production servers with a working UPS, I'd go with ext3 for / /boot and xfs (since it hates sudden power outages) for the /data directories. For production workstations, I'd stick with the standby ext3 for / /boot and ext3 or xfs for /home and /data (depending on the workload). For production servers I'd go with XFS everywhere as long as your kernel (and rescue disk kernel) has XFS built-in. Reliable power (via UPS and/or generator) is part of the definition of production server, so there's no reason to shy away from XFS for any partitions or logical volumes due to power loss fears. Some recent FS benchy comparisons with 2.6.34-rc3 on a big RAID setup: http://btrfs.boxacle.net/repository/raid/2010-04-14_2004/2.6.34-rc3/2.6.34-rc3.html As always, no single fs wins across the board. XFS falls flat on its face in the synthetic mail server test, but does very well in all others. Given its results in the mail test are almost identical to EXT4, and that EXT4 no-barrier increases performance 7 fold, I'd say some tweaking of XFS would bring its performance back in line with the others. -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd51ef5.7040...@hardwarefreak.com
Re: Filesystem recommendations
Ron Johnson put forth on 4/24/2010 5:48 PM: Define hates sudden power outages...Is it recoverable? They got pretty corrupted. Maybe it's been robustified in the intervening years. Drop this in the lore category. Any machine using pretty much any modern filesystem can suffer corruption with a given set of heavy write circumstances and depending on the applications. Some FS do better than others, but all will suffer corruption under the right mix of circumstances. XFS got a bad rap long ago for a couple of fairly high profile corruptions. But, given SGIs customers, nearly all are going to be high profile as all the systems would be huge and storing important data. The bulk of SGI's customers are traditionally U.S. government labs, oil gas exploration companies, movie studios, pharmaceutical labs, NASA, etc. One really bad incident can carry a stigma for a long time, deservedly or not. You may find this an interesting read: http://www.flamingspork.com/talks/2007/06/eat_my_data.odp -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd527ee.2010...@hardwarefreak.com
Re: Filesystem recommendations
On 04/24/2010 12:53 PM, B. Alexander wrote: Hi, I have a question on filesystems. Back in the day, I started using reiser3. It was faster than ext3, and it could be extended without umounting the filesystem (which has since been fixed in ext3), plus, unlike any filesystem I have encountered, it could be reduced in size. Well, now reiser3 is very long in the tooth, reiser4 will probably never go anywhere, so I'm wondering what filesystems are recommended. Last I heard, ext4 is stablizing, but it had problems with filesystem corruption, though that was mid-fall last year, IIRC. So now, I would like to slowly start replacing my reiser3 partitions with...something else. There are two options, the old standards, e.g. ext3/4, xfs, etc, and then there are a slew of new filesystems, such as nilfs2, btrfs and exofs. I'm talking about a range of machines, from workstations to servers to NFS and storage servers with multi-terabyte disks, and a backup server with several hundred gigs of backups. Does anyone have suggestions and practical experience with the pros and cons of the various filesystems? 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. nilfs2, btrfs and exofs are *definitely* still beta or even alpha. xfs and ext[34] can all be extended. For production servers with a working UPS, I'd go with ext3 for / /boot and xfs (since it hates sudden power outages) for the /data directories. For production workstations, I'd stick with the standby ext3 for / /boot and ext3 or xfs for /home and /data (depending on the workload). -- Dissent is patriotic, remember? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd3425f.6080...@cox.net
Re: Filesystem recommendations
On Sat, Apr 24, 2010 at 3:11 PM, Ron Johnson ron.l.john...@cox.net wrote: On 04/24/2010 12:53 PM, B. Alexander wrote: Hi, I have a question on filesystems. Back in the day, I started using reiser3. It was faster than ext3, and it could be extended without umounting the filesystem (which has since been fixed in ext3), plus, unlike any filesystem I have encountered, it could be reduced in size. Well, now reiser3 is very long in the tooth, reiser4 will probably never go anywhere, so I'm wondering what filesystems are recommended. Last I heard, ext4 is stablizing, but it had problems with filesystem corruption, though that was mid-fall last year, IIRC. So now, I would like to slowly start replacing my reiser3 partitions with...something else. There are two options, the old standards, e.g. ext3/4, xfs, etc, and then there are a slew of new filesystems, such as nilfs2, btrfs and exofs. I'm talking about a range of machines, from workstations to servers to NFS and storage servers with multi-terabyte disks, and a backup server with several hundred gigs of backups. Does anyone have suggestions and practical experience with the pros and cons of the various filesystems? 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. nilfs2, btrfs and exofs are *definitely* still beta or even alpha. xfs and ext[34] can all be extended. For production servers with a working UPS, I'd go with ext3 for / /boot and xfs (since it hates sudden power outages) for the /data directories. For production workstations, I'd stick with the standby ext3 for / /boot and ext3 or xfs for /home and /data (depending on the workload). Define hates sudden power outages...Is it recoverable? Thanks for the info, Ron, --b
Re: Filesystem recommendations
On 04/24/2010 05:31 PM, B. Alexander wrote: On Sat, Apr 24, 2010 at 3:11 PM, Ron Johnsonron.l.john...@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. xfs and ext[34] can all be extended. For production servers with a working UPS, I'd go with ext3 for / /boot and xfs (since it hates sudden power outages) for the /data directories. For production workstations, I'd stick with the standby ext3 for / /boot and ext3 or xfs for /home and /data (depending on the workload). Define hates sudden power outages...Is it recoverable? They got pretty corrupted. Maybe it's been robustified in the intervening years. -- Dissent is patriotic, remember? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd37551.3070...@cox.net
Re: Filesystem recommendations
On 4/24/2010 10:53 AM, B. Alexander wrote: Hi, I have a question on filesystems. Back in the day, I started using reiser3. It was faster than ext3, and it could be extended without umounting the filesystem (which has since been fixed in ext3), plus, unlike any filesystem I have encountered, it could be reduced in size. Well, now reiser3 is very long in the tooth, reiser4 will probably never go anywhere, so I'm wondering what filesystems are recommended. Last I heard, ext4 is stablizing, but it had problems with filesystem corruption, though that was mid-fall last year, IIRC. So now, I would like to slowly start replacing my reiser3 partitions with...something else. There are two options, the old standards, e.g. ext3/4, xfs, etc, and then there are a slew of new filesystems, such as nilfs2, btrfs and exofs. I'm talking about a range of machines, from workstations to servers to NFS and storage servers with multi-terabyte disks, and a backup server with several hundred gigs of backups. Does anyone have suggestions and practical experience with the pros and cons of the various filesystems? Thanks, --b If file integrity are important to you, look for a FS that keeps checksums of individual files. Otherwise, if a file becomes corrupted, you'll never know it, unless you keep your own checksums. There are only a small handful of filesystems that keep checksums of your files. Btrfs and ZFS come to mind. I believe ZFS is more mature than Btrfs, but it isn't in the kernel. I believe the only way to get ZFS on Linux is through FUSE. There's also JFS, which has been around for a number of years, and is mature. It doesn't checksum your files, but it does use copy-on-write (as do Btrfs and ZFS), which goes a long way to keeping your data from getting corrupted, something XFS does not do. So if Btrfs were more mature, or if ZFS were included in the kernel, I'd recommend either of those. But as it is, I think JFS is the way to go. -- Kevin -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4bd3ad1b.70...@familyross.net