Cc: ceph-devel@vger.kernel.org; sj...@redhat.com
Subject: Re: FileStore should not use syncfs(2)
On 08/05/2015 04:26 PM, Sage Weil wrote:
Today I learned that syncfs(2) does an O(n) search of the superblock's
inode list searching for dirty items. I've always assumed that it was
only
On Thu, Aug 6, 2015 at 5:26 AM, Sage Weil sw...@redhat.com wrote:
Today I learned that syncfs(2) does an O(n) search of the superblock's
inode list searching for dirty items. I've always assumed that it was
only traversing dirty inodes (e.g., a list of dirty inodes), but that
appears not to
On Wed, Aug 05, 2015 at 02:26:30PM -0700, Sage Weil wrote:
Today I learned that syncfs(2) does an O(n) search of the superblock's
inode list searching for dirty items. I've always assumed that it was
only traversing dirty inodes (e.g., a list of dirty inodes), but that
appears not to be
On Thu, 6 Aug 2015, Haomai Wang wrote:
Agree
On Thu, Aug 6, 2015 at 5:38 AM, Somnath Roy somnath@sandisk.com wrote:
Thanks Sage for digging down..I was suspecting something similar.. As I
mentioned in today's call, in idle time also syncfs is taking ~60ms. I have
64 GB of RAM in
On Thu, 6 Aug 2015, Christoph Hellwig wrote:
On Wed, Aug 05, 2015 at 02:26:30PM -0700, Sage Weil wrote:
Today I learned that syncfs(2) does an O(n) search of the superblock's
inode list searching for dirty items. I've always assumed that it was
only traversing dirty inodes (e.g., a list
On Thu, 6 Aug 2015, Yan, Zheng wrote:
On Thu, Aug 6, 2015 at 5:26 AM, Sage Weil sw...@redhat.com wrote:
Today I learned that syncfs(2) does an O(n) search of the superblock's
inode list searching for dirty items. I've always assumed that it was
only traversing dirty inodes (e.g., a list of
On Thu, Aug 06, 2015 at 06:00:42AM -0700, Sage Weil wrote:
I'm guessing the strategy here should be to fsync the file (leaf) and then
any affected ancestors, such that the directory fsyncs are effectively
no-ops? Or does it matter?
All metadata transactions log the involve parties (parent
Thanks Sage for digging down..I was suspecting something similar.. As I
mentioned in today's call, in idle time also syncfs is taking ~60ms. I have 64
GB of RAM in the system.
The workaround I was talking about today is working pretty good so far. In
this implementation, I am not giving much
On 08/05/2015 04:26 PM, Sage Weil wrote:
Today I learned that syncfs(2) does an O(n) search of the superblock's
inode list searching for dirty items. I've always assumed that it was
only traversing dirty inodes (e.g., a list of dirty inodes), but that
appears not to be the case, even on the
Agree
On Thu, Aug 6, 2015 at 5:38 AM, Somnath Roy somnath@sandisk.com wrote:
Thanks Sage for digging down..I was suspecting something similar.. As I
mentioned in today's call, in idle time also syncfs is taking ~60ms. I have
64 GB of RAM in the system.
The workaround I was talking about
10 matches
Mail list logo
