fsync = true对ext3有用吗？ [英] fsync = true beneficial on ext3?
问题描述
我很好奇在使用postgresql 7.3.4或更高版本的ext3
文件系统上使用fsync时的共识是什么（如果有的话）。我做了一些最近的性能
测试表明，在一个特定的系统上，fsync关闭时，简单插件的性能提升了45％-70％
。 fsync = true会给我带来任何额外的可恢复性吗？
如果我们写一些没有同步的东西，大概就是'立即
日记？因此，即使数据库在fsync'之前崩溃，我们是否完全可以恢复？b $ b可以恢复？我在ext3上运行了几个pgsql集群，fsync =
false，遭遇了大量的操作系统崩溃，并且还没有丢失任何数据或者看到
来自任何这些崩溃。我是否幸运？
TIA。
Ed
--------- ------------------（广播结束）---------------------------
提示1：订阅和取消订阅命令转到 ma*******@postgresql.org
I''m curious what the consensus is, if any, on use of fsync on ext3
filesystems with postgresql 7.3.4 or later. I did some recent performance
tests demonstrating a 45%-70% performance improvement for simple inserts
with fsync off on one particular system. Does fsync = true buy me any
additional recoverability beyond ext3''s journal recovery?
If we write something without sync''ing, presumably it''s immediately
journaled? So even if the DB crashes prior to fsync''ing, are we fully
recoverable? I''ve been running a few pgsql clusters on ext3 with fsync =
false, suffered numerous OS crashes, and have yet to lose any data or see
any corruption from any of those crashes. Have I just been lucky?
TIA.
Ed
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org
推荐答案
" Ed L." < PG *** @ bluepolka.net>写道：
"Ed L." <pg***@bluepolka.net> writes:
如果我们写一些没有同步的东西，可能是它立即被记录了？
我的印象是ext3期刊只有文件系统元数据，
不是文件内容。
我已经在ext3上运行了几个pgsql集群，fsync =
false，遭遇了大量的操作系统崩溃，并且还没有丢失任何数据或者看到任何来自这些崩溃的任何损坏。我刚刚幸运吗？
If we write something without sync''ing, presumably it''s immediately
journaled?
I was under the impression that ext3 journals only filesystem metadata,
not the contents of files.
I''ve been running a few pgsql clusters on ext3 with fsync =
false, suffered numerous OS crashes, and have yet to lose any data or see
any corruption from any of those crashes. Have I just been lucky?
听起来对我来说听起来不太安全。
问候，tom lane
---------------------------（广播结束）-------- -------------------
提示2：您可以使用取消注册命令立即取消所有列表
（发送取消注册YourEmailAddressHere到 ma*******@postgresql.org ）
Doesn''t sound very safe to me.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)
On Sun，2004年2月8日14:02:26 -0500 Tom Lane< tg *@sss.pgh.pa.us>写道：
On Sun, 08 Feb 2004 14:02:26 -0500 Tom Lane <tg*@sss.pgh.pa.us> wrote:
" Ed L." < PG *** @ bluepolka.net>写道：
"Ed L." <pg***@bluepolka.net> writes:
如果我们写一些没有同步的东西，可能是它立即被记录了？
If we write something without sync''ing, presumably it''s immediately
journaled?
我的印象是ext3期刊只有文件系统元数据，
不是文件的内容。
I was under the impression that ext3 journals only filesystem metadata,
not the contents of files.
默认情况下，它记录所有内容，但您可以将其设置为日记元数据
，我认为使用mount选项data = writeback。做一个man mount
并查找ext3选项以获取有关data =选项的详细信息。
richard
- -
Richard Welty rw****@averillpark.net
Averill Park Networking 518-573-7592
Java，PHP，PostgreSQL，Unix，Linux，IP网络工程，安全
----------- ----------------（广播结束）---------------------------
提示8：解释分析是你的朋友
by default, it journals everything, but you can set it to journal metadata
only, i think with the mount option data=writeback. do a "man mount"
and look for ext3 options for details on the data= option.
richard
--
Richard Welty rw****@averillpark.net
Averill Park Networking 518-573-7592
Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend
2004年2月8日星期日12:02，Tom Lane写道：
On Sunday February 8 2004 12:02, Tom Lane wrote:
Ed L. < PG *** @ bluepolka.net>写道：
"Ed L." <pg***@bluepolka.net> writes:
如果我们写一些没有同步的东西，大概是它立刻被记录了？
If we write something without sync''ing, presumably it''s immediately
journaled?
我的印象是ext3期刊只有文件系统元数据，而不是文件的内容。
I was under the impression that ext3 journals only filesystem metadata,
not the contents of files.
啊，我不知道这是怎么回事。所以我认为在保证数据方面确实没有内核级替代fsync = true
在提交时被刷新到磁盘，我想？ />
在linux中，pgsql在提交时的fsync调用是否可以避免需要对bxflush进行特定数据的刷新？我想知道是否
有bdflush调整来提高磁盘写入效率
我们可以依靠fsync = true来保证这一点。
另外，使用fdat = true和wal使用fdatasync，并假设所有的都在
相同的磁盘上（我知道这不是最佳的），是否有特定的ext3模式
（data = writeback？）可以提供更好的性能，同时保持最佳的b $ b可恢复性？
----------- ----------------（广播结束）---------------------------
提示4：不要杀死-9''邮政局长
Ah, didn''t know how that worked. So I gather there is really no
kernel-level substitute for fsync = true when it comes to guaranteeing data
is flushed to disk at commit time, I guess?
In linux, does pgsql''s fsync call at commit time obviate the need for
bdflush to do any flushing for that particular data? I''m wondering if
there are bdflush adjustments to be made to improve disk write efficiency
given we can count on fsync = true to guarantee that .
Also, with fsync = true and wal using fdatasync, and assuming all is on the
same disk (which I know is not optimal), is there a particular ext3 mode
(data=writeback?) that gives better performance while maintaining best
recoverability?
---------------------------(end of broadcast)---------------------------
TIP 4: Don''t ''kill -9'' the postmaster
这篇关于fsync = true对ext3有用吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
