Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 52381B5DBD8 for ; Tue, 19 Jul 2011 11:29:55 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 92539-06 for ; Tue, 19 Jul 2011 14:29:49 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mail.postgresql.org (Postfix) with ESMTP id 35482B5D944 for ; Tue, 19 Jul 2011 11:29:49 -0300 (ADT) Received: from [192.168.1.3] (mail.highperformancepostgresql.com [71.179.240.8]) by mrelayeu.kundenserver.de (node=mreu1) with ESMTP (Nemesis) id 0MfV79-1R7iYz1G0Z-00P2Gp; Tue, 19 Jul 2011 16:29:47 +0200 Message-ID: <4E2594D7.7000001@2ndquadrant.com> Date: Tue, 19 Jul 2011 10:29:43 -0400 From: Greg Smith User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 To: Yeb Havinga CC: Florian Weimer , Andy , pgsql-performance@postgresql.org Subject: Re: BBU still needed with SSD? References: <1310953399.25726.YahooMailClassic@web111304.mail.gq1.yahoo.com> <4E23E72B.2070508@gmail.com> <82vcuyd7p5.fsf@mid.bfk.de> <4E255DF9.20005@gmail.com> <82y5zubl90.fsf@mid.bfk.de> <4E2569B0.2050307@gmail.com> <82livubix4.fsf@mid.bfk.de> <4E257587.3040704@gmail.com> In-Reply-To: <4E257587.3040704@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:nKHdpkWJ/nsX8xHyhTJY1d/GsgrZDa0PZawYmikUkZf AD9IESsGpVFVsINkXdH/RgtGTfgjDkvnjuQj6s5dlHWfk/69ZF ZtoR/2q/hzQzHvlq06iIjbi1mYdPFlYRdg5NPW1oi7jJb9jZzk o8qE40A3Q960pWl5C72wdH5KuNrJezmnOVfzDeSlCPspcji/fj zHP4fVLNuBG3FZUZHKC0GyXK6/iMrrGHH+D1nIB5OY= X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201107/195 X-Sequence-Number: 44407 Yeb Havinga wrote: > So for the Intels it's probably also lifetime writes in GB but you'd > have to check with an Intel smart values reader to be absolutely sure. With my 320 series drive, the LBA units are pretty clearly 32MB each. Watch this: root@toy:/ssd/data# smartctl --version smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build) ... root@toy:/ssd/data# du -skh pg_xlog/ 4.2G pg_xlog/ root@toy:/ssd/data# smartctl -a /dev/sdg1 | grep LBAs 241 Total_LBAs_Written 0x0032 100 100 000 Old_age Always - 18128 242 Total_LBAs_Read 0x0032 100 100 000 Old_age Always - 10375 root@toy:/ssd/data# cat pg_xlog/* > /dev/null root@toy:/ssd/data# smartctl -a /dev/sdg1 | grep LBAs 241 Total_LBAs_Written 0x0032 100 100 000 Old_age Always - 18128 242 Total_LBAs_Read 0x0032 100 100 000 Old_age Always - 10508 That's an increase of 133 after reading 4.2GB of data, which means makes each LBA turn out to be 32MB in size. Let's try to confirm that by doing a write: root@toy:/ssd/gsmith# smartctl -a /dev/sdg1 | grep LBAs 241 Total_LBAs_Written 0x0032 100 100 000 Old_age Always - 18159 242 Total_LBAs_Read 0x0032 100 100 000 Old_age Always - 10508 root@toy:/ssd/gsmith# dd if=/dev/zero of=test_file.0 bs=32M count=25 && sync 25+0 records in 25+0 records out 838860800 bytes (839 MB) copied, 5.95257 s, 141 MB/s root@toy:/ssd/gsmith# smartctl -a /dev/sdg1 | grep LBAs 241 Total_LBAs_Written 0x0032 100 100 000 Old_age Always - 18184 242 Total_LBAs_Read 0x0032 100 100 000 Old_age Always - 10508 18184 - 18159 = 25; exactly the count I used in 32MB blocks. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD