On 07/07/2015 09:45 PM, Linda Walsh wrote:
Anton Aylward wrote:
Yes I run BtrFS but not on RAID and not for any data or /home.
Back in the 3.11 days I had it corrupt /home. I've never had any problems with it just on / but regular readers will know that I use LVM and have almost everything I can migrated off /.
---- Ditto on that. Cept my raid meltdown was back under the 2.x kernels. Decided to go w/hardware raid or BIOS-raid for 1+0 setups.
I can understand that. My AIX boxes in the racks reach have mirroring of the basic "root" and the 'data warehouse' in the "back room" (wall to wall) is whatever RAID that IBM deems it is. All this is is, as you say, BIOS or hardware and is quite transparent.
I'm sure people here will express doubts about using RAID5 especially with just three spindles. But that's another matter.
??? How many should you have?
My personal OPINION, based on my work with hamming coding in the 1970s and my experience with rebuilding RAID with a series of unfortunately unreliable drives in the 1990s is that I'd settle for 5. I might like more; the mathematics of hamming makes it easier when you start thinking in terms of 32 or even 64 bit wide data. But assembling that to write as 4K blocks is a but, well, excessive. You OPINION may be different. You ECONOMICS may be different. I'm NOT *REPEAT NOT* going to argue this point. It is my OPINION. I will note, however, that for the home user a RAID array of 5 or more 1T or 2T drives (since they come in at around US$50 http://www.tigerdirect.com/applications/SearchTools/item-details.asp?EdpNo=744346&csid=_61[1]) means that you can store more movies that your local video rental store has in stock. [2] Its getting awkward to find a reliable and consistent source of smaller SATA drives. On that point, I should mention, as I have before, some of those old <100G (some even less than 10G!) drives deep in the pile at the Closet of Anxieties are still working. There must be a lesson here about "Designing for a limited lifetime" for economic reasons[4].
My current root (haven't quite gotten up the gumption to xfr root to a RAID-10 based on orange-housing blinking lights -- despite the fact that the controller claims it is fine) has 2 data spindles, 1 parity. But it is running on 15000RPM disks that are 'short stroked' by about 50% to lower seek times. I figured my root would need more spread-out and smaller I/O's.
I've see many, MANY, !MANY! models and supporting mathematics and simulation over the performance of disk "striping", disk and cache turning. Some even take into account the nature of the application base and profile. The old acronym, EMACS - "Eight Megagbyes and Constantly Swapping" - was never that funny. many applications that users consider fundamental, Firefox most notably, so far exceed 8 meg *in code* that its not even remotely funny. But then again, long gone are the days of UNIX on a PDP-11 with one meg of 'core' and roll-in/roll-out. Even when we moved to the VAX and had twice or even four times that memory, and virtual memory support (that you Bill Joy) we still tried to write code that employed 'The Principle of Locality" so as to minimise paging. I don't know that modern compilers, linker, loaders and VM caching makes a better job of it. Yes we can tune the VM/paging/caching system. But is it worth it? Whenever any of the IT people I deal with ask me I tell them to get motherboards that they can load up with all the memory it can take and do so. Corporate budgets are more flexible on that point than home users, but sometimes contractual constraints are an impediment. They may _want_ a Toshiba or an AlienWare so it can be loaded up, but 'policy' says they have to have a (comparatively crippled) Leveno or a Dell, whose upgrade to 32G would cost more than three Toshibas[5]. Yes, I've seen that. The irony is that avoiding corporate procurement beats the economics. http://www.amazon.com/Corsair-Vengeance-Laptop-Memory-CMSX16GX3M2A1600C10/dp...
The only reason I'm running BtrFS at all is that I want to avoid the inode exhaustion problems I encounter with the ext[234] files systems and consider over-provisioning aesthetically displeasing.
xfs doesn't have those problems,
Yes, I've aware of that. Neither does ReiserFs. ZFS looks interesting but seeing what oracle is doing with Java makes me apprehensive about the longer term implications using ZFS. Even more so than the longer term implications for ReiserFS. Then there's NilFS. I can this being useful for the personal workstations or a shared workspace for developers of authors. As far as snapshots go, a pure journalling system beats out the way BtrFS seems to work. And for those of us who expect to work past 2038 its seems a good choice.
but the new CRC-check on the meta data has me very worried -- You can't even change a disks GUID w/o the disk becoming corrupt.
I'll stick with ReiserFS for my rotating rust for the foreseeable future. I plan to move my RootFS off BtrFS and abandon BtrFS. For SSD I can see Nil2 for low latency items such as VM loading of binaries and F2FS for any streaming applications (though its unlikely I'll keep movies & music on SSD) [1] See also http://www.tigerdirect.com/applications/SearchTools/item-details.asp?EdpNo=7739052&csid=_61 for another economic break point. [2] Of course if you live in a major city the library might have an even larger stock but the quality might be lacking[3]. [3] You could, of course, download from YouTube if you have enough bandwidth, and time, to spare. [4] I recall a story about the original Henry Ford finding out that the most common item in scrapyards was the rear axel of wrecked Model T cars. It was so well built! He decided it must have been 'over-engineered' and had it redesigned to be less so, less reliable, less robust. I don't know how true this anecdote is. [5] Such as http://www.laptopmag.com/reviews/laptops/toshiba-qosmio-x875-q7390 although not at that price :-) -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org