Date: Tue, 19 Dec 2017 08:14:18 +0800 From: Erich Dollansky <freebsd.ed.lists@sumeritec.com> To: RW via freebsd-questions <freebsd-questions@freebsd.org> Cc: RW <rwmaillists@googlemail.com> Subject: Re: hd firecuda Message-ID: <20171219081418.5672730b.freebsd.ed.lists@sumeritec.com> In-Reply-To: <20171218162625.5bcc543e@gumby.homeunix.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> <20171218162625.5bcc543e@gumby.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi, On Mon, 18 Dec 2017 16:26:25 +0000 RW via freebsd-questions <freebsd-questions@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@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 in? 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: http://www.tomsitpro.com/articles/shingled-magnetic-recoding-smr-101-basics,2-933.html 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. Erich
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171219081418.5672730b.freebsd.ed.lists>