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
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
means that you can store more movies that your local video rental store
has in stock. 
Its getting awkward to find a reliable and consistent source of smaller
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.
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
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. Yes,
I've seen that. The irony is that avoiding corporate procurement beats
reason I'm running BtrFS at all is that I want to avoid the
inode exhaustion problems I encounter with the ext 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)
 See also
for another economic break point.
 Of course if you live in a major city the library might have an even
larger stock but the quality might be lacking.
 You could, of course, download from YouTube if you have enough
bandwidth, and time, to spare.
 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.
 Such as
although not at that price :-)
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(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org