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 | 20 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 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2016-11-28 20:37 +0000 |
| Message-ID | <ea3isuFfhj4U2@mid.individual.net> |
| In reply to | #97394 |
On 2016-11-28, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote: > On 2016-11-27 21:05, Jolly Roger wrote: > >> as all of them absolutely will eventually. It's definitely not worth my >> time and trouble to babysit my storage devices in anticipation of some >> far-off day when they finally fail, > > The idea is to know whether you will or will not get any advance warning > that the SSD has begin to experience cells that have "worn off". No, the idea is to use my computer to get shit done rather than babysitting it. -- 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-11-28 01:47 +0000 |
| Message-ID | <ea1glrF5snU1@mid.individual.net> |
| In reply to | #97381 |
On 2016-11-28, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote: > On 2016-11-27 15:07, Jolly Roger wrote: > >> I have an 8-year-old OWC SSD purchased in 2008 and in constant daily use >> as a startup drive for my Mac Pro (the majority of that time without >> TRIM enabled) without issue. There are no signs it will fail any time >> soon. It's backed up automatically all the time; so when it dies, I'll >> just replace it. I have better things to do than babysit my computer. > > My question, reformulated: how do you know that your SSD is in perfect > health and hasn't started to put "broken" pages into the "broken" list > that can't be used anymore ? My answer, reformulated: Why should I care? > the SSD has runned out of pages It's "run". You should have gone for a better English education. -- 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-11-28 06:31 +0000 |
| Message-ID | <slrno3njt9.1ftv.g.kreme@snow.local> |
| In reply to | #97381 |
In message <583b85ff$0$10986$c3e8da3$f017e9df@news.astraweb.com> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote: > On 2016-11-27 15:07, Jolly Roger wrote: >> I have an 8-year-old OWC SSD purchased in 2008 and in constant daily use >> as a startup drive for my Mac Pro (the majority of that time without >> TRIM enabled) without issue. There are no signs it will fail any time >> soon. It's backed up automatically all the time; so when it dies, I'll >> just replace it. I have better things to do than babysit my computer. > My question, reformulated: how do you know that your SSD is in perfect > health and hasn't started to put "broken" pages into the "broken" list > that can't be used anymore ? > my question, reformulated: When a disk begins to notice some pages are > no longer usable, does the user on OS-X get a warning or a means to > notice it happening? (since initially it would be transparent to user > sicne the SSD simply marks a page that was to have been written as > unusable and performs the write elsewhere). > But eventually, the number of pages marked unwriteable would grow to a > level when something would happen, right ? > Or does OS-X remain oblivious to this (and thus no info to user) until > the SSD has runned out of pages it can write to and returns an "error" > when OS-X attemts to write something? (aka, first sign to the user is > when the system fails with no warning before). Once again you manage to phrase you question in such a FUD laden bullshit way that I have no interest in answering your trolling. -- And east is east and west is west and if you take cranberries and stew them like applesauce they taste much more like prunes than rhubarb does.
[toc] | [prev] | [next] | [standalone]
| From | JF Mezei <jfmezei.spamnot@vaxination.ca> |
|---|---|
| Date | 2016-11-28 02:07 -0500 |
| Message-ID | <583bd7a6$0$1557$c3e8da3$12bcf670@news.astraweb.com> |
| In reply to | #97397 |
On 2016-11-28 01:31, Lewis wrote: > Once again you manage to phrase you question in such a FUD laden > bullshit way that I have no interest in answering your trolling. How is this FUD? I asked if OS-X detects/warns when and SSD starts to experience cells that can't be written anymore. This is a new failure which happens while the disk is still perfectly readable. SMART utilities report bad sectors, CRC errors and bad block revectoring. So it isn't clear to me how an SSD behaves (from a SMART point of view) when some cells start to become unwritable. Since every write results in virtual remapping of blocks to new physical pages, it is likely the computer won't feel when a write tried to happen onto a cell that could no longer be written to. Or will the SSD think thr write happened and the failure of the write will go undetected?
[toc] | [prev] | [next] | [standalone]
| From | Lewis <g.kreme@gmail.com.dontsendmecopies> |
|---|---|
| Date | 2016-11-29 01:40 +0000 |
| Message-ID | <slrno3pn6e.1i38.g.kreme@snow.local> |
| In reply to | #97398 |
In message <583bd7a6$0$1557$c3e8da3$12bcf670@news.astraweb.com> JF Mezei <jfmezei.spamnot@vaxination.ca> wrote: > On 2016-11-28 01:31, Lewis wrote: >> Once again you manage to phrase you question in such a FUD laden >> bullshit way that I have no interest in answering your trolling. > How is this FUD? I notice you deleted all the bullshit phrasing you used in your original. You really are the lamest of the lame. -- NO. I CANNOT BE BIDDEN. I CANNOT BE FORCED. I WILL DO ONLY THAT WHICH I KNOW TO BE RIGHT. --Mort
[toc] | [prev] | [next] | [standalone]
| From | Jim Gibson <JimSGibson@gmail.com> |
|---|---|
| Date | 2016-11-29 14:56 -0800 |
| Message-ID | <291120161456080223%JimSGibson@gmail.com> |
| In reply to | #97398 |
In article <583bd7a6$0$1557$c3e8da3$12bcf670@news.astraweb.com>, JF Mezei <jfmezei.spamnot@vaxination.ca> wrote: > On 2016-11-28 01:31, Lewis wrote: > > > Once again you manage to phrase you question in such a FUD laden > > bullshit way that I have no interest in answering your trolling. > > > How is this FUD? I asked if OS-X detects/warns when and SSD starts to > experience cells that can't be written anymore. This is a new failure > which happens while the disk is still perfectly readable. > > SMART utilities report bad sectors, CRC errors and bad block > revectoring. So it isn't clear to me how an SSD behaves (from a SMART > point of view) when some cells start to become unwritable. Since every > write results in virtual remapping of blocks to new physical pages, it > is likely the computer won't feel when a write tried to happen onto a > cell that could no longer be written to. Or will the SSD think thr write > happened and the failure of the write will go undetected? 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. Thanks. -- Jim Gibson
[toc] | [prev] | [next] | [standalone]
| From | nospam <nospam@nospam.invalid> |
|---|---|
| Date | 2016-11-29 18:28 -0500 |
| Message-ID | <291120161828475976%nospam@nospam.invalid> |
| In reply to | #97448 |
In article <291120161456080223%JimSGibson@gmail.com>, Jim Gibson <JimSGibson@gmail.com> wrote: > > > Once again you manage to phrase you question in such a FUD laden > > > bullshit way that I have no interest in answering your trolling. > > > > > > How is this FUD? I asked if OS-X detects/warns when and SSD starts to > > experience cells that can't be written anymore. This is a new failure > > which happens while the disk is still perfectly readable. > > > > SMART utilities report bad sectors, CRC errors and bad block > > revectoring. So it isn't clear to me how an SSD behaves (from a SMART > > point of view) when some cells start to become unwritable. Since every > > write results in virtual remapping of blocks to new physical pages, it > > is likely the computer won't feel when a write tried to happen onto a > > cell that could no longer be written to. Or will the SSD think thr write > > happened and the failure of the write will go undetected? > > 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.
[toc] | [prev] | [next] | [standalone]
| From | Lewis <g.kreme@gmail.com.dontsendmecopies> |
|---|---|
| Date | 2016-11-30 00:52 +0000 |
| Message-ID | <slrno3s8ou.1s71.g.kreme@snow.local> |
| In reply to | #97451 |
In message <291120161828475976%nospam@nospam.invalid> nospam <nospam@nospam.invalid> wrote: > In article <291120161456080223%JimSGibson@gmail.com>, Jim Gibson > <JimSGibson@gmail.com> wrote: >> > > Once again you manage to phrase you question in such a FUD laden >> > > bullshit way that I have no interest in answering your trolling. >> > >> > >> > How is this FUD? I asked if OS-X detects/warns when and SSD starts to >> > experience cells that can't be written anymore. This is a new failure >> > which happens while the disk is still perfectly readable. >> > >> > SMART utilities report bad sectors, CRC errors and bad block >> > revectoring. So it isn't clear to me how an SSD behaves (from a SMART >> > point of view) when some cells start to become unwritable. Since every >> > write results in virtual remapping of blocks to new physical pages, it >> > is likely the computer won't feel when a write tried to happen onto a >> > cell that could no longer be written to. Or will the SSD think thr write >> > happened and the failure of the write will go undetected? >> >> 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. Mountains. Oceans. Planets. Stars. Galaxies. Everything is recycled. > this whole 'ssds wear out' nonsense is just that, nonsense. the point > is that ssds are way the hell more reliable than hard drives. But that doesn't help JF spread vague FUD assertions about Apple! -- Love seekest only self to please, To bind another to its delight Joys in another's loss of ease And builds a hell in Heaven's despite!
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2016-11-30 03:20 +0000 |
| Message-ID | <ea6usbF9ovmU1@mid.individual.net> |
| In reply to | #97453 |
On 2016-11-30, Lewis <g.kreme@gmail.com.dontsendmecopies> wrote: > In message <291120161828475976%nospam@nospam.invalid> > nospam <nospam@nospam.invalid> wrote: > >> this whole 'ssds wear out' nonsense is just that, nonsense. the point >> is that ssds are way the hell more reliable than hard drives. > > But that doesn't help JF spread vague FUD assertions about Apple! Yup. Like I said, I've had an SSD boot drive in my Mac Pro for *eight* *years* (mostly without TRIM enabled, too) and haven't had a single issue with it in all that time. It's still going strong. And since I use 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. -- 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-11-30 00:54 -0500 |
| Message-ID | <583e6990$0$51650$c3e8da3$f6268168@news.astraweb.com> |
| In reply to | #97456 |
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. 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. 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, 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. 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 ?
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2016-11-30 07:19 +0000 |
| Message-ID | <ea7criFcocfU1@mid.individual.net> |
| In reply to | #97457 |
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! > you cannot state that you're perfectly safe The fuck I can't. I have multiple automated backup sets stored on- and off-site, ensuring I'll lose no more than an hour of data at any time due to a hardware failure. > This isn't FUD Yes it is. > 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 ? 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. Your fear, uncertainty, and doubt are completely unwarranted, as usual. -- 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-11-30 16:38 -0500 |
| Message-ID | <583f46c4$0$31396$c3e8da3$dd9697d2@news.astraweb.com> |
| In reply to | #97458 |
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). > 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 | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2016-12-01 00:44 +0000 |
| Message-ID | <ea9a3tFqsreU1@mid.individual.net> |
| In reply to | #97467 |
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. > 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. Bullshit. Prove your assertion that making a read request following a write would get the data from RAM rather than disk. (I know from prior experience with you that you won't offer a single shred of proof of this bullshit assertion; and you couldn't anyway even if you wanted to because you are once again talking out of your ass about things you know little about. So you are full of shit until that changes, which it won't.) > The OS relies on the disk providing a confirmation of the write If a write operation fails, an error is generated. It's as simple as that. >> 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. Liar. I never said any such thing. > So how can you know ? As soon as a read or write failed, I'd know because an error would be displayed. No such problems have occurred. My eight-year-old SSD is just fine. > 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. And that has been answered in spades. Your refusal to accept the answer doesn't equate to no answer being given. The fact is when a read or write fails, macOS notifies the user of the problem. >> Your fear, uncertainty, and doubt are completely unwarranted, as >> usual. > > Wanting to understand how things work is not "fear" or FUD. You're rejecting everything anyone says here that doesn't fit your idiotic and misinformed narrative. You aren't trying to learn a thing here. -- 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 | joe <none@domain.invalid> |
|---|---|
| Date | 2016-11-30 21:11 -0600 |
| Message-ID | <o1o4co$68a$1@gioia.aioe.org> |
| In reply to | #97472 |
On 11/30/2016 06:44 PM, Jolly Roger wrote: >> 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. > > Bullshit. Prove your assertion that making a read request following a > write would get the data from RAM rather than disk. (I know from prior > experience with you that you won't offer a single shred of proof of this > bullshit assertion; and you couldn't anyway even if you wanted to > because you are once again talking out of your ass about things you know > little about. So you are full of shit until that changes, which it > won't.) > Actually, that's one thing JF got right. If the data is already in the buffer, that is what will be returned. The exception would be if an FUA bit is set in the read command.
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2016-12-01 03:34 +0000 |
| Message-ID | <ea9k2kFtat1U1@mid.individual.net> |
| In reply to | #97474 |
On 2016-12-01, joe <none@domain.invalid> wrote: > On 11/30/2016 06:44 PM, Jolly Roger wrote: > >>> 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. >> >> Bullshit. Prove your assertion that making a read request following a >> write would get the data from RAM rather than disk. (I know from prior >> experience with you that you won't offer a single shred of proof of this >> bullshit assertion; and you couldn't anyway even if you wanted to >> because you are once again talking out of your ass about things you know >> little about. So you are full of shit until that changes, which it >> won't.) > > Actually, that's one thing JF got right. If the data is already in the > buffer, that is what will be returned. The exception would be if an FUA > bit is set in the read command. Not always. Anyway, I'm not holding my breath waiting for a citation proving it either way. -- 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:55 +0000 |
| Message-ID | <slrno407g3.24ko.g.kreme@snow.local> |
| In reply to | #97474 |
In message <o1o4co$68a$1@gioia.aioe.org> joe <none@domain.invalid> wrote: > On 11/30/2016 06:44 PM, Jolly Roger wrote: >>> 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. >> >> Bullshit. Prove your assertion that making a read request following a >> write would get the data from RAM rather than disk. (I know from prior >> experience with you that you won't offer a single shred of proof of this >> bullshit assertion; and you couldn't anyway even if you wanted to >> because you are once again talking out of your ass about things you know >> little about. So you are full of shit until that changes, which it >> won't.) >> > Actually, that's one thing JF got right. If the data is already in the > buffer, that is what will be returned. The exception would be if an FUA > bit is set in the read command. The write buffer is treated separately from the read buffer. If the data has already been read of the disk, it will be in the buffer. -- I HAVE NEITHER BEEN THERE NOR DONE THAT Bart chalkboard Ep. AABF17
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@freelunchvideotron.ca> |
|---|---|
| Date | 2016-12-01 16:51 -0500 |
| Message-ID | <cbCdnXlVEtDXBt3FnZ2dnUU7-XPNnZ2d@giganews.com> |
| In reply to | #97472 |
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? Does it read the sector ( or block) back? That is the sole way to verify to perfection that there was not a write failure. I can't find anything online showing how OS X detects a disk write failure. Any deep references? -- She hummed to herself because she was an unrivaled botcher of lyrics. -Nick (Gone Girl), Gillian Flynn.
[toc] | [prev] | [next] | [standalone]
| From | JF Mezei <jfmezei.spamnot@vaxination.ca> |
|---|---|
| Date | 2016-12-01 18:46 -0500 |
| Message-ID | <5840b64a$0$8508$b1db1813$7968482@news.astraweb.com> |
| In reply to | #97481 |
On 2016-12-01 16:51, Alan Browne 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. A disk read immediately after a disk write of the same block will result in the data being back to the process coming from the hard drive,s own buffer. (and in the case of disk arrays, there is double buffering with the array having buffers and each disk having buffers. This is made worse as many disk suibsystems do not garantee that the write was actually made to the platter at the time where the IO competes, it only garantees that the disk drive has received the IO and queued it to be written from its buffers. (for performance, disks will often re-order writes so they are done in sequence of sectors appearing under the head, or bunch multiple small writes to sequential sectors into a single one. This matters in power failure situations where a process who has been told the IO succeeded and thus committed the transaction when the transaction was not actually written yet. > > I can't find anything online showing how OS X detects a disk write > failure. Any deep references? When you di a disk image backup, it has a separate disk verification pass after it has created/written the whole drive. This basically eliminates any rtesidual "data in buffer" and forces all data to be read from the backup disk. For normal everyday IO, all that happens is the OS gets the status code from the IO request (which is based on the device driver getting an "OK" or not in that drive's specific language (SATA, SCSI, SAS, USB etc)
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@freelunchvideotron.ca> |
|---|---|
| Date | 2016-12-01 19:37 -0500 |
| Message-ID | <B6GdnTwvmrvYX93FnZ2dnUU7-InNnZ2d@giganews.com> |
| In reply to | #97483 |
On 2016-12-01 18:46, JF Mezei wrote: > On 2016-12-01 16:51, Alan Browne 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. > > A disk read immediately after a disk write <s> Not what I asked. >> >> I can't find anything online showing how OS X detects a disk write >> failure. Any deep references? > > > When you di a disk image backup, it has a separate disk verificatio <s> Not what I asked. Before you can get even close to your answer you have to know what happens in a normal write operation. Most OS's do not verify that a write was successful down to the media in the course of a normal write. But I don't know in detail how Unix/BSD/OSX does it. Further, what (if any) "improvements" Apple (or others have) made wrt to SSD's. But really: you're obsessing over media failure when you should be reviewing your backup plan and implementation. -- She hummed to herself because she was an unrivaled botcher of lyrics. -Nick (Gone Girl), Gillian Flynn.
[toc] | [prev] | [next] | [standalone]
| From | JF Mezei <jfmezei.spamnot@vaxination.ca> |
|---|---|
| Date | 2016-12-02 00:46 -0500 |
| Message-ID | <58410aca$0$15589$c3e8da3$9deca2c3@news.astraweb.com> |
| In reply to | #97484 |
On 2016-12-01 19:37, Alan Browne wrote: > Not what I asked. Rereading your question: The OS issues the IO request to the device driver. Device driver sets the correct bits and sends the IO to the device using whatever driver for the bus to which the device is connected. When the disk has completed the IO, it returns a status code to the driver which then completes the IO for the OS and the OS completes the IO to the application. There is no read verification done. The OS simply assumes that the IO request status code given by the device driver indicates success or failure. (hence the problem with disk drives and disk arrays that return a "success" before the actual write has been done to the platter as they optimize their opetations for speed). > But really: you're obsessing over media failure when you should be > reviewing your backup plan and implementation. I am not obsessing. I asked a simple question and instead of saying they didn't know, Lewis and Jilly Roger blew it out of proportions. Consider this: IF indications of failure start a month before total failure, then this gives me time to get a new drive and copy everything at my leasure before failure. If there are no indications until the drive failes (or indication are in minutes or hours, it means my system may not be able to boot while I wait for spare drive to be shipped, so even though I have a backup, there is still downtime and loss of availability of my data/documents. The backups would also have to be checked in case the last backuip was incomplete as it was being done while system failed. So it is always better to rescue a drive before it fails when possible.
[toc] | [prev] | [next] | [standalone]
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
Back to top | Article view | comp.sys.mac.system
csiph-web