Re: test_fsync label adjustments
От | A.M. |
---|---|
Тема | Re: test_fsync label adjustments |
Дата | |
Msg-id | 9371B30F-B427-4C11-94B0-FF074A4CE4B4@themactionfaction.com обсуждение исходный текст |
Ответ на | Re: test_fsync label adjustments (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: test_fsync label adjustments
|
Список | pgsql-hackers |
On Jan 18, 2011, at 5:41 PM, Bruce Momjian wrote: > A.M. wrote: >>>> Because the fastest option may not be syncing to disk. For example, >>>> the only option that makes sense on OS X is fsync_writethrough- it >>>> would be helpful if the tool pointed that out (on OS X only, obviously). >>> >>> Yes, that would be a serious problem. :-( >>> >>> I am not sure how we would address this --- your point is a good one. >> >> One general idea I had would be to offer some heuristics such as "this >> sync rate is comparable to that of one SATA drive" or "comparable to >> RAID 10 with X drives" or "this rate is likely too fast to be actually >> be syncing". But then you are stuck with making sure that the heuristics >> are kept up-to-date, which would be annoying. > > That fails for RAID BBUs. Well, it's nothing more than a heuristic- it is still nice to know whether or not the fancy hardware RAID I just setup issimilar to Josh Berkus' RAID setup or a single SATA drive (which would hint at a misconfiguration). As you said, perhapsa wiki is better for this. But a wiki won't integrate with this tool, which I why I would hesitate to point novicesto this tool... should the tool point to the wiki? > >> Otherwise, the only option I see is to detect the kernel and compare >> against a list of known problematic methods. Perhaps it would be easier >> to compare against a whitelist. Also, the tool would likely need to >> parse "mount" output to account for problems with specific filesystems. >> >> I am just throwing around some ideas... > > That sounds pretty complicated. One idea would be the creation of a > wiki where people could post their results, or ideally a tool that could > read the output and load it into a database for analysis with other > results. The OS X example is pretty cut-and-dry- it would be nice if there were some kind of hints in the tool pointing in the rightdirection, or at least a few words of warning: "the fastest option may not be the safest- read the docs". Cheers, M
В списке pgsql-hackers по дате отправления: