Date: Mon, 18 Dec 2017 08:52:19 +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: <20171218085219.2fec7c3b.freebsd.ed.lists@sumeritec.com> In-Reply-To: <20171217150007.642efc20@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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. > > > Why should this disk waste SSD memory for data I need with FreeBSD > > very rarely? > > The sole reason that the first generation of these device was > developed was to speed-up the time to boot Windows. Yes, and gaming consoles. It seems that the caching algorithm is really optimised for this > > > It does not seem to me that it is like this. > > It's based on an article written a few of years ago by a development > engineer. Things have probably moved on a bit, boot time is less > important than it was, so they probably cache other frequently read > sectors. When I work on a project smaller than 8GB, this disk is fast, real fast. The problem is that the SSD part gets completely wracked when I compile kernel and then the ports I have installed. It might be the case that six months are not enough for the disk to understand to leave these things out of the SSD part. > > > > It is more likely that it uses the 8GB as a write cache. > > > I think it's unlikely that 8GB of cMLC could survive 5 years of writes > to a 2GB hard drive, and if it were designed to work that way I would > expect the specs to have a write endurance limit. > The disk has a limit. The trick on the data sheet is also that Seagate does not specify a life-time for the SSD part itself. It seems Seagate will just replace the disk until five years are over. > The article I read said that in stress tests no flash device had > failed before the drive failed mechanically, which suggests that > writes were very carefully controlled. When you work on a project, data are read and written. So make use of the SSD for the next read operation, the written data has to be also written to the SSD part. > > Seagate's marketing cites faster booting and loading of > applications/games; this relies on reading from persistent cache, not > write caching. Yes. This might works for Windows but not for FreeBSD. Every time a kernel and the world are compiled, the SSD has to be trashed. The same is true when updating the ports tree. In my observation, my first FireCuda did not understand within six months what is program and will be used more often as I update too often. I have not decided for myself to keep this disk for work or use it for backup. Erich
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171218085219.2fec7c3b.freebsd.ed.lists>