freebsd.ed.lists at sumeritec.com
Tue Dec 19 00:15:14 UTC 2017
On Mon, 18 Dec 2017 16:26:25 +0000
RW via freebsd-questions <freebsd-questions at freebsd.org> wrote:
> 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 at 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.
Seagate is very silent about how the FireCuda actually stores data on
the disk. It uses a technology called SMR. This results in a higher
track density but direct writes are impossible. A short term solution
is reading all data of a set of tracks into RAM, changing the data there
and write it all out. But what will you do when new data keeps flooding
The drives can now use a reserved space of the disk to store the data.
On long writes, this space will also be filled. The drives uses then the
SSD part as a write cache in my observation. It could be also that
the disk fills first SSD and then the reserved space. The drives keep a
high write speed until a certain transfer volume is reached. The drives
then take a deep breath - maybe they try to write the data stored in
the SSD to disk - and then continue with around 15MB/s
You can read about SMR here:
It looks to me that the SSD part is used as a write cache depending on
the transfer volume. I also noticed that the current version of the
data sheet does not have a transfer volume specified anymore.
Anyway, will not find it out as Seagate keeps very quiet about it.
More information about the freebsd-questions