Date: Tue, 19 Dec 2017 14:46:06 +0000 From: RW <rwmaillists@googlemail.com> To: freebsd-questions@freebsd.org Subject: Re: hd firecuda Message-ID: <20171219144606.0217ee55@gumby.homeunix.com> In-Reply-To: <20171219081418.5672730b.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> <20171218162625.5bcc543e@gumby.homeunix.com> <20171219081418.5672730b.freebsd.ed.lists@sumeritec.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171219144606.0217ee55>