Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 18 Dec 2017 16:26:25 +0000
From:      RW <rwmaillists@googlemail.com>
To:        freebsd-questions@freebsd.org
Subject:   Re: hd firecuda
Message-ID:  <20171218162625.5bcc543e@gumby.homeunix.com>
In-Reply-To: <20171218085219.2fec7c3b.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> <20171217150007.642efc20@gumby.homeunix.com> <20171218085219.2fec7c3b.freebsd.ed.lists@sumeritec.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 18 Dec 2017 08:52:19 +0800
Erich Dollansky wrote:

> Hi,
> 
> On Sun, 17 Dec 2017 15:00:07 +0000
> RW via freebsd-questions <freebsd-questions@freebsd.org> wrote:
> 
> > 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.   
> 
> how often do you boot your FreeBSD machine before installing a new
> kernel? If I boot a machine five times before installing a new kernel,
> the number is high.



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.   



  



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