Re: New server: SSD/RAID recommendations?
| От | Wes Vaske (wvaske) |
|---|---|
| Тема | Re: New server: SSD/RAID recommendations? |
| Дата | |
| Msg-id | 31701C89A44B714FB8D242F806E7286C5AED3892@NTXBOIMBX01.micron.com обсуждение исходный текст |
| Ответ на | Re: New server: SSD/RAID recommendations? (Michael Nolan <htfoot@gmail.com>) |
| Ответы |
Re: New server: SSD/RAID recommendations?
|
| Список | pgsql-performance |
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.<low numbers> the fsync() call wouldn’t sent any ATA or SCSI command to flush the disk cache. Whereas—AFAICT—modern kernels and file system versions *will* do this. When ‘sync’ is called the filesystem will issue the appropriate command to the disk to flush the write cache.
For ATA, this is “FLUSH CACHE” (E7h). To check support for the command use:
[root@postgres ~]# smartctl --identify /dev/sdu | grep "FLUSH CACHE"
83 13 1 FLUSH CACHE EXT supported
83 12 1 FLUSH CACHE supported
86 13 1 FLUSH CACHE EXT supported
86 12 1 FLUSH CACHE supported
The 1s in the 3rd column represent SUPPORTED for the feature listed in the last column.
Cheers,
Wes Vaske
From: pgsql-performance-owner@postgresql.org [mailto:pgsql-performance-owner@postgresql.org] On Behalf Of Michael Nolan
Sent: Tuesday, July 07, 2015 12:28 PM
To: hlinnaka@iki.fi
Cc: Wes Vaske (wvaske); Graeme B. Bell; pgsql-performance@postgresql.org
Subject: Re: [PERFORM] New server: SSD/RAID recommendations?
On Tue, Jul 7, 2015 at 10:59 AM, Heikki Linnakangas <hlinnaka@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 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 drive (like the Samsung 845DC or Intel S3500 & S3700
series).
So any drive without the capacitors to protect inflight data will
suffer from data loss if you're using disk write cache and you pull
the power.
Wow, I would be pretty angry if I installed a SSD in my desktop, and it loses a file that I saved just before pulling the power plug.
That can (and does) happen with spinning disks, too.
*Big addendum: There are two issues on powerloss that will mess with
Postgres. Data Loss and Data Corruption. The micron consumer drives
will have power loss protection against Data Corruption and the
enterprise drive will have power loss protection against BOTH.
https://www.micron.com/~/media/documents/products/white-paper/wp_ssd_power_loss_protection.pdf
The Data Corruption problem is only an issue in non-SLC NAND but
it's industry wide. And even though some drives will protect against
that, the protection of inflight data that's been fsync'd is more
important and should disqualify *any* consumer drives from *any*
company from consideration for use with Postgres.
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 guaranteed that if B is persisted, A is as well? Because if it isn't, you can end up with filesystem (or database) corruption anyway.
- Heikki
The sad fact is that MANY drives (ssd as well as spinning) lie about their fsync status.
--
Mike Nolan
В списке pgsql-performance по дате отправления: