From owner-freebsd-questions@freebsd.org Tue Dec 19 00:15:14 2017 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0E702E94E66 for ; Tue, 19 Dec 2017 00:15:14 +0000 (UTC) (envelope-from freebsd.ed.lists@sumeritec.com) Received: from mx42-out4.antispamcloud.com (mx42-out4.antispamcloud.com [138.201.61.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AC66078848 for ; Tue, 19 Dec 2017 00:15:12 +0000 (UTC) (envelope-from freebsd.ed.lists@sumeritec.com) Received: from [153.92.8.106] (helo=srv31.niagahoster.com) by mx6.antispamcloud.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eR5Yq-0007FG-1V; Tue, 19 Dec 2017 01:15:09 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sumeritec.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Z0GO5yZ7SIsLM+NCL6kE2Ig8nQ420NNq9JYME2u9bUs=; b=qiqqwDiZ5u2kWFozpUorMnfJRT IJUE5TqkhFUOq/0H+7kLTQXhQ7Zq5BrEOpHkFZr9ZRBuAwX9u8JMYgDImSh8+maI9SR6vx6jHVMkh aJ8Gyk/6y8B08z3BixbvTMQXxC/mWkWYd1gphUfHFSJ1PaDrSmg1mGJ+98FrCzWlmodYYLD3bNGnh YazRY6JcZ9K749QzVL/Wz0kzfCjUX4Q36fE9hJsTNSi9rP9LCaBYZ/8hVLAdzFp6l027sJOcmoE0u MFOsACJdf8S43paQ9aMtrUvraPdP7McO9kkD6LcLiSuuSNtt4lr7ZDkb9EXFM6sGBrwihsbGtit4+ mxUk5y1w==; Received: from [114.125.69.183] (port=19502 helo=X220.sumeritec.com) by srv31.niagahoster.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eR5Y5-0000bM-09; Tue, 19 Dec 2017 07:14:21 +0700 Date: Tue, 19 Dec 2017 08:14:18 +0800 From: Erich Dollansky To: RW via freebsd-questions Cc: RW 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> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AuthUser: freebsd.ed.lists@sumeritec.com X-Originating-IP: 153.92.8.106 X-AntiSpamCloud-Domain: out.niagahoster.com X-AntiSpamCloud-Username: niaga Authentication-Results: antispamcloud.com; auth=pass (login) smtp.auth=niaga@out.niagahoster.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.22) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5sNfJrniNOahTX1nd9ng1QDj1g3/PwYZaTCzSym8uE9HvyegFAN3MVG+ 8Mu8M+ESLE+fzSH/OCabdgYrKxSFlmz0WCHdVL2O4JcuP9paLbvfuso5dtSdoXAUjjzTYPx/gefH zJ6mVE7ewsipSVIfs4YuRlP/jKGz9SMlk+pI4GKD4JjiDSrbcmJ1QXhuh4fWdhzVbG/CVUn5REsZ 3CrjMGEhEWyJzIkwSFAW0Pw8uiKe14ngzVsz7019I2tmW3YF86PBphix6rk/5xxWln4AvZltui3/ twGGymTQ9M9nInMiBoXyGXjGdVgfBZmYS7ZpB6O5TPqzGal/PlyCuaPMa+bDhSDwOaK4Wi1ekn/R KJ5v/GvqX3R1xq5AWRLKWJ/8M9OeOTSfoIBIa+iKhc8s+nGL+8LUGUdqDrPZ3aG8sVuyrcJVKk1J 0UdB/2NbTS6jAye18MkVkPDU4C/+kA7pihpZV3dtOujd0u9IxxpxaVgxjgfwGgrYhdwYhTRuciSX R9K7q2rWRu2bEDBrn9XCvqoBIkUL/j1Y48GvmeURQjjEwiLQvYmDWqg4h9lm6q5KHuPS+ou/4rRJ AGavNe79jObUnL7cHjHrU1Uwrx3kMoqQAH8WgFEDFV0anqG3QLhcBU4ypizDIoSI9NimOXTdLw7T PpuFqUUQz+mM8JAD4ECWfSiw4hQSSuVtgqBJ7QGUR0ZPakfwMy7OJBElXjLSJzDczDv+ct0JxRwc HDf4uxZsXovHDHmYbuSUgTtSXjeZ1NBj9qFTqW29+hVgN//VZRvJS7aysAufYrbzjGyYaYbJpRwN epoydEtjer9eettxrv1TduFgZxSMBhgPu8KHqEXRf2BFJSOt9mPgLKpjcST0ZJ0Q4x+0GOxZvoEN DONKwcABRoKlYnOoj/Sdd/c8yLR5T2Cy09huISk1GIHBjqQv7pMUGEd7KUcuVEcOwnlEQQ== X-Report-Abuse-To: spam@quarantine1.antispamcloud.com X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Dec 2017 00:15:14 -0000 Hi, On Mon, 18 Dec 2017 16:26:25 +0000 RW via freebsd-questions 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 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