Re: fsync vs open_sync (more info)
От | pgsql@mohawksoft.com |
---|---|
Тема | Re: fsync vs open_sync (more info) |
Дата | |
Msg-id | 12721.64.119.142.34.1092152169.squirrel@mail.mohawksoft.com обсуждение исходный текст |
Ответ на | fsync vs open_sync (pgsql@mohawksoft.com) |
Список | pgsql-hackers |
> On Tue, 2004-08-10 at 07:48, pgsql@mohawksoft.com wrote: >> Some more information: >> >> I started to perform the tests on one of the machines in my lab, and >> guess >> what, almost no difference between fsync and open_sync. Either on jfs or >> ext2. >> >> The difference, Linux 2.6.3? My original tests where on Linux 2.4.25. > Very hazy memory recalls something about O_SYNC not really doing > anything in early kernel versions. > >> >> The good part is that open_sync wasn't worse. In early Linux kernels, O_SYNC was implemented using fsync(), and there was an amount of debate about people using "O_SYNC" should see performance degradation. >> >> Just a question about conceptually, "What is the right thing to do?" I >> started to think about this. To me, the O_SYNC flag is to ensure that >> what >> you write, at the time of write, is on the disk. In SQL terms it is like >> "auto commit." Calling fsync or fdatasync is so that one can batch write >> calls and flush it out to disk in one shot, conceptually, it is like >> transaction. > With the caveat that the kernel can start flushing your data to disk > in the background, not just when you call fdatasync/fsync. I was speaking in conceptual terms, not exact ones. Just a general analogy. In theory, theory and practice are the same thing, in practice, they are not.
В списке pgsql-hackers по дате отправления: