hd firecuda

[RW]

On Tue, 19 Dec 2017 08:14:18 +0800
Erich Dollansky wrote:

On Tue, 19 Dec 2017 08:14:18 +0800
Erich Dollansky wrote:

> Hi,
> 
> On Mon, 18 Dec 2017 16:26:25 +0000
> RW via freebsd-questions <freebsd-questions at freebsd.org> wrote:  

> > The details of precisely which sectors are cached is not important
> > (although it is important to recognise that Seagate doesn't care
> > about how these devices perform under FreeBSD). 
> > 
> > What I'm getting at is that previous version of these devices did
> > selective read caching - not write  caching. I don't see any reason
> > to think that this has changed - especially when their marketing
> > isn't mentioning it. 
> > 
> > Even if they are now doing write caching, it's very unlikely that
> > anything like the full 8GB of flash would available for it because
> > you wouldn't want saving a 10GB video file to blow-away the
> > cache.   
> Seagate is very silent about how the FireCuda actually stores data on
> the disk. It uses a technology called SMR.   

...

> The drives can now use a reserved space of the disk to store the data.
> On long writes, this space will also be filled.   

It's unlikely that it would fall back to discarding useful cache in the
SSD *after* filling the larger non-shingled area of the drive. If
that bit of extra buffering made a useful difference they'd just
increase the size of the non-shingled area.

>  It could be also that
> the disk fills first SSD and then the reserved space.  

If that happened I'd expect the speed to first drop to an intermediate
speed of 50-100 MB/s, where the the non-shingled area is being written
to, and then drop again when the non-shingled area fills. 

IMO what you are seeing is consistent with selective read caching plus
write caching into the non-shingled area.