[opensuse] ext3 vs reiser vs ... ?
Hi again, all -- The last thing I need to figure out for my happy new system is what FS to use. I've been a big fan of Reiser for a long time (although I haven't kept up with any development news), but ext3 (as ext2 + journal) is a solid standard and drivers and utils are available under Windows (and in fact I have in the past put such things in a tiny DOS-fs slice at the back end of the disk) for "just in case". There are others (no, I'm not considering NTFS :-) out there, too, that I haven't even met. Now that I've met SuSE Studio, though, and shouldn't have to worry about booting from some random live ISO in the event of a system crash, maybe it's time to just pick the best FS for my needs. This will be primarily a large-disk (~4T or, via striping, perhaps ~5T) data storage system for backups, media, and other fun stuff; I don't expect lots of dynamic activity as on a desktop or compiling system but instead figure I'll see large write batches (backups, copies, etcetc) and mostly sequential reads, but we'll have mostly small and medium files and probably not a lot of really big files. The disks themselves will hold content and be fairly static; my SuSE Studio boot image goes on a uSD card in a USB slot and that's where any /tmp or other work will be. I'll probably end up running a small web server as well as samba, but again that shouldn't affect the spinning bits. Any thoughts, shy of religious warfare, on the best FS to use for a data and archive server? [I promise this is it for me for today ;-] TIA again & HAND :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt
"Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2013-10-23 12:59, David T-G wrote:
Any thoughts, shy of religious warfare, on the best FS to use for a data and archive server? [I promise this is it for me for today ;-]
XFS?
10 years ago I researched the same question and chose xfs. I've followed both xfs and ext3/ext4 development since then and would still pick xfs of the 2 (for the described workload). I think Per likes JFS for fileservers, but I don't know much about it. I don't think btrfs is the right choice for a archive server. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wednesday 23 October 2013, Greg Freemyer wrote:
"Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2013-10-23 12:59, David T-G wrote:
Any thoughts, shy of religious warfare, on the best FS to use for a
data
and archive server? [I promise this is it for me for today ;-]
XFS?
10 years ago I researched the same question and chose xfs. I've followed both xfs and ext3/ext4 development since then and would still pick xfs of the 2 (for the described workload).
XFS is _extremely_ slow when creating/deleting files, AFAIR something about factor 100! worse than the ext family. That's why I would not used it for (rsnapshot) backups and most other use cases. Also a few times xfs made me a lot trouble after power failures. So I can't confirm the reputed robustness of XFS. ext4 is not safe to be used as NFS server, at least the dir_index has to disabled. (Maybe this problem was fixed in recent kernels.) I've used reiserfs for everything for years without any problems. But since big kernel lock was removed I've found that it became slower and somehow unstable. BTRFS was still really unstable when I had tested it a few times. That's why I use ext4 currently (for NFS dir_index disabled). But I am not 100% happy with it. Online resizing is slow and I believe it's not as good as offline resizing. Also mkfs is very slow and inefficient when using sparse vm images. Moreover I don't like the inode limit. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2013-10-23 14:52, Ruediger Meier wrote:
Also a few times xfs made me a lot trouble after power failures. So I can't confirm the reputed robustness of XFS.
ext4 is not safe to be used as NFS server, at least the dir_index has to disabled. (Maybe this problem was fixed in recent kernels.)
I had filesystems totally destroyed because power failures and other causes, in xfs, reiserfs, and ext3. All are vulnerable. Ah, I managed to break btrfs too, beyond repair. -- Cheers / Saludos, Carlos E. R. (from 12.3 x86_64 "Dartmouth" at Telcontar)
Carlos E. R. said the following on 10/23/2013 09:05 AM:
I had filesystems totally destroyed because power failures and other causes, in xfs, reiserfs, and ext3. All are vulnerable. Ah, I managed to break btrfs too, beyond repair.
I've broken BtrFS by power outage when ReiserFS has survived. Actually ReiserFS seems better at automatically recovering from systems crashes and power outages, than ext3/4 and BtrFS, but don't take that as an absolute, only a relative. -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/23/2013 06:12 AM, Anton Aylward wrote:
I've broken BtrFS by power outage when ReiserFS has survived. Actually ReiserFS seems better at automatically recovering from systems crashes and power outages, than ext3/4 and BtrFS, but don't take that as an absolute, only a relative.
fwiw... I have yet to lose /anything/ on the reiserfs partitions. I was constantly losing files w/ ext[3|4], even without the power failures, crashes, etc. And after one kernel oops, lost the entire root partition. Gone. jd -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 10/23/2013 10:00 AM, jdebert wrote:
On 10/23/2013 06:12 AM, Anton Aylward wrote:
I've broken BtrFS by power outage when ReiserFS has survived. Actually ReiserFS seems better at automatically recovering from systems crashes and power outages, than ext3/4 and BtrFS, but don't take that as an absolute, only a relative.
fwiw...
I have yet to lose /anything/ on the reiserfs partitions.
I was constantly losing files w/ ext[3|4], even without the power failures, crashes, etc. And after one kernel oops, lost the entire root partition. Gone.
jd
This!. I've used it for my principal server for years. I'm looking at a server rebuild, (simply because its time) and am seriously intending to continue with Reiserfs for the main storage pool, even if I use something newer in the boot drive. -- Explain again the part about rm -rf / -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Oct 23, 2013 at 8:52 AM, Ruediger Meier <sweet_f_a@gmx.de> wrote:
On Wednesday 23 October 2013, Greg Freemyer wrote:
"Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2013-10-23 12:59, David T-G wrote:
Any thoughts, shy of religious warfare, on the best FS to use for a
data
and archive server? [I promise this is it for me for today ;-]
XFS?
10 years ago I researched the same question and chose xfs. I've followed both xfs and ext3/ext4 development since then and would still pick xfs of the 2 (for the described workload).
XFS is _extremely_ slow when creating/deleting files, AFAIR something about factor 100! worse than the ext family. That's why I would not used it for (rsnapshot) backups and most other use cases.
I think you recall from 2003 not 2013! As 18 months ago, the delta was almost gone. At that time Dave Chinner (one of the core XFS developers) was argueing that he only saw a multi-year future in XFS and BtrFS. As such his argument was people should move to XFS if they wanted short term stability because it was going to be around and well supported for years. Then for desktops and small servers, migrate them to BtrFS when it was ready. I'll let you read some of it yourself:
From <http://lwn.net/Articles/476565/> Dave Chinner says:
==
to summarize how I understood you: you recommend using XFS for "big storage" systems, while -- for the time being -- the desktop use-case is still better served by ext4?
No, that's exactly the opposite of what I am saying. My point is that even for desktop use cases, XFS is now so close ext4 performance on single threaded metadata intensive workloads that it ext4 has lost the one historical advantage it held over XFS. The example I use in the talk is untarring a kernel tarball - XFS used to take a minute, ext4 about 3s. That's one of the common "20x slower" workloads that people saw all the time. Now XFS will do that same untar in 4s. And the typical 50x slower workload was then doing a 'rm -rf' on that unpacked kernel tarball. XFS has gone from about a minute down to 3s, compared to 2s for ext4.... While these XFS numbers are still slightly slower from a "benchmark perspective", in practice most people will consider them both to be "instantaneous" because they now both complete faster than the time it takes to type your next command. IOWs, users will notice no practical difference between the performance of the filesystems for common desktop/workstation usage. Let's now fast forward a few months: your desktop and server system filesystems will be BTRFS, whilst XFS is fast enough and scales well enough for everything else that BTRFS can't be used for. I can't see where ext4 fits into this picture because, AFAIC, XFS is now the better choice for just about every workload you wouldn't use BTRFS for.... So I'm not sure ext4 has a future - ext4 was always intended as a stop-gap measure until BTRFS is ready to take over as the default linux filesystem. This milestone is rapidly approaching, so now is a good time to look at the future of the other filesystems that are typically used on systems. Everyone knows what I think now, so I'm very interested in what users and developers think about what I've said and the questions I've posed. The upcoming LSF workshop could be very interesting. :) Dave. ======= -- Greg Freemyer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wednesday 23 October 2013, Greg Freemyer wrote:
On Wed, Oct 23, 2013 at 8:52 AM, Ruediger Meier <sweet_f_a@gmx.de> wrote:
On Wednesday 23 October 2013, Greg Freemyer wrote:
"Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2013-10-23 12:59, David T-G wrote:
Any thoughts, shy of religious warfare, on the best FS to use for a
data
and archive server? [I promise this is it for me for today ;-]
XFS?
10 years ago I researched the same question and chose xfs. I've followed both xfs and ext3/ext4 development since then and would still pick xfs of the 2 (for the described workload).
XFS is _extremely_ slow when creating/deleting files, AFAIR something about factor 100! worse than the ext family. That's why I would not used it for (rsnapshot) backups and most other use cases.
I think you recall from 2003 not 2013!
No, from 2011, kernel 2.6.37. Even I re-validated my results using 3.0.80-52, which is the up-to-date kernel of SLE11. I consider it my own huge mistake that I've started using xfs at all without benchmarking before. It was a lot work to migrate back and there are still some xfs partitions left which are as slow as measured in 2011.
As 18 months ago, the delta was almost gone. At that time Dave Chinner (one of the core XFS developers) was argueing that he only saw a multi-year future in XFS and BtrFS. As such his argument was people should move to XFS if they wanted short term stability because it was going to be around and well supported for years.
It sounds right somehow, but xfs was still 100 times slower probably on all existing distros at this time, just 18 months ago. So I wouldn't have recommended it at that time. And even now it will be too slow on most existing enterprise distros.
Then for desktops and small servers, migrate them to BtrFS when it was ready. I'll let you read some of it yourself:
Planning migration to btrfs in future is even one more argument for ext2/3/4 because btrfs-convert does not work for xfs.
From <http://lwn.net/Articles/476565/> Dave Chinner says:
It's good to know, maybe I will keep my last existing XFS partions and try a recent kernel.
[...] XFS is now so close ext4 performance on single threaded metadata intensive workloads that it ext4 has lost the one historical advantage it held over XFS.
Hm, maybe this performance difference is really gone now. But it was such a huge difference (feels like comparing HD with floppy disk) ... and it was not fixed for many many years ... so at least for me it will take some time before forgetting the bad taste of xfs. cu, Rudi -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Oct 23, 2013 at 11:16 AM, Ruediger Meier <sweet_f_a@gmx.de> wrote:
XFS is _extremely_ slow when creating/deleting files, AFAIR something about factor 100! worse than the ext family. That's why I would not used it for (rsnapshot) backups and most other use cases.
I think you recall from 2003 not 2013!
No, from 2011, kernel 2.6.37. Even I re-validated my results using 3.0.80-52, which is the up-to-date kernel of SLE11.
I consider it my own huge mistake that I've started using xfs at all without benchmarking before. It was a lot work to migrate back and there are still some xfs partitions left which are as slow as measured in 2011.
You might want to read http://lwn.net/Articles/476263/ Per it, the last of major changes to make file creation / deletion went into the 3.3 kernel. Even openSUSE 12.2 uses the 3.4 kernel, so openSUSE has had the improvements in both of the last 2 major releases and of course will have them in 13.1 due out next month. Greg -- Greg Freemyer -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
FWIW, I have never lost any files with reiserfs - however - I have lost files with ext2 and ext3 - and scared to try ext4 Duaine -- Duaine Hechler Piano, Player Piano, Pump Organ - Tuning, Servicing & Rebuilding (314) 838-5587 / dahechler@att.net / www.hechlerpianoandorgan.com Home & Business user of Linux - 13 years -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Duaine Hechler said the following on 10/23/2013 01:18 PM:
FWIW, I have never lost any files with reiserfs - however - I have lost files with ext2 and ext3 - and scared to try ext4
Maybe I've been lucky, but while I've had to run fsck a lot I've never (noticed any) lost files on ReiserFS. When I have set up ext3/4 FS I keep finding files in lost+found at the least. So at the very least, ReiserFS is better at preserving linkages. -- Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity. -- George S. Patton -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Greg Freemyer wrote:
"Carlos E. R." <robin.listas@telefonica.net> wrote:
On 2013-10-23 12:59, David T-G wrote:
Any thoughts, shy of religious warfare, on the best FS to use for a data and archive server? [I promise this is it for me for today ;-]
XFS?
10 years ago I researched the same question and chose xfs. I've followed both xfs and ext3/ext4 development since then and would still pick xfs of the 2 (for the described workload).
I think Per likes JFS for fileservers, but I don't know much about it.
Yes, I have long (towards 10 years) been using only JFS on my systems. (any kind, mail, web, file, desktops, whatever). JFS is mature and actively maintained by the original/key developer. I don't know if performance can keep up with more modern filesystems, it's not of real concern to me. /Per -- Per Jessen, Zürich (13.2°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David T-G said the following on 10/23/2013 06:59 AM:
Any thoughts, shy of religious warfare, on the best FS to use for a data and archive server? [I promise this is it for me for today ;-]
Won't that depend on a) the nature of the archive files If this is simply to be a 'mirror' of the regular file system, a 1:1 file mapping then there is no need for some specific optimizations as there would be if, for example, each snapshot were to be a single large file, a TAR or CPIO image say. You then have to look at what you are archiving: small files, large files .... Archiving mail a mbox is going to be different from archiving as maildir. For example the later is going to consume a LOT of inodes and that affects how one would format a extN file system but not be relevant on a ReiserFS or BtrFS. b) the demand for retrieval from the archive This is actually a can of worms. You might not think so at first but I've seen businesses put out of service because their 'backup' indexing was inadequate when the time came to retrieve a specific archive file of a specific date, as oppose to restore the whole backup. You need to be driven by your business methods here and that in turn will determine your indexing and retrieval which will determine your storage format. Its business drive, not technology driven. Why else would you be archiving? Now while (b) is pretty much an 'absolute', (a) can end up being flexible. You HAVE to have a clear way of retrieval otherwise your archive is just a 'junk room' into which your file system overflows. That (a) can be flexible also means that the optimization curve is not clearly peaked. Why else would you be asking this question? What's the worst situation if you choose ReiserFS rather than extN? The size of the file system? The number of inodes? But if your indexing broken or inadequate you've got a business problem. -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David T-G said the following on 10/23/2013 06:59 AM:
The last thing I need to figure out for my happy new system is what FS to use.
Maybe not. I use LVM.[1] That gives me a flexibility for backups and archiving since I can use its snapshot mechanism. I have a large number (hey, big disks are cheap[1]) of partitions, many of them under or at 5G in size. That means I can image them onto a DVD for off-line backup. That's actually very easy to do with LVM. You can also use the 'snapper' system to archive any changes you make. Some sites use that so they can roll back updates. Because I use LVM I can use different file systems for different bits of the system. My experimental desktop ha one humongous (all of the disk except swap) file system, but I'm not sure that's a good idea. I tried it to see if BtrFS can do a global optimization. It seems it can but is it worth it compared to the data management flexibility I have using LVM? You asked to avoid a religious war. Well LVM lets me avoid a religious war. If I have a partition of maildir files on a ext3FS and run out of inodes then I can create another partition, perhaps put a ReiserFS on it to avoid that problem, perhaps make it a larger ext3FS & format that with a different inode ratio, rsync across, unmount, rename, remount. Problem solved! Oh, and I can then free up the space of the old FS. Or perhaps XFS or perhaps JFS or perhaps BtrFS or ... Not only am I not committed to one FS, I don't have to stay committed. The argument people often make against my strategy is that those 5G partitions aren't reasonable. Well they are. Look at your tree. Its easy to separate out things like /var and /usr/share. Look how much space they take and look how often they get updated. You may even be able to subdivide those but I'm not sure its worth it. Then there's ~/Documents, ~/Downloads. I also have ~/PDFs. Under my ~/Pictures I have a tree of my own photographs that's currently organized by year. Look to your own file tree. There are other advantages with LVM. It make handling RAID easier and you can do some simple RAID-like things such as mirroring and striping entirely within LVM and on a partition by partition basis. For example, I want my data very secure so mirror it, but things /usr/share I can restore from the distribution so don't need to be mirrored. [1] Except on an experimental desktop which has only a old, old, 20G drive on which I run BtrFS. The drive is old and has a few bad sectors and that really gives BtrFS a workout! WHEEEE! [2] A 2G Barracuda is under $100 from TigerDirect.ca -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David T-G said the following on 10/23/2013 06:59 AM:
here are others (no, I'm not considering NTFS:-) out there, too, that I haven't even met.
Just for reference then .. http://en.wikipedia.org/wiki/Category:Linux_file_systems -- How long did the whining go on when KDE2 went on KDE3? The only universal constant is change. If a species can not adapt it goes extinct. That's the law of the universe, adapt or die. -- Billie Walsh, May 18 2013 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Hi again, everyone -- ...and then David T-G said... % % The last thing I need to figure out for my happy new system is what FS to % use. I've been a big fan of Reiser for a long time (although I haven't [snip] Thanks for the many replies. What's most obvious is that I've been out of the loop for a long time :-| Discussion of content is right on, and I get that. I would say that most of the content will be lots of files under 500M and lots under 5M, but there will probably a few score of files in the 5G-50G range. I'll have both filesystem-like copies of entire content both for backups and media storage and archive-ish single files of bundled bunches of stuff. I don't think there will be clear winner there, so in "old think" terms I would probably worry more about running out of inodes for entries than being slow to process long extents. Or at least I think I would :-) From what I can tell, XFS is a big contender, ReiserFS isn't bad, and Carlos can break pretty much everything :-) Barring more "XFS really is still slow" input, I think, at this point, that I'm going to lean toward XFS even though it's new to me, especially if I also give LVM a try and it does my mirroring so that I have the ability to break, reformat, transfer, and sync if I need a change (and, hey, manage volumes on the fly to tune their different purposes, too). Thanks again & HAND :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt
On 10/23/2013 08:24 AM, David T-G wrote:
From what I can tell, XFS is a big contender, ReiserFS isn't bad, and Carlos can break pretty much everything:-) Barring more "XFS really is still slow" input, I think, at this point, that I'm going to lean toward XFS even though it's new to me, especially if I also give LVM a try and it does my mirroring so that I have the ability to break, reformat, transfer, and sync if I need a change (and, hey, manage volumes on the fly to tune their different purposes, too).
<- snip -> Coming in a bit late. I did benchmark XFS, EXT4 and btrfs recently for our application and found that XFS won. We're having to write binary data as quickly as possible to RAID filesystems exceeding 17-TB in size. The file sizes are all 4-GB. The data is coming from two optimized 1-Gig Ethernet (fiber) interfaces, so we don't have to read/write while collecting data. BTW, we're able to get continuous bandwidth of 1,900-Gbits/sec over the two interfaces. I don't have the numbers available now, but XFS was able to write to an 11-disk RAID-6 array that netted about 17-TB of space at a rate of about 1.6-GB/sec. EXT4 was a tiny bit faster, but it had more storage overhead. Btrfs completely failed at about 15-TB. So XFS won (again) for our job mix. Reiserfs wasn't considered here because it doesn't support partitions larger than 16-TB. FWIW, we've been using XFS on this project for seven years and I don't recall ever having a non-hardware related loss of data. We did have filesystem corruption caused by disk failures on JBOD drives without RAID protection, but no unclean shutdown loss of data. Tests were run on openSuSE 12.3 and 13.1-Beta1. (Yes, I did a bug report on the btrfs failure in 12.3 in July of this year, it's still there in 13.1-Beta1.) Regards, Lew -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David T-G said the following on 10/23/2013 11:24 AM:
Discussion of content is right on, and I get that. I would say that most of the content will be lots of files under 500M and lots under 5M, but there will probably a few score of files in the 5G-50G range. I'll have both filesystem-like copies of entire content both for backups and media storage and archive-ish single files of bundled bunches of stuff. I don't think there will be clear winner there, so in "old think" terms I would probably worry more about running out of inodes for entries than being slow to process long extents. Or at least I think I would:-)
From what I can tell, XFS is a big contender, ReiserFS isn't bad, and Carlos can break pretty much everything:-) Barring more "XFS really is still slow" input, I think, at this point, that I'm going to lean toward XFS even though it's new to me, especially if I also give LVM a try and it does my mirroring so that I have the ability to break, reformat, transfer, and sync if I need a change (and, hey, manage volumes on the fly to tune their different purposes, too).
I still read a subtext that your thinking one filesystem to rule them all, and possibly just one partition. Tell me it ain't so, Joe! Right now with LVM and lots of free space for new logical partitions I can quickly create a new one for a XFS for my CD Images and rsync across and compare speeds with another download or burn, and if its not better switch back or rsync the updates back, the free up the logical partition. Most of my server's partitions are ReiserFS 'cos its a joy to watch them come back so quickly and faultlessly after a powerloss :-) Oh, and read up the docs, the man page and the various How-To on LVM. Mirroring is just part of it. Oh, and BtrFS can do mirroring and other RAID-like stuff as well. I think you need to research this all a LOT more than we can explain here. The truth may or may not not be out there, for various values of 'truth', but there are some good examples and illustration that go into a lot of detail. http://www.tldp.org/HOWTO/LVM-HOWTO/recipethreescsistripe.html http://www.tldp.org/HOWTO/LVM-HOWTO/snapshots_backup.html http://www.tldp.org/HOWTO/LVM-HOWTO/removeadisk.html And yes, I've done that! Oh how wonderful! http://www.howtoforge.com/creating-portable-disksafes-with-loopbackfs-and-lv... And using LVM to do the mirroring instead of RAID http://www.joshbryan.com/blog/2008/01/02/lvm2-mirrors-vs-md-raid-1/ The problems such as write barriers, are now fixed. They never were a problem if you stuck to using a file system. I've done this too on a large machine. -- Before all else, we seek, upon our common labor as a nation, the blessings of Almighty God. -- Dwight D. Eisenhower -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton, et al -- ...and then Anton Aylward said... % % David T-G said the following on 10/23/2013 11:24 AM: % > % > From what I can tell, XFS is a big contender, ReiserFS isn't bad, and ... % >it does my mirroring so that I have the ability to break, reformat, % >transfer, and sync if I need a change (and, hey, manage volumes on the % >fly to tune their different purposes, too). % % I still read a subtext that your thinking one filesystem to rule them % all, and possibly just one partition. % % Tell me it ain't so, Joe! It is for now; see my other note for an explanation of why. But I admit that I also don't like the endless management of deciding how much space to allocate for this or that, even if it is easier to adjust with LVM and modern filesystems. Hey, who was it who keeps telling me to not micromanage? ;-) In the end, I think that I look forward to having some large slice(s) for mostly-static archiving and backups as well as some smaller, snapper-ed, COW FS slice(s) for more dynamic content and to managing this under LVM. I think I'm going to get away with having my 500G + 320G (oops; couldn't make the 400G drives work) pairs in there as scratch or other space, so I just might be able to have them available to hold content while I resize and reallocate, which will be helpful, too. % ... % Most of my server's partitions are ReiserFS 'cos its a joy to watch them % come back so quickly and faultlessly after a powerloss :-) Funny you should mention that... I decided last night, when formatting up both new drives, to make one XFS and the other ReiserFS. I then started multiple copies from half a dozen source drives along the lines of for V in XFS RFS do (cd /path/to/drive && tar cpf - .) | (cd /tmp/$V/drive && tar xpf - .) & done and let it chew overnight. After about six hours, I now see that the XFS disk has about 600G on it while the ReiserFS disk has about 1.5T on it. Curious... That's writing, which won't be as fast as reading, and it's interrupted by having multiple streams come in, but the difference is intriguing. % % Oh, and read up the docs, the man page and the various How-To on LVM. ... % The truth may or may not not be out there, for various values of % 'truth', but there are some good examples and illustration that go into % a lot of detail. [snip] Thanks, and I will. Of course, another part of my mental challenge is that if I go digging too deeply I'll get sucked in and then have to find The Right Way, and we all know how fruitless that search is :-| Worse yet, I don't have that kind of time; I want it all, and I want it NOW. Thanks again & HAND :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt
On 23 okt 2013, at 12:59, David T-G wrote:
Hi again, all --
The last thing I need to figure out for my happy new system is what FS to use. I've been a big fan of Reiser for a long time (although I haven't kept up with any development news), but ext3 (as ext2 + journal) is a solid standard and drivers and utils are available under Windows (and in fact I have in the past put such things in a tiny DOS-fs slice at the back end of the disk) for "just in case". There are others (no, I'm not considering NTFS :-) out there, too, that I haven't even met. Now that I've met SuSE Studio, though, and shouldn't have to worry about booting from some random live ISO in the event of a system crash, maybe it's time to just pick the best FS for my needs.
This will be primarily a large-disk (~4T or, via striping, perhaps ~5T) data storage system for backups, media, and other fun stuff; I don't expect lots of dynamic activity as on a desktop or compiling system but instead figure I'll see large write batches (backups, copies, etcetc) and mostly sequential reads, but we'll have mostly small and medium files and probably not a lot of really big files. The disks themselves will hold content and be fairly static; my SuSE Studio boot image goes on a uSD card in a USB slot and that's where any /tmp or other work will be. I'll probably end up running a small web server as well as samba, but again that shouldn't affect the spinning bits.
Any thoughts, shy of religious warfare, on the best FS to use for a data and archive server? [I promise this is it for me for today ;-]
TIA again & HAND
:-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt
Hi David, I'm surprised no one mentioned ZFS yet... http://en.wikipedia.org/wiki/ZFS http://zfsonlinux.org/ and the very recently opened site: http://open-zfs.org/wiki/Main_Page I has a lot of of XFS, Lustre, better RAID than RAID5/6/7, built in compression, iscsi, nfs, etc etc and it's extremely easy (almost boring) to administer. Runs on OSX, Linux, Illumnos/Solaris, FreeBSD... and it loves old disks ;) gr Arno-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
ArnoB wrote:
Hi David,
I'm surprised no one mentioned ZFS yet...
Maybe because it's so brand-spanking new? From the wiki: "OpenZFS was announced in September 2013 as the truly open source successor to the ZFS project." Is there an openSUSE package ready to install? -- Per Jessen, Zürich (13.6°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Per Jessen <per@computer.org> [10-23-13 14:42]:
ArnoB wrote:
Hi David,
I'm surprised no one mentioned ZFS yet...
Maybe because it's so brand-spanking new? From the wiki: "OpenZFS was announced in September 2013 as the truly open source successor to the ZFS project."
Is there an openSUSE package ready to install?
http://software.opensuse.org/package/zfs -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 23 okt 2013, at 20:40, Per Jessen wrote:
ArnoB wrote:
Hi David,
I'm surprised no one mentioned ZFS yet...
Maybe because it's so brand-spanking new? From the wiki: "OpenZFS was announced in September 2013 as the truly open source successor to the ZFS project."
yup that's true, that website is very new ZFS is not though... its development started around 2001 at Sun and is currently a very mature, production proven filesystem prepared for the future. gr arno -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
ArnoB wrote:
I'm surprised no one mentioned ZFS yet...
Runs on OSX, Linux, Illumnos/Solaris, FreeBSD... and it loves old disks ;)
Not to mention LOTS and LOTS of memory! xfs_repair can eat memory, but it's got nothing on ZFS. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 24 okt 2013, at 11:01, Dave Howorth wrote:
ArnoB wrote:
I'm surprised no one mentioned ZFS yet...
Runs on OSX, Linux, Illumnos/Solaris, FreeBSD... and it loves old disks ;)
Not to mention LOTS and LOTS of memory! xfs_repair can eat memory, but it's got nothing on ZFS.
yes it needs a lot of memory with the idea that memory is affordable these days. but you can tweak zfs to use the drives as cache, which might be reasonable on backup servers. disadvantage of xfs: you can't tweak data integrity corruption, which is quite important on backup systems if you'd ask me :) gr arno-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (13)
-
Anton Aylward -
ArnoB -
Carlos E. R. -
Dave Howorth -
David T-G -
Duaine Hechler -
Greg Freemyer -
jdebert -
John Andersen -
Lew Wolfgang -
Patrick Shanahan -
Per Jessen -
Ruediger Meier