Ad
Ad
Ad
Pages: « 1 [2] 3 4 5 »   Bottom of Page
Print
Author Topic: Drive capacity/fullness vs. performance  (Read 15030 times)
mephisto42
Newbie
*
Offline Offline

Posts: 3


« Reply #20 on: April 20, 2012, 03:34:30 AM »
ReplyReply

I doubt the quote above (A "Solid 3" SSD reached serious degration after 18 TBytes (write) and  dropped below 20 percent of it's initial write performance after ca. 22 TBytes.

Basically that quote is correct, but I can give You some additional details: After 18 TByte written (continiously 24/7, incrompessible data) the write performance degraded. After 25 TByte it was as low as 10 MByte/s (the drive startet at 140 MByte/s with incrompessible data). This seems to be a self protection mechanism of the Sandforce-Controller called Life Time Throttling. As far as we know, the controller lowers this brake again, if the drive has reached a better data written per hour value again. This means: leave the drive powered on but without writes for a while. In a real world use case this probably never happens at all.

A "FM 25" performed with its maximum performance until 152 TBytes were written and dropped below 10 percent after.
That is basically, what we have observed.

If you work back up the thread the fundamental question is: Will an SSD's performance ever degrade below a normally plattered HDD ?
Yes, You can construct such cases with theoretical workloads (or very stupid configurations). But it depends on the controller and the use case. With a real world use case it doesn't seem very probable, as long as You don't try to use truecrypt in combination with some Sandforce-controllers. And it always only regards the write but not the read performance.

To give You an idea of more realistic numbers: Intel guarantees, that You can write 20 GByte each day for 5 years to their SSD 320. I don't know, how many photos You take per day, but I don't do 20 GByte a day. I also think, that typical for a photographer's use case is, that a certain amount of pictures stay on the drive for a long period of time. Compared to this static data the amount of permanetly changed data changed will be relatively small. So You won't ever reach lot's of "TByte written". This might be different, if You use a SSD as photoshop scratch disk.

Best regards Benjamin Benz
Logged
Rhossydd
Sr. Member
****
Offline Offline

Posts: 1965


WWW
« Reply #21 on: April 20, 2012, 03:58:43 AM »
ReplyReply

Basically that quote is correct,
Well, I'm sure it is, and I'm sure it makes sense to you, but I haven't a clue what a 'super 3' or 'FM25' is.
Quote
To give You an idea of more realistic numbers: Intel guarantees, that You can write 20 GByte each day for 5 years to their SSD 320. I don't know, how many photos You take per day, but I don't do 20 GByte a day. I also think, that typical for a photographer's use case is, that a certain amount of pictures stay on the drive for a long period of time. Compared to this static data the amount of permanetly changed data changed will be relatively small. So You won't ever reach lot's of "TByte written". This might be different, if You use a SSD as photoshop scratch disk.
I think the users most likely to hit those sort of numbers are press guys using laptops in the field for sports work. They may well be moving multi-gigs of photos onto the drive for sorting, labelling and transmission on, then archiving. However few work every day and not many will hit 20gb either, so that drive life could be approaching ten years, probably more than the working life of the machine in practice.

The question remains when does SSD performance fall below HDD performance ?

Logged
mephisto42
Newbie
*
Offline Offline

Posts: 3


« Reply #22 on: April 20, 2012, 04:26:58 AM »
ReplyReply

Hi,

I haven't a clue what a 'super 3' or 'FM25' is.

I guess the original posting meant with FM25 our test drive of the type FM-25S2S-100GBP1 from GSkill and a Solid 3 from OCZ. I'm sure You can find detailed data for these drives with google.

I think the users most likely to hit those sort of numbers are press guys using laptops in the field for sports work. They may well be moving multi-gigs of photos onto the drive for sorting, labelling and transmission on, then archiving. However few work every day and not many will hit 20gb either, so that drive life could be approaching ten years, probably more than the working life of the machine in practice.

And as far as we know this 20 GByte/day number is a very, very, very safe number, which Intel gives to keep their return rates extremly low. If You multiply it with 365 days and 5 years You get only 36,5 TByte. In our torture test the Media wear out indicator of the SSD320 from Intel droped from 100 to 83 after 35 TByte written. There was no performance loss at that time. So I guess, that long before even the press photographer runs into this kind of problem, his Notebook has been stolen or is damaged or outdated long before.

The question remains when does SSD performance fall below HDD performance ?
There is no simple answer to this question. I'll try it with three extreme approaches:
* If You don't buy a crappy SSD and don't have a very stupid setup (like enryption on a compressing SSD) probably never.
* For torture tests in the lab You might run into problems after some weeks.
* With a very stupid setup and a bad SSD You can observer performance problems at once.

Perhaps You might be interested in reading the original (german) articles:
http://www.heise.de/artikel-archiv/ct/2012/3/66_kiosk
http://www.heise.de/artikel-archiv/ct/2011/22/150_kiosk
http://www.heise.de/artikel-archiv/ct/2011/26/102_kiosk

best regards
Benjamin Benz
Logged
Rhossydd
Sr. Member
****
Offline Offline

Posts: 1965


WWW
« Reply #23 on: April 20, 2012, 06:37:45 AM »
ReplyReply

Thanks for the contribution Benjamin;

I think the quote below sums it up
Quote
The question remains when does SSD performance fall below HDD performance ?
There is no simple answer to this question. I'll try it with three extreme approaches:
* If You don't buy a crappy SSD and don't have a very stupid setup (like enryption on a compressing SSD) probably never.
* For torture tests in the lab You might run into problems after some weeks.
* With a very stupid setup and a bad SSD You can observer performance problems at once.
The first scenario is probably the most appropriate here. In routine, average use they'll always out perform HDDs.
Logged
PierreVandevenne
Sr. Member
****
Offline Offline

Posts: 510


WWW
« Reply #24 on: April 20, 2012, 11:55:42 AM »
ReplyReply

As far as conventional hard disk drives are concerned, the main cause of performance degradation for sequential access when becoming "full" is simply the fact that the length of the tracks decreases as one comes closer to the center - there are simply less sectors travelling in front of the head per rotation on the inside than there is on the outside of the platter. A nice explanation of this and HDD zones can be found here (http://hddscan.com/doc/HDD_Tracks_and_Zones.html). That's why we have nicely decreasing curves towards the center in the tests. The difference is not something like 3 or 4 to 1 as it would be expected "geometrically" but less than that because, in most tests, the data being written or read is spread on many consecutive tracks and track to track + 1 switching is a fairly constant factor.
Logged
chrismurphy
Jr. Member
**
Offline Offline

Posts: 77


« Reply #25 on: April 20, 2012, 01:05:54 PM »
ReplyReply

HDD Geometry:

Outer sectors of a hard disk drive outperform the inner sectors.

Assuming the number of sectors per cylinder are the same from the inner to outer cylinder, the exact same number of sectors are being read in the same amount of time.

Modern drives aren't configured this way. They pack more sectors on outer tracks than on inner tracks. Because there are more sectors read for each rotation, outer tracks out perform inner tracks.

The first sector of a hard drive, is referred to as LBA 0, and it's location is on the outer cylinder of the disk. Drives read from outside to inside. This leads to the very real experience that a drive seems to get slower as it fills up, because as it fills up more inner tracks are being used, which have fewer sectors per cylinder, and commensurately higher seek times.

A technique referred to as short stroking limits the disk to that of perhaps just 10-20% of the disk, using only outer cylinders, in order to limit storage of data to just the fastest portion of the disk. This comes at a cost of not using the full available storage, but performance benefit is significant, depending on application it can double the performance of a drive.

RAID 1, 5, 6:

As for RAID 5 write performance, I think this is less of a concern than the write hole problem, and with larger arrays the long rebuild times during which a 2nd disk could die leading to the collapse of the entire array. If there is a single unrecoverable error in parity with RAID 5 during a single disk rebuild, the array is toast. So RAID 5 is a tenuous case of high(er) data availability at best, perhaps suitable for smaller arrays and aggressive backups. It's better than nothing, I supposed, but I'd sooner go to the effort of a RAIDZ1 based array, on a FreeNAS setup. While both RAID 5 and RAIDZ1 use single parity, ZFS doesn't suffer from the write hole problem.

ZFS:

I will try to set aside the appalling state of affairs with Windows and Mac OS file systems, and volume management. NTFS and JHFS+/X lack features available, some of which have been around for 15+ years such as logical volume management, in free software available to anyone.

http://arstechnica.com/apple/reviews/2011/07/mac-os-x-10-7.ars/12
http://research.cs.wisc.edu/adsl/Publications/corruption-fast08.html

Considering Microsoft has at least publicly announced (for Windows 8 server) a new resilient file system, which appears to have many of the features of modern file systems like ZFS and Btrfs, I'll consider that sufficient evidence of NTFS's present inadequacy. Apple was about to pull the trigger on ZFS, then pulled back for reasons speculated, but there is presently no publicly announced alternative or even acknowledgement of JHFS+/X's inadequacies. Nevertheless, its a problem. I'd consider them strictly local file systems only. And I'd keep the data on them limited (operating system, applications and short term data such as scratch/working disks including a smallish RAID 0 or 10). I'd put the bulk of the data I actually care about an another file system.

As for the wider implementation of ZFS, previously I mentioned FreeNAS. There is also a more commercialized version with support called TrueNAS. And there is a free and commercialized (based on array size, free up to ~17TB) ZFS based NAS called Nexenta.

For smaller scale implementations, the ZEVO product from http://tenscomplement.com/ is interesting. Presently it is a single disk, native ZFS on Mac OS X implementation. Soon, their RAIDZ capable versions are expected to ship. The dollar cost is reasonable. But changing your file system is something most people simply expect their operating system supplier to…well, supply. And I don't think that's unreasonable to expect. Yet here we are with inadequate, ancient file system supplied by both of the major desktop operating system platforms.
« Last Edit: April 20, 2012, 02:47:42 PM by chrismurphy » Logged
dreed
Sr. Member
****
Offline Offline

Posts: 1260


« Reply #26 on: April 20, 2012, 09:00:42 PM »
ReplyReply

...
RAID 1, 5, 6:

As for RAID 5 write performance, I think this is less of a concern than the write hole problem, and with larger arrays the long rebuild times during which a 2nd disk could die leading to the collapse of the entire array. If there is a single unrecoverable error in parity with RAID 5 during a single disk rebuild, the array is toast. So RAID 5 is a tenuous case of high(er) data availability at best, perhaps suitable for smaller arrays and aggressive backups. It's better than nothing, I supposed, but I'd sooner go to the effort of a RAIDZ1 based array, on a FreeNAS setup. While both RAID 5 and RAIDZ1 use single parity, ZFS doesn't suffer from the write hole problem.

ZFS:
...
For smaller scale implementations, the ZEVO product from http://tenscomplement.com/ is interesting. Presently it is a single disk, native ZFS on Mac OS X implementation. Soon, their RAIDZ capable versions are expected to ship. The dollar cost is reasonable. But changing your file system is something most people simply expect their operating system supplier to…well, supply. And I don't think that's unreasonable to expect. Yet here we are with inadequate, ancient file system supplied by both of the major desktop operating system platforms.

If performance is important then you want to avoid RADIZ because RAIDZ effectively has all of your hard drives acting and moving as one, rather than being able to drive them all independently. Great for data reliability, terrible for performance (RAIDZ is slower than non-mirror/non-RAID ZFS and slower than mirrored ZFS.)

Similarly, ZFS is not immune to the problems associated with RAID, where a disk dieing during rebuild can take out your entire data set.

The most significant feature of ZFS for photographers is that data is checksum'd by the operating system before being stored on disk. This means that if the disk or the path to the disk (including controller) causes corruption then you'll find out and hopefully be able to correct it (if using mirroring or raidz.) Prior to ZFS, this was only available on expensive NAS solutions. Hopefully more vendors will include data checksum'ing in their disk storage products/operating systems. But what you've got to ask yourself is how likely is this to happen?

The answer to that question is perhaps most easily found in this forum - how many posters here have posted complaining about the operating system corrupting their image or that when they went back to look at an image from 5 years ago that they couldn't read the file on their hard drive?

You're more likely to find people complaining about hard drives themselves failing than the data becoming corrupt - but that doesn't mean data corruption isn't a problem. One of the first USB-Compact Flash adapters I used randomly corrupted data during long transfers and this wasn't visible until I attempted to open up the image in Lightroom (at first I didn't realise that it was the USB adapter that was at fault - I thought the camera had written out bad data!)
Logged
John.Murray
Sr. Member
****
Offline Offline

Posts: 893



WWW
« Reply #27 on: April 20, 2012, 11:09:21 PM »
ReplyReply

Windows ReFS and ZFS for Apple is available now.

Server 2012 public Beta is available to anyone who cares to sign up:
http://blogs.technet.com/b/windowsserver/archive/2012/03/01/windows-server-8-beta-available-now.aspx

ZFS is commercially available from Tens http://tenscomplement.com/

One nice thing about ReFS is that is largely API compatible with NTFS - this means most applications will immediately be able to take advantage of it.  The downside, is that it's only available on Server at this point, it will not be available on Windows 8:

http://blogs.msdn.com/b/b8/archive/2012/01/16/building-the-next-generation-file-system-for-windows-refs.aspx


« Last Edit: April 20, 2012, 11:11:58 PM by John.Murray » Logged

chrismurphy
Jr. Member
**
Offline Offline

Posts: 77


« Reply #28 on: April 22, 2012, 01:27:21 PM »
ReplyReply

If performance is important then you want to avoid RADIZ because RAIDZ effectively has all of your hard drives acting and moving as one, rather than being able to drive them all independently. Great for data reliability, terrible for performance (RAIDZ is slower than non-mirror/non-RAID ZFS and slower than mirrored ZFS.)

Solvable by striped RAIDZ groups. And the fact a single disk saturates GigE anyway, it's unlikely this is a real performance problem, let alone one without a work around.

Quote
Similarly, ZFS is not immune to the problems associated with RAID, where a disk dieing during rebuild can take out your entire data set.

That is expected with single parity RAID of any sort, however RAIDZ single parity is still more reliable than single parity conventional RAID due to the lack of the write hole.

Quote
The most significant feature of ZFS for photographers is that data is checksum'd by the operating system before being stored on disk. This means that if the disk or the path to the disk (including controller) causes corruption then you'll find out and hopefully be able to correct it (if using mirroring or raidz.)

In the case of mirrored data, including RAIDZ, any error detection is automatically corrected, the corrupt version automatically repaired. You'd need to check dmesg to learn of it.


Quote
Hopefully more vendors will include data checksum'ing in their disk storage products/operating systems. But what you've got to ask yourself is how likely is this to happen?

Sun, Oracle, Microsoft, various Linux distros are all offering, or imminently offering, disk storage with file systems that include data checksumming. Missing is Apple.

Quote
The answer to that question is perhaps most easily found in this forum - how many posters here have posted complaining about the operating system corrupting their image or that when they went back to look at an image from 5 years ago that they couldn't read the file on their hard drive?

Flawed logic. The forum is not a scientific sample. Users have no reliable way of determining a problem may be the result of corrupt data. You assume the problem in every case is a.) restricted to an image; and b.) results in visible artifacts; c.) that they would post any sort of "could not read the file" experience on a forum, rather than go to a backup copy, and move along with the rest of their day.

I've had perhaps 1/2 dozen image files, so far, unreadable. I'm a certified storage and file system geek (perhaps secondary to color geek) and I cannot tell you whether this was bit rot, silent data corruption, or file system corruption. But the files, as read, were not considered recognizably encoded image data by any image viewer, or any version of Photoshop going back to 5.5 (and I mean 5.5 not CS 5.5). The backups were also affected, presumably because all of the backups were copies of corrupted files. Fortunately, they were synthetic test images and were relatively easily recreated. Nevertheless, if you think this problem is anything like a mouse, you've got one mouse with this anecdote, and as they say, where there's one mouse there's bound to be more. We really have no idea how big of a problem this is based on forums. So I refuse that premise entirely.

Clearly some significant companies think it's a problem or there wouldn't be so much active development on Btrfs: Oracle, Red Hat, Fujitsu, IBM, HP, and others.

Here's some research data on the subject. Google has also done a study.
http://research.cs.wisc.edu/adsl/Publications/corruption-fast08.html

Quote
You're more likely to find people complaining about hard drives themselves failing than the data becoming corrupt - but that doesn't mean data corruption isn't a problem. One of the first USB-Compact Flash adapters I used randomly corrupted data during long transfers and this wasn't visible until I attempted to open up the image in Lightroom (at first I didn't realise that it was the USB adapter that was at fault - I thought the camera had written out bad data!)

It's an example of SDC, which the paper above addresses and attributes, rather significantly, to firmware induced corruption. Message boards, unscientific samples though they are, are littered with people having "hardware" RAID controller firmware induced corruption of their RAIDs, obliterating all data upon a single disk failing because data couldn't be reconstructed from (corrupted) parity.

So it's a bigger problem than we think it is, just because we're thinking that the corruption would be obvious. And that's probably untrue. How many people get a RAID 1, 5, or 6 up and running, and actually yank a drive, pop in a spare and see if the RAID correctly rebuilds? Professionals do this. Most people doing it themselves do not. They assume the reconstruction will work. And too many people consider RAID a backup solution rather than about increasing the availability of data.
Logged
alain
Sr. Member
****
Offline Offline

Posts: 298


« Reply #29 on: April 22, 2012, 02:02:50 PM »
ReplyReply

...
The answer to that question is perhaps most easily found in this forum - how many posters here have posted complaining about the operating system corrupting their image or that when they went back to look at an image from 5 years ago that they couldn't read the file on their hard drive?

...

I have.  I run "global" md5 checks from time to time (read not frequent enough) and found errors.  I was "lucky" to recover those files from backups.
Logged
alain
Sr. Member
****
Offline Offline

Posts: 298


« Reply #30 on: April 22, 2012, 02:11:38 PM »
ReplyReply

Solvable by striped RAIDZ groups. And the fact a single disk saturates GigE anyway, it's unlikely this is a real performance problem, let alone one without a work around.

That is expected with single parity RAID of any sort, however RAIDZ single parity is still more reliable than single parity conventional RAID due to the lack of the write hole.

In the case of mirrored data, including RAIDZ, any error detection is automatically corrected, the corrupt version automatically repaired. You'd need to check dmesg to learn of it.


Sun, Oracle, Microsoft, various Linux distros are all offering, or imminently offering, disk storage with file systems that include data checksumming. Missing is Apple.

I suppose that running ZFS means setting up a dedicated linux box with quite some drives and thus limited by the LAN?
Is there a "simple" windows solution, read: inside the same pc with local speeds?
Logged
chrismurphy
Jr. Member
**
Offline Offline

Posts: 77


« Reply #31 on: April 22, 2012, 02:22:32 PM »
ReplyReply

I suppose that running ZFS means setting up a dedicated linux box with quite some drives and thus limited by the LAN?

Yes.

Sortof a non-relevant technicality but ZFS primarily runs on Solaris and BSD derivatives, rather than Linux. FreeNAS for example is FreeBSD based.

Quote
Is there a "simple" windows solution, read: inside the same pc with local speeds?

No. If you want a better file system locally, you'll have to wait for ReFS to appear possibly circa Windows 9. If you want speed and a more resilient file system, you'll need a 10 GigE network. Actually, you just need the link between the NAS and the workstations to be 10 GigE.

And Mac users are in the same boat, until tenscompliment ships their RAID and multidisk pool capable versions of ZEVO. Or Apple gets us a new file system.

Realize that GigE NAS speeds are in the realm of Firewire 800 speeds.
« Last Edit: April 22, 2012, 02:43:40 PM by chrismurphy » Logged
chrismurphy
Jr. Member
**
Offline Offline

Posts: 77


« Reply #32 on: April 22, 2012, 02:41:40 PM »
ReplyReply

I run "global" md5 checks from time to time (read not frequent enough) and found errors.

Adobe DNG files, since spec 1.2.0.0, have a tag containing an MD5 digest of the raw image data. Any DNG reader can read the raw image data in the DNG, produce an MD5 digest of it, and compare to the MD5 digest embedded in the DNG to verify that no raw image data pixels have changed since the original (embedded) MD5 was computed.

I haven't done exhaustive testing, but my understanding is that Adobe Camera Raw, Lightroom and DNG converter, do this automatically.
Logged
alain
Sr. Member
****
Offline Offline

Posts: 298


« Reply #33 on: April 22, 2012, 03:34:34 PM »
ReplyReply

Yes.

Sortof a non-relevant technicality but ZFS primarily runs on Solaris and BSD derivatives, rather than Linux. FreeNAS for example is FreeBSD based.

No. If you want a better file system locally, you'll have to wait for ReFS to appear possibly circa Windows 9. If you want speed and a more resilient file system, you'll need a 10 GigE network. Actually, you just need the link between the NAS and the workstations to be 10 GigE.

And Mac users are in the same boat, until tenscompliment ships their RAID and multidisk pool capable versions of ZEVO. Or Apple gets us a new file system.

Realize that GigE NAS speeds are in the realm of Firewire 800 speeds.
Well 10GigE is expensive and not that common.  As a pure backup solution GigE is probably more than fast enough.
Logged
alain
Sr. Member
****
Offline Offline

Posts: 298


« Reply #34 on: April 22, 2012, 03:36:15 PM »
ReplyReply

Adobe DNG files, since spec 1.2.0.0, have a tag containing an MD5 digest of the raw image data. Any DNG reader can read the raw image data in the DNG, produce an MD5 digest of it, and compare to the MD5 digest embedded in the DNG to verify that no raw image data pixels have changed since the original (embedded) MD5 was computed.

I haven't done exhaustive testing, but my understanding is that Adobe Camera Raw, Lightroom and DNG converter, do this automatically.

I use hashdeep and that does all files, also non image files...  Not perfect, because it was made for another reason. 
Logged
chrismurphy
Jr. Member
**
Offline Offline

Posts: 77


« Reply #35 on: April 22, 2012, 04:26:05 PM »
ReplyReply

I use hashdeep and that does all files, also non image files...  Not perfect, because it was made for another reason. 

The problem is that there's metadata inside of files that can legitimately change, which will also cause the MD5 hash to change, but the data you care about (just the raw image data) may not have.
Logged
dreed
Sr. Member
****
Offline Offline

Posts: 1260


« Reply #36 on: April 23, 2012, 12:34:28 AM »
ReplyReply

Quote
If performance is important then you want to avoid RADIZ because RAIDZ effectively has all of your hard drives acting and moving as one, rather than being able to drive them all independently. Great for data reliability, terrible for performance (RAIDZ is slower than non-mirror/non-RAID ZFS and slower than mirrored ZFS.)
Solvable by striped RAIDZ groups. And the fact a single disk saturates GigE anyway, it's unlikely this is a real performance problem, let alone one without a work around.

This only works in configurations where you have more than 6 disks. Otherwise you do not have enough disks to create more than one pool with a pair of disks plus parity. I suspect that nearly everyone here is looking at something with around half that number of disks.
Logged
dreed
Sr. Member
****
Offline Offline

Posts: 1260


« Reply #37 on: April 23, 2012, 12:47:16 AM »
ReplyReply

I suppose that running ZFS means setting up a dedicated linux box with quite some drives and thus limited by the LAN?
Is there a "simple" windows solution, read: inside the same pc with local speeds?

Unless you're a full on computer geek, ZFS should not be part of the equation. There are other aspects of the solution that will be far more important, such as what interfaces the product provides, how do you connect it, manage it, etc.

Probably the best solution is to find an external RAID thing that does USB 3.0 and get a USB 3.0 card for your computer if it doesn't have USB 3.0 in it. If you can't do USB 3.0, check if your computer has eSATA ports and go that path. Both USB and eSATA will give you performance with an external drive to match that of those inside. Failing both of those, you're left with USB.
Logged
Farmer
Sr. Member
****
Offline Offline

Posts: 1631


WWW
« Reply #38 on: April 23, 2012, 04:39:24 AM »
ReplyReply

http://www.lian-li.com/v2/en/product/product06.php?pr_index=549&cl_index=12&sc_index=42&ss_index=115&g=f
Logged

dreed
Sr. Member
****
Offline Offline

Posts: 1260


« Reply #39 on: April 23, 2012, 04:53:47 AM »
ReplyReply


Looks great as it ticks all of the important boxes for connecting as a directly attached external storage device.
Logged
Pages: « 1 [2] 3 4 5 »   Top of Page
Print
Jump to:  

Ad
Ad
Ad