https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-3451 Lustre <p>When edit a file by emacs or vim and save it, it takes a couple of seconds to close it. This problen is not limited to a specific file, client or OST, and can be reproduced easily at any file or any client. It occurs with root user. There is no error recorded on MDS/OSS/client syslog for it.</p> <p>We traced the process and got Lustre log. According to the strace, it takes seconds while fsync(). And according to Lustre log of client, mdc_sync() waits for seconds until it recieves the reply. But the log on Lustre MDS does not contain any message about mds_sync().</p> <p>We do not find any problem of other metadata operations like file creation or direcotry creation. The simple test 'fsync.c' opens, writes to and then fsync a file but it can not reproduce the problem.</p> Kernel: 2.6.32-220.el6.x86_64<br/> Lustre: 1.8.8 LU-3451

Editor closes file very slow because of fsync()

Bug Major Resolved Not a Bug Peter Jones Li Xi ldiskfs Tue, 11 Jun 2013 11:35:07 +0000 Wed, 7 Aug 2013 04:14:36 +0000 Wed, 7 Aug 2013 04:14:36 +0000 Lustre 1.8.8 0 6 <p>Here are the logs:<br/> <a href="ftp://ftp.whamcloud.com/uploads/LU-3451/MMBK_log_20130605.tar.gz" class="external-link" target="_blank" rel="nofollow noopener">ftp://ftp.whamcloud.com/uploads/LU-3451/MMBK_log_20130605.tar.gz</a><br/> <a href="ftp://ftp.whamcloud.com/uploads/LU-3451/lustre_debug_mds_cl.tar1.gz" class="external-link" target="_blank" rel="nofollow noopener">ftp://ftp.whamcloud.com/uploads/LU-3451/lustre_debug_mds_cl.tar1.gz</a></p> <p>Thanks for your submission Li Xi.</p> <p>Thank you Peter. I would be grateful for any help.</p> <p>Is it slow on every close, or just occasionally?</p> <p>I think occasional slow closes are caused by close on the MDT changing the atime, but getting stuck in the journal transaction commit. There is an old Bugzilla bug for this problem also, but I'm not able to find it (possibly because it is not public?).</p> <p>Hi Andreas,</p> <p>It is slow accasionally, but very frequently. And we found that there are a lot of open/close operations on the system. Is it the cause of the problem?</p> <p>Do you know which direction I should do more research? Or is it too complex to fix it promptly?</p> <p>Thanks!</p> <p>After we collected metadata stats, this performance problem was caused by too many metadata operation with some applications. We found that applications that was doing such metadata operation and stop the job, the system was going to be back normal. So, please close ticket now.</p> <p>ok - thanks Ihara</p> Development Rank 1|hzvt13: Rank (Obsolete) 8631 Severity