Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 17 Dec 2017 15:00:07 +0000
From:      RW <rwmaillists@googlemail.com>
To:        freebsd-questions@freebsd.org
Subject:   Re: hd firecuda
Message-ID:  <20171217150007.642efc20@gumby.homeunix.com>
In-Reply-To: <20171217194753.3ab59e6d.freebsd.ed.lists@sumeritec.com>
References:  <1513447749.62024.1.camel@yandex.com> <20171217112428.150d8041.freebsd.ed.lists@sumeritec.com> <20171217111319.6a1af590@gumby.homeunix.com> <20171217194753.3ab59e6d.freebsd.ed.lists@sumeritec.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 17 Dec 2017 19:47:53 +0800
Erich Dollansky wrote:


> > My understanding is they weren't intended to work like that. The
> > last I heard was that the SSD was divided into two, one part
> > specifically speeds up booting, and the other part caches sectors
> > where the head had to seek to access a small amount of data.  
> 
> how should a hard disk work? Data is written, data is read.
> 
> How should this SSHD know where by boot-related data is stored? 

It knows when you boot, it knows the sequence of sectors that were
accessed after boot and it can keep statistics about which are
accessed on multiple boots. 

> Why should this disk waste SSD memory for data I need with FreeBSD
> very rarely?

The sole reason that the first generation of these device was developed
was to speed-up the time to boot Windows. 

> It does not seem to me that it is like this. 

It's based on an article written a few of years ago by a development
engineer. Things have probably moved on a bit, boot time is less
important than it was, so they probably cache other frequently read
sectors. 


> It is more likely that it uses the 8GB as a write cache. 


I think it's unlikely that 8GB of cMLC could survive 5 years of writes
to a 2GB hard drive, and if it were designed to work that way I would
expect the specs to have a write endurance limit. 

The article I read said that in stress tests no flash device had failed
before the drive failed mechanically, which suggests that writes were
very carefully controlled.

Seagate's marketing cites faster booting and loading of
applications/games; this relies on reading from persistent cache, not
write caching. 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171217150007.642efc20>