On 05/07/2014 04:45 PM, Jerry Feldman wrote:
So, if you had to buy a new 1TB drive and you had a choice between a
high quality consumer SSD and a mechanical drive at the same price,
what would you buy?
Is there competition? Can you get two of the SSDs from different
manufacturers? If so, run
> From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss-
> bounces+blu=nedharvey@blu.org] On Behalf Of Bill Bogstad
>
> And checksums can be incorrectly generated/verified by any hardware at any
> time.
> I claim that 100% data integrity is impossible.
You have some control over th
On May 7, 2014, Jerry Feldman wrote:
>So, if you had to buy a new 1TB drive and you had a choice between a
>high quality consumer SSD and a mechanical drive...
[qualifier about "same price" omitted]
No contest! (At least for my purposes.)
Here's the result of running "du -shx" on a 3TB Western Di
> From: Dan Ritter [mailto:d...@randomstring.org]
>
> 3Ware tw_cli man page:
I believe that hardware data integrity checking must exist, so you are correct
to call me out on the generalization, "hardware raid doesn't do integrity." I
was in fact overstating my belief. But I've never seen any
For a laptop or even primary drive on small desktop, SSD. For bulk data
anywhere, HD.
HD, like tapes used to be, is my 'security blanket'.
On Wed, May 7, 2014 at 3:45 PM, Jerry Feldman wrote:
>
> On 05/07/2014 03:49 PM, Richard Pieri wrote:
> > Jerry Feldman wrote:
> >> Why do they lie about s
Jerry Feldman wrote:
> So, if you had to buy a new 1TB drive and you had a choice between a
> high quality consumer SSD and a mechanical drive at the same price, what
> would you buy?
I'd find a better price on mechanical drives. A 1TB SSD costs about ten
times as much as a 1TB mechanical disk.
R
On 05/07/2014 03:49 PM, Richard Pieri wrote:
> Jerry Feldman wrote:
>> Why do they lie about sync completion.
> To inflate benchmark performance numbers.
>
Ok.
So, if you had to buy a new 1TB drive and you had a choice between a
high quality consumer SSD and a mechanical drive at the same price, w
Jerry Feldman wrote:
> Why do they lie about sync completion.
To inflate benchmark performance numbers.
--
Rich P.
___
Discuss mailing list
Discuss@blu.org
http://lists.blu.org/mailman/listinfo/discuss
On 05/07/2014 12:37 PM, Richard Pieri wrote:
> Bill Bogstad wrote:
>> Power failure vs. forced power off. Is there a difference from the
>> prospective of an SSD?
> Not really. Loss of power is loss of power regardless of the cause.
>
>> Moving this conversation in a slightly different direction
Bill Bogstad wrote:
> ECC is not 100%.
It's not intended to be 100%. It's intended to fault when cosmic ray
strikes causes random bit flips.
> Nor does it protect against transient CPU/memory
> cache errors during
> checksum computation. If you are saying that ZFS can then I will happily read
On Wed, May 7, 2014 at 1:09 PM, Richard Pieri wrote:
> Bill Bogstad wrote:
>> And checksums can be incorrectly generated/verified by any hardware
>> at any time.I claim that 100% data integrity is impossible. I don't
>> think even ZFS can guarantee 100% data integrity with the right set
>> of biza
On Wed, May 7, 2014 at 12:37 PM, Richard Pieri wrote:
> Bill Bogstad wrote:
>> Moving this conversation in a slightly different direction. Does
>> anybody know how to tell a generic SSD to go into a consistent state?
>
> I don't think so, at least not with consumer grade kit. Enterprise grade
> dr
Bill Bogstad wrote:
> And checksums can be incorrectly generated/verified by any hardware
> at any time.I claim that 100% data integrity is impossible. I don't
> think even ZFS can guarantee 100% data integrity with the right set
> of bizarre hardware failures in the CPU/RAM of the computer.
ZFS
On Wed, May 7, 2014 at 12:40 PM, Richard Pieri wrote:
> Dan Ritter wrote:
>> 3Ware tw_cli man page:
>>
>> Verify activity attempts to verify all units based on their unit
>> type. Verifying RAID-1 involves checking that both drives contain the
>
> It doesn't work reliably. If the data is corrupt
Dan Ritter wrote:
> 3Ware tw_cli man page:
>
> Verify activity attempts to verify all units based on their unit
> type. Verifying RAID-1 involves checking that both drives contain the
It doesn't work reliably. If the data is corrupted somewhere in the
controller itself (flakey cache for example
Bill Bogstad wrote:
> Power failure vs. forced power off. Is there a difference from the
> prospective of an SSD?
Not really. Loss of power is loss of power regardless of the cause.
> Moving this conversation in a slightly different direction. Does
> anybody know how to tell a generic SSD to g
On 05/07/2014 09:42 AM, Edward Ned Harvey (blu) wrote:
As IT Manager at Engim, a few years ago, I had a new VP to support. I
gave him a brand new laptop with brand new HDD. He complained that the
backup software slowed down his system, so he disabled it. And then
his HDD suddenly failed. So the
On Wed, May 07, 2014 at 01:56:29PM +, Edward Ned Harvey (blu) wrote:
> Seriously dude?
>
> In software (btrfs and zfs) you should periodically scrub. In fact, this is
> something that would be good on *all* raid sets, it's just not available on
> hardware raid. What a scrub does is this:
On Tue, May 6, 2014 at 2:47 PM, Richard Pieri wrote:
> Bill Bogstad wrote:
>> 1. SSDs are constantly moving data around in order to do wear leveling.
>
> Not constantly. SSD on-board controllers automatically perform garbage
> collection when they're idle. Not when the systems are idle; when the
> From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss-
> bounces+blu=nedharvey@blu.org] On Behalf Of Bill Bogstad
>
> Guessing here
>
> 1. SSDs are constantly moving data around in order to do wear leveling.
Sorry, that's not correct. Wear leveling goes like this:
The OS r
> From: Bill Bogstad [mailto:bogs...@pobox.com]
>
> > Truth is: Hardware mirroring doesn't provide data integrity. But software
> mirroring with btrfs/zfs do indeed provide data integrity.
>
> For purposes of this email:
>
> data loss: you don't get any data
> data integrity: you get data, but
> From: Kent Borg [mailto:kentb...@borg.org]
>
> Go ahead and trust SSDs on par with HDDs. I am going to hold off until I
> see it, let the young industry grow up a lot more.
I have been for years. How many years do you require?
> Things like Linux 3.12 being delayed because of Linus' SSD fail
> From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss-
> bounces+blu=nedharvey@blu.org] On Behalf Of Dan Ritter
>
> For a modern server, swap should be an emergency usage only.
Incorrect.
On a modern (linux) server, the kernel is able to balance stale application
memory just lik
On 05/07/2014 07:15 AM, Jerry Feldman wrote:
Indeed. I have been doing that for years. Disks from a single lot
under a similar usage have a higher likelihood of simultaneous
failure. We had a simultaneous disk failure at the BLU a few years ago.
Ironically, when one buys a disk, one hopes it i
On 05/06/2014 09:31 AM, Kent Borg wrote:
> On 05/06/2014 09:13 AM, Robert Krawitz wrote:
>> Disks themselves have clever proprietary firmware...
>
> Indeed. But, judging from lost data reputations, they appear to be
> careful in what they ship.
>
> Also, when doing RAID 1, I like to pair disks fr
Bill Bogstad wrote:
> 1. SSDs are constantly moving data around in order to do wear leveling.
Not constantly. SSD on-board controllers automatically perform garbage
collection when they're idle. Not when the systems are idle; when the
controllers are idle. Or they can be sent a trim command to in
Bill Bogstad wrote:
> Any hardware that isn't redundant can cause corruption, but proper
> use of redundant hardware (appropriate RAID levels) can protect
> against corruption caused by those devices.
Write holes. Parity corruption. Rebuild errors. Cache inconsistency.
These can and will damage yo
On Tue, May 6, 2014 at 11:29 AM, Mike Small wrote:
> Kent Borg writes:
>> Go ahead and trust SSDs on par with HDDs. I am going to hold off until
>> I see it, let the young industry grow up a lot more.
>
> Is the failure mode for SSDs different? It happened that a newish
> Windows 7 machine I use
Kent Borg writes:
> On 05/05/2014 11:47 AM, Richard Pieri wrote:
>> Any medium can fail with no warning.
>
> Indeed, though disks frequently (usually?) degrade with warning. SMART
> monitoring can note ECC-errors, for example. And other key components
> tend to have "lifetime" reliability, i.e.,
On Tue, May 6, 2014 at 7:29 AM, Edward Ned Harvey (blu)
wrote:
>
>
> Truth is: Hardware mirroring doesn't provide data integrity. But software
> mirroring with btrfs/zfs do indeed provide data integrity.
For purposes of this email:
data loss: you don't get any data
data integrity: you get dat
On Mon, May 5, 2014 at 3:50 PM, Richard Pieri wrote:
>...
> Repeat after me: redundant disks do not provide data integrity.
>
> Redundant disks -- be they rotating platters or flash chips -- will keep
> the system running if one fails but they won't protect your data from
> corruption or loss.
Th
On Sat, May 3, 2014 at 2:37 PM, Richard Pieri wrote:
> Bill Bogstad wrote:
>> And why does it matter that flash chips are slow? The question is whether
>> SATA connected SSDs are slow. The first 500Gbyte SSD that I looked at
>
> What do you think SATA connected SSDs are? They're banks of flash
Edward Ned Harvey (blu) wrote:
> Truth is: Hardware mirroring doesn't provide data integrity. But
Hardware mirroring = redundant disks, and you just said that I was
incorrect that "redundant disks do not provide data integrity."
No, the fact is that redundant disks DON'T protect your data. Writ
Kent Borg writes:
> Go ahead and trust SSDs on par with HDDs. I am going to hold off until
> I see it, let the young industry grow up a lot more.
Is the failure mode for SSDs different? It happened that a newish
Windows 7 machine I use at work ran out of memory and crashed without
syncing to disk
On Tue, May 06, 2014 at 09:07:36AM -0400, Kent Borg wrote:
>
> Go ahead and put swap on SSD if you like. I hear the SSD firmware
> and the redundant chips will save you from chip failures. You should
> be okay...
For a modern server, swap should be an emergency usage only.
0-200 MB of usage and n
On 05/06/2014 09:13 AM, Robert Krawitz wrote:
Disks themselves have clever proprietary firmware...
Indeed. But, judging from lost data reputations, they appear to be
careful in what they ship.
Also, when doing RAID 1, I like to pair disks from different
manufacturers. Different models and m
On Tue, 06 May 2014 09:07:36 -0400, Kent Borg wrote:
> Yes, I understand that, though individual flash cells that have low
> cycle count lives, they can be extended by clever firmware. Clever
> proprietary firmware, that might have bugs. Until SSDs can overcome
> their early reputation of having bu
On 05/06/2014 07:22 AM, Edward Ned Harvey (blu) wrote:
From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss-
bounces+blu=nedharvey@blu.org] On Behalf Of Kent Borg
I don't trust flash, so I am being cautious, but...
Everything you said is equally true of rust.
HDD's can also die
> From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss-
> bounces+blu=nedharvey@blu.org] On Behalf Of Kent Borg
>
> On 05/05/2014 03:50 PM, Richard Pieri wrote:
> > Repeat after me: redundant disks do not provide data integrity.
>
> No, you are not my kindergarten teacher.
Correct
> From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss-
> bounces+blu=nedharvey@blu.org] On Behalf Of Kent Borg
>
> Indeed, though disks frequently (usually?) degrade with warning. SMART
> monitoring can note ECC-errors, for example.
Flash failure is much more easily and much more
> From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss-
> bounces+blu=nedharvey@blu.org] On Behalf Of MBR
>
> While it's true that any medium can fail with no warning, if your data's
> on a spinning magnetic platter, the most likely modes of failure do not
> destroy all the data on
> From: discuss-bounces+blu=nedharvey@blu.org [mailto:discuss-
> bounces+blu=nedharvey@blu.org] On Behalf Of Kent Borg
>
> I don't trust flash, so I am being cautious, but...
Everything you said is equally true of rust.
HDD's can also die with no warning and no recourse. The question
Kent Borg wrote:
> Scenario 1: Horrible noise comes from one disk and it quits working.
> Desire: Go back in time to just before the horrible noise.
> Solution: RAID works great, in fact you are already forward of point and
> still running. (Order a new disk.)
Please explain how having one disk th
On 05/05/2014 03:50 PM, Richard Pieri wrote:
Repeat after me: redundant disks do not provide data integrity.
No, you are not my kindergarten teacher.
And "data integrity" isn't as narrow and simple a definition as you pretend.
Redundant disks -- be they rotating platters or flash chips -- wil
I'm actually considering using btrfs when Fedora 21 comes out to replace
my RAID-1 mirroring. If a drive fails catastrophically without warning,
as long as I have my backups or snapshots I can recover.
On 05/05/2014 02:21 PM, Dan Ritter wrote:
> On Mon, May 05, 2014 at 11:28:48AM -0400, Kent Borg
Backup strategy depends on usage. That said, a recent backup of your
data will save a lot of headaches and money. And make sure the backup
runs and your backup device is working.
Case 1: Us, the BLU. we had a backup strategy, but it failed because we
made changes to access of the server and we neve
Jack Coats wrote:
> That is the difference between 'oh damn' backup protection (missing or
> corrupt file or two)
> and 'oh sh%*' full restore protection.
That's why I prefer and recommend a combination of online or nearline
storage for primary backup purposes and nearline or offline storage for
l
That is the difference between 'oh damn' backup protection (missing or
corrupt file or two)
and 'oh sh%*' full restore protection.
Fastest full restores are from system images in my experience, second is
from 'build a new system'
then restore the data' scenario's.
Just a few missing or corrupt fi
Kent Borg wrote:
> The term "backup" tends to refer to having historical copies of data,
> usually with a notable delay in how long it takes to restore the data.
Not necessarily. Depends on the medium used.
> I would suggest that with flash, hardware redundancy (external to
> whatever proprietary
On 05/05/2014 11:47 AM, Richard Pieri wrote:
Any medium can fail with no warning.
Indeed, though disks frequently (usually?) degrade with warning. SMART
monitoring can note ECC-errors, for example. And other key components
tend to have "lifetime" reliability, i.e., CPUs and RAM and motherboar
MBR wrote:
> While it's true that any medium can fail with no warning, if your data's
> on a spinning magnetic platter, the most likely modes of failure do not
> destroy all the data on the platter.
Head crash. Opening up a crashed drive is quite the mess.
Reading data from "dead" flash chips is
On 5/5/14 11:47 AM, Richard Pieri wrote:
Kent Borg wrote:
- Flash can die with no warning and no recourse.
Any medium can fail with no warning. Good backups have always been the
go-to recourse for these occurrences.
While it's true that any medium can fail with no warning, if your data's
on
On Mon, May 05, 2014 at 11:28:48AM -0400, Kent Borg wrote:
> Worries:
>
> - Flash can die with no warning and no recourse. I will be making a
> copy of the flash and keeping it on another medium. Maybe this board
> can boot from the SD slot it has? Maybe I just use a slow USB stick.
Make a backu
Kent Borg wrote:
> - Flash can die with no warning and no recourse.
Any medium can fail with no warning. Good backups have always been the
go-to recourse for these occurrences.
> - Flash hates writes.
Yep. Like I described earlier in the thread.
> extra is sitting mostly blank. I think wear-l
I don't trust flash, so I am being cautious, but...
I am in the process of replacing my old (and I mean old) basement server
with a new one. I have the base box mostly set up and am moving on to
the mail VM.
Anyway, I bought a little mSATA 60GB card, and so far I am glad I did:
- I can boot
Bill Bogstad wrote:
> And why does it matter that flash chips are slow? The question is whether
> SATA connected SSDs are slow. The first 500Gbyte SSD that I looked at
What do you think SATA connected SSDs are? They're banks of flash chips
with a RAID controller and some DRAM cache. Just as RAI
On Sat, May 3, 2014 at 11:49 AM, Richard Pieri wrote:
> Jerry Feldman wrote:
>> I have seen some competing posts on other forums
>> SSD drives are certainly lighter and faster than mechanical hard drives.
>
> Lighter, yes. Faster, not necessarily. Flash chips are faster for random
> reads, certain
Jerry Feldman wrote:
> I have seen some competing posts on other forums
> SSD drives are certainly lighter and faster than mechanical hard drives.
Lighter, yes. Faster, not necessarily. Flash chips are faster for random
reads, certainly, but they're slower for sustained writes. You need a
lot of "
from my old days of doing performance analysis of round brown and spinning
devices,
performance from lack of seek, rotational delay, and head positioning time
(track to track)
should take quite a bite out of the delays associated with them.
The only delays I could think of should be buss access an
I have seen some competing posts on other forums
SSD drives are certainly lighter and faster than mechanical hard drives.
The comment on Windows Boston that has no figures to back up his claim
is that the SSD drives actually are less power efficient than mechanical
hard drives because of their addi
60 matches
Mail list logo
