On 07/07/2015 10:59 PM, Graeme B. Bell wrote:
Cache flushing isn't an atomic operation though. Even if the ordering
is right, you are likely to have a partial fsync on the disk when the
lights go out - isn't your FS still corrupt?
If the filesystem is worth its salt, no. Journaling filesystems
Cache flushing isn't an atomic operation though. Even if the ordering is right,
you are likely to have a partial fsync on the disk when the lights go out -
isn't your FS still corrupt?
On 07 Jul 2015, at 21:53, Heikki Linnakangas wrote:
> On 07/07/2015 09:01 PM, Wes Vaske (wvaske) wrote:
>
>
On 07/07/2015 09:01 PM, Wes Vaske (wvaske) wrote:
Regarding:
“lie about their fsync status.”
This is mostly semantics but it might help google searches on the issue.
A drive doesn’t support fsync(), that’s a filesystem/kernel process. A drive will do
a FLUSH CACHE. Before kernels 2.6. the fsyn
On Tue, Jul 7, 2015 at 11:46 AM, Graeme B. Bell wrote:
>>
>> RAID controllers are completely unnecessary for SSD as they currently
>> exist.
>
> Agreed. The best solution is not to buy cheap disks and not to buy RAID
> controllers now, imho.
>
> In my own situation, I had a tight budget, high per
erformance@postgresql.org
Subject: Re: [PERFORM] New server: SSD/RAID recommendations?
On Tue, Jul 7, 2015 at 10:59 AM, Heikki Linnakangas
mailto:hlinn...@iki.fi>> wrote:
On 07/07/2015 05:15 PM, Wes Vaske (wvaske) wrote:
The M500/M550/M600 are consumer class drives that don't have pow
On 07 Jul 2015, at 19:47, Scott Marlowe wrote:
>> [I know that using a shingled disk sounds crazy (it sounds crazy to me) but
>> you can bet there are people that just want to max out the disk bays in
>> their server... ]
>
> Let's just say no online backup companies are using those disks. :)
On Tue, Jul 7, 2015 at 11:43 AM, Graeme B. Bell wrote:
>
> The comment on HDDs is true and gave me another thought.
>
> These new 'shingled' HDDs (the 8TB ones) rely on rewriting all the data on
> tracks that overlap your data, any time you change the data. Result: disks
> 8-20x slower during wr
The comment on HDDs is true and gave me another thought.
These new 'shingled' HDDs (the 8TB ones) rely on rewriting all the data on
tracks that overlap your data, any time you change the data. Result: disks
8-20x slower during writes, after they fill up.
Do they have power loss protection fo
On Tue, Jul 7, 2015 at 10:59 AM, Heikki Linnakangas wrote:
> On 07/07/2015 05:15 PM, Wes Vaske (wvaske) wrote:
>
>> The M500/M550/M600 are consumer class drives that don't have power
>> protection for all inflight data.* (like the Samsung 8x0 series and
>> the Intel 3x0 & 5x0 series).
>>
>> The M
> Why would you think that you don't need RAID for ZFS?
>
> Reason I'm asking if because we are moving to ZFS on FreeBSD for our future
> projects.
Because you have zraid. :-)
https://blogs.oracle.com/bonwick/entry/raid_z
General points:
1. It's my understanding that ZFS is designed to talk
After a plug-pull during the create, reboot and here is the verify:
root@Dbms2:/var/tmp # ./diskchecker.pl -s newfs verify /test/biteme
verifying: 0.00%
verifying: 3.81%
verifying: 10.91%
verifying: 18.71%
verifying: 26.46%
verifying: 33.95%
verifying: 41.20%
verifying: 49.48%
verifying:
>
> This raises another interesting question. Does anyone hear have a document
> explaining how their BBU cache works EXACTLY (at cache / sata level) on their
> server? Because I haven't been able to find any for mine (Dell PERC
> H710/H710P). Can anyone tell me with godlike authority and preci
Hi Graeme,
Why would you think that you don't need RAID for ZFS?
Reason I'm asking if because we are moving to ZFS on FreeBSD for our future
projects.
Regards,
Wei Shan
On 8 July 2015 at 00:46, Graeme B. Bell wrote:
> >
> > RAID controllers are completely unnecessary for SSD as they currently
That is a very good question, which I have raised elsewhere on the postgresql
lists previously.
In practice: I have *never* managed to make diskchecker fail with the BBU
enabled in front of the drives and I spent days trying with plug pulls till I
reached the point where as a statistical event
>
> RAID controllers are completely unnecessary for SSD as they currently
> exist.
Agreed. The best solution is not to buy cheap disks and not to buy RAID
controllers now, imho.
In my own situation, I had a tight budget, high performance demand and a newish
machine with RAID controller and HDD
> On 07 Jul 2015, at 16:59, Heikki Linnakangas wrote:
>
>>
>> So it lies about fsync()... The next question is, does it nevertheless
>> enforce the correct ordering of persisting fsync'd data? If you write to
>> file A and fsync it, then write to another file B and fsync it too, is it
>> guaran
Hi.
How would BBU cache help you if it lies about fsync? I suppose any RAID
controller removes data from BBU cache after it was fsynced by the drive.
As I know, there is no other "magic command" for drive to tell controller
that the data is safe now and can be removed from BBU cache.
Вт, 7 лип. 2
Yikes. I would not be able to sleep tonight if it were not for the BBU cache in
front of these disks...
diskchecker.pl consistently reported several examples of corruption
post-power-loss (usually 10 - 30 ) on unprotected M500s/M550s, so I think it's
pretty much open to debate what types of m
x27;s been fsync'd is more important and should
> disqualify *any* consumer drives from *any* company from consideration for
> use with Postgres.
>
> Wes Vaske | Senior Storage Solutions Engineer
> Micron Technology
>
> -Original Message-----
> From: Graem
On 07/07/2015 05:15 PM, Wes Vaske (wvaske) wrote:
The M500/M550/M600 are consumer class drives that don't have power
protection for all inflight data.* (like the Samsung 8x0 series and
the Intel 3x0 & 5x0 series).
The M500DC has full power protection for inflight data and is an
enterprise-class
Storage Solutions Engineer
Micron Technology
-Original Message-
From: Graeme B. Bell [mailto:graeme.b...@nibio.no]
Sent: Tuesday, July 07, 2015 8:26 AM
To: Merlin Moncure
Cc: Wes Vaske (wvaske); Craig James; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] New server: SSD/RAID re
As I have warned elsewhere,
The M500/M550 from $SOME_COMPANY is NOT SUITABLE for postgres unless you have a
RAID controller with BBU to protect yourself.
The M500/M550 are NOT plug-pull safe despite the 'power loss protection'
claimed on the packaging. Not all fsync'd data is preserved in the e
On Thu, Jul 2, 2015 at 1:00 PM, Wes Vaske (wvaske)
wrote:
> Storage Review has a pretty good process and reviewed the M500DC when it
> released last year.
> http://www.storagereview.com/micron_m500dc_enterprise_ssd_review
>
>
>
> The only database-specific info we have available are for Cassandr
Thanks, this is very useful to know about the 730. When you say 'tested it with
plug-pulls', you were using diskchecker.pl, right?
Graeme.
On 07 Jul 2015, at 14:39, Karl Denninger wrote:
>
> Incidentally while there are people who have questioned the 730 series power
> loss protection I've
On 7/7/2015 06:52, Graeme B. Bell wrote:
> Hi Karl,
>
> Great post, thanks.
>
> Though I don't think it's against conventional wisdom to aggregate writes
> into larger blocks rather than rely on 4k performance on ssds :-)
>
> 128kb blocks + compression certainly makes sense. But it might make le
ow you're getting on with your NVMe disk in postgres!
>>
>> Graeme.
>>
>> On 07 Jul 2015, at 12:28, Mkrtchyan, Tigran wrote:
>>
>>> Thanks for the Info.
>>>
>>> So if RAID controllers are not an option, what one should use to bu
Hi Karl,
Great post, thanks.
Though I don't think it's against conventional wisdom to aggregate writes into
larger blocks rather than rely on 4k performance on ssds :-)
128kb blocks + compression certainly makes sense. But it might make less sense
I suppose if you had some incredibly high ra
uot;pgsql-performance"
>> Sent: Tuesday, July 7, 2015 12:38:10 PM
>> Subject: Re: [PERFORM] New server: SSD/RAID recommendations?
>> I am unsure about the performance side but, ZFS is generally very attractive
>> to
>> me.
>>
>> Key advantages:
>>
- Original Message -
> From: "Graeme B. Bell"
> To: "Mkrtchyan, Tigran"
> Cc: "Graeme B. Bell" , "Steve Crawford"
> , "Wes Vaske (wvaske)"
> , "pgsql-performance"
> Sent: Tuesday, July 7, 2015 12:38:10 PM
t;
>> To: "Steve Crawford"
>> Cc: "Wes Vaske (wvaske)" , "pgsql-performance"
>>
>> Sent: Tuesday, July 7, 2015 12:22:00 PM
>> Subject: Re: [PERFORM] New server: SSD/RAID recommendations?
>
>> Completely agree with Steve.
pgsql-performance"
>
> Sent: Tuesday, July 7, 2015 12:22:00 PM
> Subject: Re: [PERFORM] New server: SSD/RAID recommendations?
> Completely agree with Steve.
>
> 1. Intel NVMe looks like the best bet if you have modern enough hardware for
> NVMe. Otherwise e.g. S3700 men
Completely agree with Steve.
1. Intel NVMe looks like the best bet if you have modern enough hardware for
NVMe. Otherwise e.g. S3700 mentioned elsewhere.
2. RAID controllers.
We have e.g. 10-12 of these here and e.g. 25-30 SSDs, among various machines.
This might give people idea about where
On 07/06/2015 09:56 AM, Steve Crawford wrote:
On 07/02/2015 07:01 AM, Wes Vaske (wvaske) wrote:
For what it's worth, in my most recent iteration I decided to go with
the Intel Enterprise NVMe drives and no RAID. My reasoning was thus:
1. Modern SSDs are so fast that even if you had an infini
On 07/02/2015 07:01 AM, Wes Vaske (wvaske) wrote:
What about a RAID controller? Are RAID controllers even available for
PCI-Express SSD drives, or do we have to stick with SATA if we need a
battery-backed RAID controller? Or is software RAID sufficient for SSD
drives?
Quite a few of the ben
@postgresql.org
Subject: Re: [PERFORM] New server: SSD/RAID recommendations?
On Thu, Jul 2, 2015 at 7:01 AM, Wes Vaske (wvaske)
mailto:wva...@micron.com>> wrote:
What about a RAID controller? Are RAID controllers even available for
PCI-Express SSD drives, or do we have to stick with SATA if we
On Wed, Jul 1, 2015 at 4:57 PM, Scott Marlowe
wrote:
> On Wed, Jul 1, 2015 at 5:06 PM, Craig James wrote:
> > We're buying a new server in the near future to replace an aging system.
> I'd
> > appreciate advice on the best SSD devices and RAID controller cards
> > available today.
> >
> SSD
On Wed, Jul 1, 2015 at 4:56 PM, Andreas Joseph Krogh
wrote:
> På torsdag 02. juli 2015 kl. 01:06:57, skrev Craig James <
> cja...@emolecules.com>:
>
> We're buying a new server in the near future to replace an aging system.
> I'd appreciate advice on the best SSD devices and RAID controller cards
.@postgresql.org] *On Behalf Of *Andreas Joseph
> Krogh
> *Sent:* Wednesday, July 01, 2015 6:56 PM
> *To:* pgsql-performance@postgresql.org
> *Subject:* Re: [PERFORM] New server: SSD/RAID recommendations?
>
>
>
> På torsdag 02. juli 2015 kl. 01:06:57, skrev Craig James <
On Wed, Jul 1, 2015 at 6:06 PM, Craig James wrote:
> We're buying a new server in the near future to replace an aging system. I'd
> appreciate advice on the best SSD devices and RAID controller cards
> available today.
>
> The database is about 750 GB. This is a "warehouse" server. We load supplie
...@postgresql.org
[mailto:pgsql-performance-ow...@postgresql.org] On Behalf Of Andreas Joseph
Krogh
Sent: Wednesday, July 01, 2015 6:56 PM
To: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] New server: SSD/RAID recommendations?
På torsdag 02. juli 2015 kl. 01:06:57, skrev Craig James
mailto:cja
On Wed, Jul 1, 2015 at 5:06 PM, Craig James wrote:
> We're buying a new server in the near future to replace an aging system. I'd
> appreciate advice on the best SSD devices and RAID controller cards
> available today.
>
> The database is about 750 GB. This is a "warehouse" server. We load supplie
På torsdag 02. juli 2015 kl. 01:06:57, skrev Craig James mailto:cja...@emolecules.com>>:
We're buying a new server in the near future to replace an aging system. I'd
appreciate advice on the best SSD devices and RAID controller cards available
today.
The database is about 750 GB. This is a "ware
We're buying a new server in the near future to replace an aging system.
I'd appreciate advice on the best SSD devices and RAID controller cards
available today.
The database is about 750 GB. This is a "warehouse" server. We load
supplier catalogs throughout a typical work week, then on the weeken
43 matches
Mail list logo
