Re: We really ought to do something about O_DIRECT and data=journalled on ext4
От | Tom Lane |
---|---|
Тема | Re: We really ought to do something about O_DIRECT and data=journalled on ext4 |
Дата | |
Msg-id | 19015.1291226945@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: We really ought to do something about O_DIRECT and data=journalled on ext4 (Josh Berkus <josh@agliodbs.com>) |
Ответы |
Re: We really ought to do something about O_DIRECT and
data=journalled on ext4
Re: We really ought to do something about O_DIRECT and data=journalled on ext4 Re: We really ought to do something about O_DIRECT and data=journalled on ext4 |
Список | pgsql-hackers |
Josh Berkus <josh@agliodbs.com> writes: > It's a bug and it's our bug. No, it's a filesystem bug that this particular filesystem doesn't support a perfectly reasonable combination of options, and doesn't even fail gracefully as it could easily do. But assigning blame doesn't help much. > Back when we added O_DIRECT, we assumed > that support for O_DIRECT/opensync could be determined on an OS/kernel > basis, because that was the information we had. Now it turns out that > support can vary *by filesystem* and *between remounts*. We didn't have > any way of knowing different back in 2004, but that doesn't mean we > don't need to fix our mistaken assumption now. > Ideally, we would change our code to test support for O_DIRECT on > startup, rather than at compile time, and backport *that*. I'm not convinced that a startup-time test would be enough either, since as you note a remount might be enough to change the situation. I think the best answer is to get out of the business of using O_DIRECT by default, especially seeing that available evidence suggests it might not be a performance win anyway. regards, tom lane
В списке pgsql-hackers по дате отправления: