Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.mac.system > #97364 > unrolled thread
| Started by | JF Mezei <jfmezei.spamnot@vaxination.ca> |
|---|---|
| First post | 2016-11-27 14:55 -0500 |
| Last post | 2016-11-29 18:10 -0800 |
| Articles | 19 on this page of 79 — 12 participants |
Back to article view | Back to comp.sys.mac.system
How does OS-X behave with a dead SSD ? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-11-27 14:55 -0500
Re: How does OS-X behave with a dead SSD ? Jolly Roger <jollyroger@pobox.com> - 2016-11-27 20:07 +0000
Re: How does OS-X behave with a dead SSD ? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-11-27 20:18 -0500
Re: How does OS-X behave with a dead SSD ? nospam <nospam@nospam.invalid> - 2016-11-27 20:32 -0500
Re: How does OS-X behave with a dead SSD ? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-11-27 20:54 -0500
Re: How does OS-X behave with a dead SSD ? nospam <nospam@nospam.invalid> - 2016-11-27 20:56 -0500
Re: How does OS-X behave with a dead SSD ? Jolly Roger <jollyroger@pobox.com> - 2016-11-28 02:09 +0000
Re: How does OS-X behave with a dead SSD ? Jolly Roger <jollyroger@pobox.com> - 2016-11-28 02:05 +0000
Re: How does OS-X behave with a dead SSD ? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-11-27 23:36 -0500
Re: How does OS-X behave with a dead SSD ? nospam <nospam@nospam.invalid> - 2016-11-28 07:31 -0500
Re: How does OS-X behave with a dead SSD ? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-11-28 13:41 -0500
Re: How does OS-X behave with a dead SSD ? nospam <nospam@nospam.invalid> - 2016-11-28 14:32 -0500
Re: How does OS-X behave with a dead SSD ? android <here@there.was> - 2016-11-28 21:05 +0100
Re: How does OS-X behave with a dead SSD ? Jolly Roger <jollyroger@pobox.com> - 2016-11-28 20:39 +0000
Re: How does OS-X behave with a dead SSD ? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-11-28 18:52 -0500
Re: How does OS-X behave with a dead SSD ? Jolly Roger <jollyroger@pobox.com> - 2016-11-28 23:56 +0000
Re: How does OS-X behave with a dead SSD ? Alan Browne <alan.browne@freelunchvideotron.ca> - 2016-11-28 19:06 -0500
Re: How does OS-X behave with a dead SSD ? joe <none@domain.invalid> - 2016-11-28 19:53 -0600
Re: How does OS-X behave with a dead SSD ? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-11-28 18:30 -0500
Re: How does OS-X behave with a dead SSD ? Jolly Roger <jollyroger@pobox.com> - 2016-11-28 20:38 +0000
Re: How does OS-X behave with a dead SSD ? Jolly Roger <jollyroger@pobox.com> - 2016-11-28 20:37 +0000
Re: How does OS-X behave with a dead SSD ? Jolly Roger <jollyroger@pobox.com> - 2016-11-28 01:47 +0000
Re: How does OS-X behave with a dead SSD ? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2016-11-28 06:31 +0000
Re: How does OS-X behave with a dead SSD ? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-11-28 02:07 -0500
Re: How does OS-X behave with a dead SSD ? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2016-11-29 01:40 +0000
Re: How does OS-X behave with a dead SSD ? Jim Gibson <JimSGibson@gmail.com> - 2016-11-29 14:56 -0800
Re: How does OS-X behave with a dead SSD ? nospam <nospam@nospam.invalid> - 2016-11-29 18:28 -0500
Re: How does OS-X behave with a dead SSD ? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2016-11-30 00:52 +0000
Re: How does OS-X behave with a dead SSD ? Jolly Roger <jollyroger@pobox.com> - 2016-11-30 03:20 +0000
Re: How does OS-X behave with a dead SSD ? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-11-30 00:54 -0500
Re: How does OS-X behave with a dead SSD ? Jolly Roger <jollyroger@pobox.com> - 2016-11-30 07:19 +0000
Re: How does OS-X behave with a dead SSD ? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-11-30 16:38 -0500
Re: How does OS-X behave with a dead SSD ? Jolly Roger <jollyroger@pobox.com> - 2016-12-01 00:44 +0000
Re: How does OS-X behave with a dead SSD ? joe <none@domain.invalid> - 2016-11-30 21:11 -0600
Re: How does OS-X behave with a dead SSD ? Jolly Roger <jollyroger@pobox.com> - 2016-12-01 03:34 +0000
Re: How does OS-X behave with a dead SSD ? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2016-12-01 12:55 +0000
Re: How does OS-X behave with a dead SSD ? Alan Browne <alan.browne@freelunchvideotron.ca> - 2016-12-01 16:51 -0500
Re: How does OS-X behave with a dead SSD ? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-12-01 18:46 -0500
Re: How does OS-X behave with a dead SSD ? Alan Browne <alan.browne@freelunchvideotron.ca> - 2016-12-01 19:37 -0500
Re: How does OS-X behave with a dead SSD ? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-12-02 00:46 -0500
Re: How does OS-X behave with a dead SSD ? nospam <nospam@nospam.invalid> - 2016-12-02 01:42 -0500
Re: How does OS-X behave with a dead SSD ? Jim Gibson <JimSGibson@gmail.com> - 2016-12-02 01:04 -0800
Re: How does OS-X behave with a dead SSD ? joe <none@domain.invalid> - 2016-12-02 08:06 -0600
Re: How does OS-X behave with a dead SSD ? Alan Browne <alan.browne@freelunchvideotron.ca> - 2016-12-03 08:50 -0500
Re: How does OS-X behave with a dead SSD ? Jolly Roger <jollyroger@pobox.com> - 2016-12-03 15:07 +0000
Re: How does OS-X behave with a dead SSD ? Jolly Roger <jollyroger@pobox.com> - 2016-12-03 15:16 +0000
Re: How does OS-X behave with a dead SSD ? Alan Browne <alan.browne@freelunchvideotron.ca> - 2016-12-03 10:57 -0500
Re: How does OS-X behave with a dead SSD ? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-12-03 17:06 -0500
Re: How does OS-X behave with a dead SSD ? Alan Browne <alan.browne@freelunchvideotron.ca> - 2016-12-03 17:25 -0500
Re: How does OS-X behave with a dead SSD ? Jolly Roger <jollyroger@pobox.com> - 2016-12-04 00:32 +0000
Re: How does OS-X behave with a dead SSD ? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-12-03 21:19 -0500
Re: How does OS-X behave with a dead SSD ? David Ritz <dritz@mindspring.com> - 2016-12-03 21:39 -0600
Re: How does OS-X behave with a dead SSD ? joe <none@domain.invalid> - 2016-12-03 19:41 -0600
Re: How does OS-X behave with a dead SSD ? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-12-03 21:26 -0500
Re: How does OS-X behave with a dead SSD ? Jolly Roger <jollyroger@pobox.com> - 2016-12-04 05:59 +0000
Re: How does OS-X behave with a dead SSD ? ANTant@zimage.com (Ant) - 2016-12-04 21:48 -0600
Re: How does OS-X behave with a dead SSD ? Jolly Roger <jollyroger@pobox.com> - 2016-12-05 18:01 +0000
Re: How does OS-X behave with a dead SSD ? ANTant@zimage.com (Ant) - 2016-12-05 22:17 -0600
Re: How does OS-X behave with a dead SSD ? Alan Browne <alan.browne@freelunchvideotron.ca> - 2016-12-03 10:51 -0500
Re: How does OS-X behave with a dead SSD ? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2016-12-02 10:28 +0000
Re: How does OS-X behave with a dead SSD ? Alan Browne <alan.browne@freelunchvideotron.ca> - 2016-12-03 08:48 -0500
Re: How does OS-X behave with a dead SSD ? Jolly Roger <jollyroger@pobox.com> - 2016-12-03 15:02 +0000
Re: How does OS-X behave with a dead SSD ? Jolly Roger <jollyroger@pobox.com> - 2016-12-02 17:54 +0000
Re: How does OS-X behave with a dead SSD ? Alan Baker <alangbaker@telus.net> - 2016-12-05 00:08 -0800
Re: How does OS-X behave with a dead SSD ? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2016-12-05 16:10 +0000
Re: How does OS-X behave with a dead SSD ? Alan Baker <alangbaker@telus.net> - 2016-12-05 12:47 -0800
Re: How does OS-X behave with a dead SSD ? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2016-12-05 21:53 +0000
Re: How does OS-X behave with a dead SSD ? joe <none@domain.invalid> - 2016-11-30 07:55 -0600
Re: How does OS-X behave with a dead SSD ? nospam <nospam@nospam.invalid> - 2016-11-30 11:12 -0500
Re: How does OS-X behave with a dead SSD ? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-11-30 16:44 -0500
Re: How does OS-X behave with a dead SSD ? nospam <nospam@nospam.invalid> - 2016-11-30 17:14 -0500
Re: How does OS-X behave with a dead SSD ? Jolly Roger <jollyroger@pobox.com> - 2016-12-01 00:53 +0000
Re: How does OS-X behave with a dead SSD ? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2016-12-01 12:58 +0000
Re: How does OS-X behave with a dead SSD ? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2016-11-30 20:15 +0000
Re: How does OS-X behave with a dead SSD ? billy@MIX.COM - 2016-12-04 05:25 +0000
Re: How does OS-X behave with a dead SSD ? Jolly Roger <jollyroger@pobox.com> - 2016-12-04 06:02 +0000
Re: How does OS-X behave with a dead SSD ? JF Mezei <jfmezei.spamnot@vaxination.ca> - 2016-12-04 02:00 -0500
Re: How does OS-X behave with a dead SSD ? Lewis <g.kreme@gmail.com.dontsendmecopies> - 2016-12-04 18:42 +0000
Re: How does OS-X behave with a dead SSD ? Jim Gibson <JimSGibson@gmail.com> - 2016-11-29 18:10 -0800
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | Alan Browne <alan.browne@freelunchvideotron.ca> |
|---|---|
| Date | 2016-12-03 08:48 -0500 |
| Message-ID | <_oGdnf0EMYmKUN_FnZ2dnUU7-TudnZ2d@giganews.com> |
| In reply to | #97494 |
On 2016-12-02 05:28, Lewis wrote: > In message <cbCdnXlVEtDXBt3FnZ2dnUU7-XPNnZ2d@giganews.com> > Alan Browne <alan.browne@freelunchvideotron.ca> wrote: >> What precisely does OS X do that confirms correct recording of a sector >> (or block) write? Does it read the sector ( or block) back? That is >> the sole way to verify to perfection that there was not a write failure. > > No. The drives do this, as they have done since the days of MFM drives, > and probably before. If the write fails, the drive throws an error to > the OS. That would do it. And so one should expect SSD drives to behave the same. -- She hummed to herself because she was an unrivaled botcher of lyrics. -Nick (Gone Girl), Gillian Flynn.
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2016-12-03 15:02 +0000 |
| Message-ID | <eag54rFg0qsU2@mid.individual.net> |
| In reply to | #97506 |
Alan Browne <alan.browne@freelunchvideotron.ca> wrote: > On 2016-12-02 05:28, Lewis wrote: >> In message <cbCdnXlVEtDXBt3FnZ2dnUU7-XPNnZ2d@giganews.com> >> Alan Browne <alan.browne@freelunchvideotron.ca> wrote: > >>> What precisely does OS X do that confirms correct recording of a sector >>> (or block) write? Does it read the sector ( or block) back? That is >>> the sole way to verify to perfection that there was not a write failure. >> >> No. The drives do this, as they have done since the days of MFM drives, >> and probably before. If the write fails, the drive throws an error to >> the OS. > > That would do it. And so one should expect SSD drives to behave the same. They do. -- E-mail sent to this address may be devoured by my ravenous SPAM filter. I often ignore posts from Google. Use a real news client instead. JR
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2016-12-02 17:54 +0000 |
| Message-ID | <eadqq4FtleiU2@mid.individual.net> |
| In reply to | #97481 |
On 2016-12-01, Alan Browne <alan.browne@freelunchvideotron.ca> wrote: > On 2016-11-30 19:44, Jolly Roger wrote: >> On 2016-11-30, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote: >>> On 2016-11-30 02:19, Jolly Roger wrote: >>>> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote: >>>>> On 2016-11-29 22:20, Jolly Roger wrote: >>>>> >>>>>> Time Machine to back up to two different destinations, whenever the >>>>>> SSD does crap out, replacing it will be a simple matter of replace, >>>>>> then restore. It's completely a non-issue. >>>>> >>>>> You're assuming that you will notice it crapping out. Unlike >>>>> spinning rust discs, an SSD will continue to remain readable after >>>>> writes become a problem. >>>> >>>> Irrelevant; as soon as there is an issue that prevents either reads >>>> *or* writes, the OS will say so. >>>> >>>>> But you may encounter a situation where after saving a document, the >>>>> middle 4 blocks contain invalid data because the SSD was unable to >>>>> write those 4 blocks and nobody noticed. >>>> >>>> Now you're trying to claim macOS doesn't verify data that it writes >>>> to a volume during file saves? That's not just completely false; it's >>>> laughable! >>> >>> Wow. you have little understanding of how an OS works. >> >> Your claim that an SSD write will fail without the OS or the user >> noticing is both false and idiotic. Of *course* the OS will know if a >> write fails - an error will be generated. And of *course* the user will >> be notified of the failure - an error message will be displayed on the >> screen. > > What precisely does OS X do that confirms correct recording of a sector > (or block) write? The storage device returns a success of failure on each write. The OS trusts the storage device to know whether or not the operation was successful. > Does it read the sector ( or block) back? That is > the sole way to verify to perfection that there was not a write failure. The OS trusts that the storage device was correct when it claimed the operation completed successfully. > I can't find anything online showing how OS X detects a disk write > failure. Any deep references? Meh. Not worth my time. -- E-mail sent to this address may be devoured by my ravenous SPAM filter. I often ignore posts from Google. Use a real news client instead. JR
[toc] | [prev] | [next] | [standalone]
| From | Alan Baker <alangbaker@telus.net> |
|---|---|
| Date | 2016-12-05 00:08 -0800 |
| Message-ID | <o237aj$238$1@news.datemas.de> |
| In reply to | #97467 |
On 2016-11-30 1:38 PM, JF Mezei wrote: > On 2016-11-30 02:19, Jolly Roger wrote: > >> Now you're trying to claim macOS doesn't verify data that it writes to a >> volume during file saves? That's not just completely false; it's laughable! > > Wow. you have little understanding of how an OS works. For one thing, > making a read request following a write would get the data from the > disk's RAM buffer since the data was already there. The OS relies on the > disk providing a confirmation of the write, it doesn't do double IOs to > verify, unless you perform a backup and the backup specifically reads > the backup to compare against original after having written it (second > phase, not done after every write). Do you have cites for any of that? I'm guessing... ...not. > >> Because my SSD shows zero signs of malfunction after eight years of >> continuous use doing hefty work - not a single I/O error or failed read or >> write in all that time. > > But you have argued that you never check. So how can you know ? > > The whole reason i asked was whether one can just live and not worry, > kmnwoing the OS will warn if/when somthing turns sour on an SSD, or > whether someone should make regular checks manually once the SSD ages. > > >> Your fear, uncertainty, and doubt are completely >> unwarranted, as usual. > > Wanting to understand how things work is not "fear" or FUD. > >
[toc] | [prev] | [next] | [standalone]
| From | Lewis <g.kreme@gmail.com.dontsendmecopies> |
|---|---|
| Date | 2016-12-05 16:10 +0000 |
| Message-ID | <slrno4b4f1.1mmt.g.kreme@snow.local> |
| In reply to | #97558 |
In message <o237aj$238$1@news.datemas.de> Alan Baker <alangbaker@telus.net> wrote: > On 2016-11-30 1:38 PM, JF Mezei wrote: >> On 2016-11-30 02:19, Jolly Roger wrote: >> >>> Now you're trying to claim macOS doesn't verify data that it writes to a >>> volume during file saves? That's not just completely false; it's laughable! >> >> Wow. you have little understanding of how an OS works. For one thing, >> making a read request following a write would get the data from the >> disk's RAM buffer since the data was already there. The OS relies on the >> disk providing a confirmation of the write, it doesn't do double IOs to >> verify, unless you perform a backup and the backup specifically reads >> the backup to compare against original after having written it (second >> phase, not done after every write). > Do you have cites for any of that? Do you mean cites? > I'm guessing... ...not. He never does. -- A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki
[toc] | [prev] | [next] | [standalone]
| From | Alan Baker <alangbaker@telus.net> |
|---|---|
| Date | 2016-12-05 12:47 -0800 |
| Message-ID | <o24jou$hdg$1@news.datemas.de> |
| In reply to | #97559 |
On 2016-12-05 8:10 AM, Lewis wrote: > In message <o237aj$238$1@news.datemas.de> > Alan Baker <alangbaker@telus.net> wrote: >> On 2016-11-30 1:38 PM, JF Mezei wrote: >>> On 2016-11-30 02:19, Jolly Roger wrote: >>> >>>> Now you're trying to claim macOS doesn't verify data that it writes to a >>>> volume during file saves? That's not just completely false; it's laughable! >>> >>> Wow. you have little understanding of how an OS works. For one thing, >>> making a read request following a write would get the data from the >>> disk's RAM buffer since the data was already there. The OS relies on the >>> disk providing a confirmation of the write, it doesn't do double IOs to >>> verify, unless you perform a backup and the backup specifically reads >>> the backup to compare against original after having written it (second >>> phase, not done after every write). > >> Do you have cites for any of that? > > Do you mean cites? Yes. Because that's what I wrote. :-) > >> I'm guessing... ...not. > > He never does. >
[toc] | [prev] | [next] | [standalone]
| From | Lewis <g.kreme@gmail.com.dontsendmecopies> |
|---|---|
| Date | 2016-12-05 21:53 +0000 |
| Message-ID | <slrno4bohr.1obm.g.kreme@snow.local> |
| In reply to | #97571 |
In message <o24jou$hdg$1@news.datemas.de> Alan Baker <alangbaker@telus.net> wrote: > On 2016-12-05 8:10 AM, Lewis wrote: >> In message <o237aj$238$1@news.datemas.de> >> Alan Baker <alangbaker@telus.net> wrote: >>> On 2016-11-30 1:38 PM, JF Mezei wrote: >>>> On 2016-11-30 02:19, Jolly Roger wrote: >>>> >>>>> Now you're trying to claim macOS doesn't verify data that it writes to a >>>>> volume during file saves? That's not just completely false; it's laughable! >>>> >>>> Wow. you have little understanding of how an OS works. For one thing, >>>> making a read request following a write would get the data from the >>>> disk's RAM buffer since the data was already there. The OS relies on the >>>> disk providing a confirmation of the write, it doesn't do double IOs to >>>> verify, unless you perform a backup and the backup specifically reads >>>> the backup to compare against original after having written it (second >>>> phase, not done after every write). >> >>> Do you have cites for any of that? >> >> Do you mean cites? > Yes. Because that's what I wrote. Well, that's peculiar. Must have been before coffee or something because I sure saw 'sites'. -- 'Are you Death?' IT'S THE SCYTHE, ISN'T IT? PEOPLE ALWAYS NOTICE THE SCYTHE.
[toc] | [prev] | [next] | [standalone]
| From | joe <none@domain.invalid> |
|---|---|
| Date | 2016-11-30 07:55 -0600 |
| Message-ID | <o1mlo2$1i6g$1@gioia.aioe.org> |
| In reply to | #97457 |
JF Mezei wrote: > On 2016-11-29 22:20, Jolly Roger wrote: <snip>> > You're assuming that you will notice it crapping out. Unlike spinning > rust discs, an SSD will continue to remain readable after writes become > a problem. > When writes are a problem, that should become apparent via SMART. > But you may encounter a situation where after saving a document, the > middle 4 blocks contain invalid data because the SSD was unable to write > those 4 blocks and nobody noticed. > The SSD would certainly notice. This would mean there are no free blocks available to put that data, inferring all excess/spare capacity has been consumed. SMART data will indicate there is a problem long before this happens. > So unless you know how an SSD fails when cells cease to be writeable, > and unless you know whether the OS notices it, you cannot state that > you're perfectly safe, Once YOU consider YOUR situation only YOU can determine how safe YOU are. The first thing to consider is the endurance of YOUR drive, then compare that to how much data YOU write in a month. Then you can determine the expected life YOU might see. Then, combined with backups YOU do, YOU can determine how safe YOU are. YOUR expected life can me 10s or 100s of years. At that point, your concerns are truly FUD. > > > This isn't FUD, It is just about understanding how SSDs fail. It is a > different tech from spinning rust drives and behaves very differently > internally using very proprietary and undocumented logic so each SSD may > be failing in different ways. As you admit, each SSD can fail in different ways. So how do you expect anyone to tell you what might happen with whatever SSD you have under your specific conditions. Can you tell us how the version of OS you will be running whenever that SDD happens to fail actually behaves when an SSD fails. That code has probably not been written. (If you expect the SSD to fail in 2025, what OS will you be running and how do you think it will behave.) > > If you don't even know that an SSD will report unwriteable cells in > SMART data, how can you be sure that your current SSD hasn't begun to > degrade and lose cells ? If YOU use the SMART tools designed for YOUR SSD, then YOU should get a valid picture of the drive. There may not be a field that is called "unwriteable cells" but other fields will tell you something. It is up to YOU to understand YOUR SSD and determine what YOUR risks are. We cannot say anything useful without know YOUR details. So for all intent and purpose, your queries are nothing more than an expression of your FUD. Show us the details mentioned above and your calculations of expected lifetime in your situation and we may be able to contribute.
[toc] | [prev] | [next] | [standalone]
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2016-11-30 11:12 -0500 |
| Message-ID | <301120161112572363%nospam@nospam.invalid> |
| In reply to | #97457 |
In article <583e6990$0$51650$c3e8da3$f6268168@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote: > > > Time Machine to back up to two different destinations, whenever the SSD > > does crap out, replacing it will be a simple matter of replace, then > > restore. It's completely a non-issue. > > You're assuming that you will notice it crapping out. Unlike spinning > rust discs, an SSD will continue to remain readable after writes become > a problem. a read-only drive will definitely be noticeable. macos requires being able to write to the boot drive. > But you may encounter a situation where after saving a document, the > middle 4 blocks contain invalid data because the SSD was unable to write > those 4 blocks and nobody noticed. the app will let you know the write failed, at which point you can take action. assuming you weren't alerted before. > So unless you know how an SSD fails when cells cease to be writeable, > and unless you know whether the OS notices it, you cannot state that > you're perfectly safe, nothing is perfectly safe. that's why you need to make backups. > This isn't FUD, It is just about understanding how SSDs fail. It is a > different tech from spinning rust drives and behaves very differently > internally using very proprietary and undocumented logic so each SSD may > be failing in different ways. it's fud. > If you don't even know that an SSD will report unwriteable cells in > SMART data, how can you be sure that your current SSD hasn't begun to > degrade and lose cells ? ssds are way more reliable than hard drives. why aren't you whining for early warnings with hard drives?
[toc] | [prev] | [next] | [standalone]
| From | JF Mezei <jfmezei.spamnot@vaxination.ca> |
|---|---|
| Date | 2016-11-30 16:44 -0500 |
| Message-ID | <583f4824$0$34642$c3e8da3$dbd57e7@news.astraweb.com> |
| In reply to | #97463 |
On 2016-11-30 11:12, nospam wrote: > the app will let you know the write failed, at which point you can take > action. Are you sure ? The SSD having virtualized the "disk block" could simply map the cell as "bad" and complete succesfully the write to another cell and the app wouldn't know. I don't know if SSDs do that or if they report a write error to the OS (which then reports bakc to app). Hence my questions. > ssds are way more reliable than hard drives. Yet, they use a technology with finite lifetime. A spinning rust platter could last 30 years or fail in 2 weeks. And the failure modes for SSD are different. > why aren't you whining for early warnings with hard drives? Because I know how hard drives fail. Yo can often even HEAR them. I am asking about how SSD failures will be seen/noticed since I have no experience with such failures.
[toc] | [prev] | [next] | [standalone]
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2016-11-30 17:14 -0500 |
| Message-ID | <301120161714253730%nospam@nospam.invalid> |
| In reply to | #97468 |
In article <583f4824$0$34642$c3e8da3$dbd57e7@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote: > > > the app will let you know the write failed, at which point you can take > > action. > > Are you sure ? yes. > The SSD having virtualized the "disk block" could simply > map the cell as "bad" and complete succesfully the write to another cell > and the app wouldn't know. in which case no error is generated because the write did not fail. what happens internal to the ssd does not affect apps. hard drives do the same when remapping bad blocks. it all happens automatically. the problem is when there are no more spare blocks (or some other unrecoverable error occurs), at which point the write will fail. > I don't know if SSDs do that or if they report a write error to the OS > (which then reports bakc to app). Hence my questions. hence the answers. > > ssds are way more reliable than hard drives. > > Yet, they use a technology with finite lifetime. everything has a finite lifetime, including hard drives. > A spinning rust platter > could last 30 years or fail in 2 weeks. same for an ssd. on average, an ssd will outlast a hard drive and also outlast the computer in which it's installed. > And the failure modes for SSD > are different. so what? failure modes for punched cards are different than ssd or hard drives. you can drop an ssd and nothing bad happens. good luck if you drop a deck of punched cards. > > why aren't you whining for early warnings with hard drives? > > Because I know how hard drives fail. Yo can often even HEAR them. sometimes you can hear an impending failure. most of the time, not. and that assumes you're near the hard drive to hear it. what if the computer is offsite? > I am asking about how SSD failures will be seen/noticed since I have no > experience with such failures. and people have answered you. no matter what happens, you'll know when it fails, at which point you will probably scream obscenities and then start restoring from a backup.
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2016-12-01 00:53 +0000 |
| Message-ID | <ea9akbFqsreU2@mid.individual.net> |
| In reply to | #97468 |
On 2016-11-30, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote: > On 2016-11-30 11:12, nospam wrote: > >> the app will let you know the write failed, at which point you can >> take action. > > Are you sure ? You've got to be pretty ignorant to actually think a modern operating system *won't* let you know when a read or write fails. > The SSD having virtualized the "disk block" could simply map the cell > as "bad" and complete succesfully the write to another cell and the > app wouldn't know. Now you are confusing read/write *failures* with bad block *mapping* - two completely different things. Spinning hard drives also map out bad blocks on the fly; but you aren't at all "concerned" about them, are you? Because: FUD. > I don't know if SSDs do that or if they report a write error to the OS > (which then reports bakc to app). Hence my questions. And you are rejecting any answer that doesn't agree with your silly narrative. You aren't trying to learn anything. As always, ignorance reigns supreme with you. >> ssds are way more reliable than hard drives. > > Yet, they use a technology with finite lifetime. A spinning rust > platter could last 30 years or fail in 2 weeks. Hard drives have finite lifetimes as well; but you aren't expressing your fear, uncertainty, and doubt about them. > And the failure modes for SSD are different. A read or write operation either succeeds or fails. If it fails, the file system and operating system are notified of the failure, and the user is informed. That's true of SSDs or hard drives. >> why aren't you whining for early warnings with hard drives? > > Because I know how hard drives fail. Yo can often even HEAR them. Often you cannot hear them. What's your point? > I am asking about how SSD failures will be seen/noticed If a read or write operation fails, the user is notified. -- E-mail sent to this address may be devoured by my ravenous SPAM filter. I often ignore posts from Google. Use a real news client instead. JR
[toc] | [prev] | [next] | [standalone]
| From | Lewis <g.kreme@gmail.com.dontsendmecopies> |
|---|---|
| Date | 2016-12-01 12:58 +0000 |
| Message-ID | <slrno407n5.24ko.g.kreme@snow.local> |
| In reply to | #97468 |
In message <583f4824$0$34642$c3e8da3$dbd57e7@news.astraweb.com> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote: > Are you sure ? The SSD having virtualized the "disk block" could simply > map the cell as "bad" and complete succesfully the write to another cell > and the app wouldn't know. If the drive (SSD or platter) maps out a bad block and writes the block elsewhere then the write didn't fail, did it? Hard Drives have worked like this for decades, and this has nothing to do with SSDs versus platters. > I don't know We know. -- There is nothing so stupid that some person somewhere will not, with earnestness, say it.
[toc] | [prev] | [next] | [standalone]
| From | Lewis <g.kreme@gmail.com.dontsendmecopies> |
|---|---|
| Date | 2016-11-30 20:15 +0000 |
| Message-ID | <slrno3ucts.24ko.g.kreme@snow.local> |
| In reply to | #97457 |
In message <583e6990$0$51650$c3e8da3$f6268168@news.astraweb.com> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote: > But you may encounter a situation where after saving a document, the > middle 4 blocks contain invalid data because the SSD was unable to write > those 4 blocks and nobody noticed. No. That's absurd. > So unless you know how an SSD fails when cells cease to be writeable, > and unless you know whether the OS notices it, you cannot state that > you're perfectly safe, Yes I can. Thanks for playing. > This isn't FUD, Of course it is. > It is just about understanding how SSDs fail. Which you do not. -- SOME SHADOWS ARE SO LONG, THEY ARRIVE BEFORE THE LIGHT. --Soul Music
[toc] | [prev] | [next] | [standalone]
| From | billy@MIX.COM |
|---|---|
| Date | 2016-12-04 05:25 +0000 |
| Message-ID | <o209bt$3im$1@reader2.panix.com> |
| In reply to | #97457 |
JF Mezei <jfmezei.spamnot@vaxination.ca> writes:
> You're assuming that you will notice it crapping out. Unlike spinning
> rust discs, an SSD will continue to remain readable after writes become
> a problem.
There is so much bullshit in this thread. I'm not going to read it all,
but here is an example of writes not failing but a read does (an OWC SSD,
although that's relevant only because I have dozens of them and this is
only the second one to have a problem) (pardon my not wrapping the text,
viewing with a 132 column wide screen is suggested) -
disk0s2: I/O error.
0 [Level 3] [Facility com.apple.system.fs] [ErrType IO] [ErrNo 5] [IOType Read] [PBlkNum 73046760] [LBlkNum 176045]
0 [Level 3] [Facility com.apple.system.fs] [DevNode /dev/disk0s2] [MountPt /] [Path /private/var/db/systemstats/snapshots.db]
disk0s2: I/O error.
0 [Level 3] [Facility com.apple.system.fs] [ErrType IO] [ErrNo 5] [IOType Read] [PBlkNum 73046760] [LBlkNum 176045]
0 [Level 3] [Facility com.apple.system.fs] [DevNode /dev/disk0s2] [MountPt /] [Path /private/var/db/systemstats/snapshots.db]
disk0s2: I/O error.
0 [Level 3] [Facility com.apple.system.fs] [ErrType IO] [ErrNo 5] [IOType Read] [PBlkNum 73046760] [LBlkNum 176045]
0 [Level 3] [Facility com.apple.system.fs] [DevNode /dev/disk0s2] [MountPt /] [Path /private/var/db/systemstats/snapshots.db]
I'm now at 15,855 of these errors. The system remains quite usable - I'm
posting this note with it, email is fine, etc. I'm guessing the defect
managemant (bad block replacement) is failing coz the bad block here can't
be read.
> But you may encounter a situation where after saving a document, the
> middle 4 blocks contain invalid data because the SSD was unable to write
> those 4 blocks and nobody noticed.
That'd only be because you ignored the error message thrown into the middle
of your screen.
> This isn't FUD
Sure it is.
Imagining shit that does not exist is... Ummm... F.U.D.
Billy Y..
--
sub #'9+1 ,r0 ; convert ascii byte
add #9.+1 ,r0 ; to an integer
bcc 20$ ; not a number
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2016-12-04 06:02 +0000 |
| Message-ID | <eahprsFrs5vU2@mid.individual.net> |
| In reply to | #97526 |
On 2016-12-04, billy@MIX.COM <billy@MIX.COM> wrote: > JF Mezei <jfmezei.spamnot@vaxination.ca> writes: > >> You're assuming that you will notice it crapping out. Unlike spinning >> rust discs, an SSD will continue to remain readable after writes become >> a problem. > > There is so much bullshit in this thread. I'm not going to read it all, > but here is an example of writes not failing but a read does (an OWC SSD, > although that's relevant only because I have dozens of them and this is > only the second one to have a problem) (pardon my not wrapping the text, > viewing with a 132 column wide screen is suggested) - > > disk0s2: I/O error. > 0 [Level 3] [Facility com.apple.system.fs] [ErrType IO] [ErrNo 5] [IOType Read] [PBlkNum 73046760] [LBlkNum 176045] > 0 [Level 3] [Facility com.apple.system.fs] [DevNode /dev/disk0s2] [MountPt /] [Path /private/var/db/systemstats/snapshots.db] > disk0s2: I/O error. > 0 [Level 3] [Facility com.apple.system.fs] [ErrType IO] [ErrNo 5] [IOType Read] [PBlkNum 73046760] [LBlkNum 176045] > 0 [Level 3] [Facility com.apple.system.fs] [DevNode /dev/disk0s2] [MountPt /] [Path /private/var/db/systemstats/snapshots.db] > disk0s2: I/O error. > 0 [Level 3] [Facility com.apple.system.fs] [ErrType IO] [ErrNo 5] [IOType Read] [PBlkNum 73046760] [LBlkNum 176045] > 0 [Level 3] [Facility com.apple.system.fs] [DevNode /dev/disk0s2] [MountPt /] [Path /private/var/db/systemstats/snapshots.db] > > I'm now at 15,855 of these errors. The system remains quite usable - I'm > posting this note with it, email is fine, etc. I'm guessing the defect > managemant (bad block replacement) is failing coz the bad block here can't > be read. > >> But you may encounter a situation where after saving a document, the >> middle 4 blocks contain invalid data because the SSD was unable to write >> those 4 blocks and nobody noticed. > > That'd only be because you ignored the error message thrown into the middle > of your screen. > >> This isn't FUD > > Sure it is. > > Imagining shit that does not exist is... Ummm... F.U.D. No shit. Anyone who thinks a modern OS *won't* let you know when a read or write fails is an idiot. There's nothing new to see here folks. Move along. -- E-mail sent to this address may be devoured by my ravenous SPAM filter. I often ignore posts from Google. Use a real news client instead. JR
[toc] | [prev] | [next] | [standalone]
| From | JF Mezei <jfmezei.spamnot@vaxination.ca> |
|---|---|
| Date | 2016-12-04 02:00 -0500 |
| Message-ID | <5843bf1e$0$60969$b1db1813$2411a48f@news.astraweb.com> |
| In reply to | #97528 |
On 2016-12-04 01:02, Jolly Roger wrote: > No shit. Anyone who thinks a modern OS *won't* let you know when a read > or write fails is an idiot. There's nothing new to see here folks. Move > along. A disk may find an error and still complete the IO request succesfully. (for instance by rereading the sector multiple times until the read works.) Similarly, it may discover a bad block and revector it during a write operation. The OS will see a success code for the IO. Different operating systems treats the above errors differently. Some ignore it. some process these messages. It all depends on the drivers. VMS for instance had error logging for all its disks until the ATA driver was introduced which didn't have error logging so the above errors would not be logged in VMS. Wanting to understand how disks subsystems works is not FUD. Unfortunatly in this group, Lewis and Roger ensure their spin everything into FUD, preventing intelligent conversation.
[toc] | [prev] | [next] | [standalone]
| From | Lewis <g.kreme@gmail.com.dontsendmecopies> |
|---|---|
| Date | 2016-12-04 18:42 +0000 |
| Message-ID | <slrno48ovg.10tl.g.kreme@snow.local> |
| In reply to | #97529 |
In message <5843bf1e$0$60969$b1db1813$2411a48f@news.astraweb.com> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote: > On 2016-12-04 01:02, Jolly Roger wrote: >> No shit. Anyone who thinks a modern OS *won't* let you know when a read >> or write fails is an idiot. There's nothing new to see here folks. Move >> along. > A disk may find an error and still complete the IO request succesfully. Because it was ... wait for it.. SUCCESSFUL. > (for instance by rereading the sector multiple times until the read > works.) Similarly, it may discover a bad block and revector it during a > write operation. The OS will see a success code for the IO. Because it was ... wait for it.. SUCCESSFUL. > VMS for instance There may be a VMS group to post to, but this is not it. > Wanting to understand how disks subsystems works is not FUD. The way you do it, it is. And this is not the group for it anyway. > Unfortunatly in this group, Lewis and Roger ensure their spin everything > into FUD, preventing intelligent conversation. As soon as you are capable of an intelligent conversion, you let us know. So far, no go. -- 'I'm just going to kick some arse dear' 'Oh, good. Just be sure you wrap up well, then.'
[toc] | [prev] | [next] | [standalone]
| From | Jim Gibson <JimSGibson@gmail.com> |
|---|---|
| Date | 2016-11-29 18:10 -0800 |
| Message-ID | <291120161810490463%JimSGibson@gmail.com> |
| In reply to | #97451 |
In article <291120161828475976%nospam@nospam.invalid>, nospam <nospam@nospam.invalid> wrote: > In article <291120161456080223%JimSGibson@gmail.com>, Jim Gibson > <JimSGibson@gmail.com> wrote: > > > Since you aren't getting much joy from this newsgroup, try entering the > > following into your favorite search engine: "ssd wearing out" (159,000 > > hits on www.google.com). Let us know what you find out. > > *everything* wears out, including hard drives, batteries and other > components. nothing lasts forever, not even people. > > this whole 'ssds wear out' nonsense is just that, nonsense. the point > is that ssds are way the hell more reliable than hard drives. > > as for your idiotic search engine metric, put in 'earth is flat'. when > i do that with google, i get: > About 131,000,000 results (0.51 seconds) > which is roughly about *one* *thousand* times as many hits as what you > get for ssds wearing out. I think your irony detector is not working. -- Jim Gibson
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.sys.mac.system
csiph-web