Sony to ax 10,000 jobs in turnaround bid: Nikkei - (via Reuters)

In article , Mxsmanic
wrote:

As nospam points out, the seek time for SSD's is close to 0 - SSD's are
replacing more and more HD's or are added to HD's to store the most
accessed files in hybrid setups.

SSDs fail after a certain number of write operations, which is a very serious
risk.

it's actually fairly high number of write operations and not a
significant risk. with no moving parts they are *more* reliable than
hard drives.

hds also fail, and it isn't necessarily due to write operations. they
can fail for all sorts of reasons. i have one with a head crash in the
closet and another with dozens of bad blocks.

backup regularly and you won't lose anything.

And they are still extremely slow compared to RAM and CPUs.

so go get a terabyte of ram to store your files. let us know how well
that works out for you.

"David J. Littleboy" wrote in message
...
[]
Yep, SSDs are now mainline. The new peecee here has a 128 GB SSD and a
500 GB HD. I'm being a bit nervous about setting things up, and putting
more program files on the HD than may be necessary. But things like
Lightroom and Photoshop tend to put scratch files on "C", so I need to
leave lots of free space there.

Whatever, it's a new generation. Our old ideas are wrong.

-- David J. Littleboy
Tokyo, Japan

I would be careful about having too much write access going on with the
SSD - try to keep it as read-only as possible. I have tended to put files
with frequent write I/O on the HD rather than the SSD, as SSDs still have
a limited number of write cycles. With Windows-7 it's reasonably easy to
see which files have the maximum write activity.

Cheers,
David

"David J Taylor" writes:

"David J. Littleboy" wrote in message
...
[]
Yep, SSDs are now mainline. The new peecee here has a 128 GB SSD and
a 500 GB HD. I'm being a bit nervous about setting things up, and
putting more program files on the HD than may be necessary. But
things like Lightroom and Photoshop tend to put scratch files on
"C", so I need to leave lots of free space there.

Whatever, it's a new generation. Our old ideas are wrong.

-- David J. Littleboy
Tokyo, Japan

I would be careful about having too much write access going on with
the SSD - try to keep it as read-only as possible. I have tended to
put files with frequent write I/O on the HD rather than the SSD, as
SSDs still have a limited number of write cycles. With Windows-7 it's
reasonably easy to see which files have the maximum write activity.

With modern life-cycles and modern wear-leveling code in the SSD, this
is a non-issue for anything like a normal "temp file" or other working
files.

It might still be an issue for a communication file between two
processes that gets heavily used, maybe (24/7, megabytes a minute, and
so forth).

I've had an SSD as system drive for my W7 system for several years now.
--
David Dyer-Bennet, ; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

Mxsmanic writes:

nospam writes:

it's actually fairly high number of write operations and not a
significant risk. with no moving parts they are *more* reliable than
hard drives.

With frequently rewritten files--often the very kind to which you'd want quick
access--the write limit will be exhausted surprisingly fast.

It's not the write limit for those particular sectors, though, it's the
total write limit for the SSD drive. There's wear-leveling code that
spreads the erase cycles around.

Disk drives today can run for years continuously without a failure.

And so can SSDs.
--
David Dyer-Bennet, ; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

In article , Mxsmanic
wrote:

it's actually fairly high number of write operations and not a
significant risk. with no moving parts they are *more* reliable than
hard drives.

With frequently rewritten files--often the very kind to which you'd want quick
access--the write limit will be exhausted surprisingly fast.

nope, due to wear leveling.

Disk drives today can run for years continuously without a failure.

ssds for even longer.

i've had a couple of drive failures in the past few years. hard drives
definitely fail.

"David Dyer-Bennet" wrote in message
...
[]
With modern life-cycles and modern wear-leveling code in the SSD, this
is a non-issue for anything like a normal "temp file" or other working
files.

It might still be an issue for a communication file between two
processes that gets heavily used, maybe (24/7, megabytes a minute, and
so forth).

I've had an SSD as system drive for my W7 system for several years now.
--
David Dyer-Bennet, ; http://dd-b.net/

David,

You need to be careful, though. I have applications which write 5 Mb log
files once a minute. OK for SSD? Those applications are handling
reading, processing and writing of 60 GB of data every day. OK for SSD?
As a "system drive", it's hammered a lot less than a "data" disk might be,
and I'm happy to use an SSD in that case. I'm just saying that you need
to have a handle on what your disk usage actually is.

Cheers,
David

"David J Taylor" writes:

"David Dyer-Bennet" wrote in message
...
[]
With modern life-cycles and modern wear-leveling code in the SSD, this
is a non-issue for anything like a normal "temp file" or other working
files.

It might still be an issue for a communication file between two
processes that gets heavily used, maybe (24/7, megabytes a minute, and
so forth).

I've had an SSD as system drive for my W7 system for several years now.
--
David Dyer-Bennet, ; http://dd-b.net/

David,

You need to be careful, though. I have applications which write 5 Mb
log files once a minute. OK for SSD? Those applications are handling
reading, processing and writing of 60 GB of data every day. OK for
SSD?

That sounds rather like the specific exception I made in my second
paragraph there, yes.

As a "system drive", it's hammered a lot less than a "data" disk
might be, and I'm happy to use an SSD in that case. I'm just saying
that you need to have a handle on what your disk usage actually is.

For specialized applications, sure. For a normal consumer system, any
weird repeating use of a file is likely to end up on the system disk by
default.
--
David Dyer-Bennet, ; http://dd-b.net/
Snapshots: http://dd-b.net/dd-b/SnapshotAlbum/data/
Photos: http://dd-b.net/photography/gallery/
Dragaera: http://dragaera.info

On 2012-04-17 21:56 , Mxsmanic wrote:
Alan Browne writes:

You're ignoring that file systems write large file blocks sequentially
over many sectors rather than filling in nearest available sectors.

Most disk I/Os are extremely small, around 1000 bytes. And they typically are
randomly distributed over the disk.


"Most" are not that small. And, regardless, small files do need to be
accessed, read and written. When files are saved, the entire file is
typically rewritten (exception is indexed files).

But photos, audio, web pages and so on (and the exploding XML content)
are re-written entirely.

Further, in well designed OS' writes do not occur on post but when the
OS determines the optimal time to do so. As far as an app (or higher
layer in the OS) is concerned, the file was written and can be read as
if written. Where it actually is is transparent to higher levels in the
system.

The vast majority of files on a system lie in a contiguous block ...

Well, they are near each other but not contiguous, since that increases
fragmentation if they grow.

Re-written files are typically re-written entirely, not appended and
linked. Simply because it's simpler and changes to a file are usually
somewhere "in" the file, not simply appended.


But either way, a new disk access is required for each physical I/O.

Not when the file is sequential. There is no need other than to wait
for the sector to come - and occasionally move by one cylinder.

Clarification, very large files may indeed be segmented but the segments
are huge (hundred MB level).

Since PC memories of 2, 4 , 8 GB and so on are more and more common, the
amount of disk cache allocated to system memory has risen (and is
flexible in size). Recently read/written files are often already in
memory when needed. This reduces seek times dramatically.

If the RAM size is not a substantial fraction of the total used disk space,
and access is random, disk cache may buy nothing at all. But in practice there
are some files that are usually at least partially in cache. The problem is
that many are not, and so very large numbers of physical disk I/Os are still
required.

It's not about all being available but many being available. All such
approaches take bites out of the issue - not solve it entirely.

As nospam points out, the seek time for SSD's is close to 0 - SSD's are
replacing more and more HD's or are added to HD's to store the most
accessed files in hybrid setups.

SSDs fail after a certain number of write operations, which is a very serious
risk. And they are still extremely slow compared to RAM and CPUs.

Flash memory continues to push the write limit. "Wear leveling" spreads
out the effect as well.

Do you know of any first flight MacBook Air's that have failed for this
reason? (And they didn't have the best wear leveling strategy).

The fact that RAM and CPU's are quicker is irrelevant. The file system
is not intended to be used in real time computation. Most files being
"worked on" can fit in memory when needed. The transfer time is what it is.

You could build a disk system entirely of powered static or dynamic ram.
It would be very fast and very expensive and would require a permanent
power source (and backup to disk) and a special i/o channel to move the
data quickly. Your choice.


--
"I was gratified to be able to answer promptly, and I did.
I said I didn't know."
-Samuel Clemens.

"Alan Browne" wrote:

SSDs fail after a certain number of write operations, which is a very
serious
risk. And they are still extremely slow compared to RAM and CPUs.

Flash memory continues to push the write limit. "Wear leveling" spreads
out the effect as well.

Do you know of any first flight MacBook Air's that have failed for this
reason? (And they didn't have the best wear leveling strategy).

The fact that RAM and CPU's are quicker is irrelevant. The file system
is not intended to be used in real time computation. Most files being
"worked on" can fit in memory when needed. The transfer time is what it is.

You could build a disk system entirely of powered static or dynamic ram.
It would be very fast and very expensive and would require a permanent
power source (and backup to disk) and a special i/o channel to move the
data quickly. Your choice.


Just having bought a peecee with an SSD as it's main disk, I should have
looked into thisg.

http://en.wikipedia.org/wiki/Solid-s..._disk_drive s

Looking around, it seems that the current state of things is that SSDs are
seen as having significantly longer expected operating lifetimes than HDs
for normal PC usage. It's multiple decades for SDDs vs. 3 to 6 years for
HDs. HDs have mechanical parts that wear.

-- David J. Littleboy
Tokyo, Japan

In article , Mxsmanic
wrote:

It's multiple decades for SDDs vs. 3 to 6 years for HDs.

That depends on the number of writes, not the total operating time. A file
that is regularly written can go through a SSD much more quickly.

you'll probably want to replace it because of wanting more capacity,
not because it failed.

HDs have mechanical parts that wear.

So do SSDs. Every write damages the SSDs slightly, until eventually it stops
working.

there are no mechanical parts in an ssd.