lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <37C3E508-AE2F-4FA5-9536-7F59B26CBBAC@sun.com>
Date:	Fri, 26 Mar 2010 13:24:58 -0600
From:	Andreas Dilger <adilger@....com>
To:	Surbhi Palande <surbhi.palande@...onical.com>
Cc:	linux-ext4@...r.kernel.org, Stephen Tweedie <sct@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ext3: call blkdev_issue_flush on fsync

On 2010-03-26, at 10:50, Surbhi Palande wrote:
> To ensure that bits are truly on-disk after an fsync,
> we should call blkdev_issue_flush if barriers are supported.
>
> @@ -87,5 +89,7 @@ int ext3_sync_file(struct file * file, struct  
> dentry *dentry, int datasync)
> 		ret = sync_inode(inode, &wbc);
> 	}
> out:
> +	if (journal && (journal->j_flags & JFS_BARRIER))
> +		blkdev_issue_flush(inode->i_sb->s_bdev, NULL);
> 	return ret;


I don't think we need yet ANOTHER barrier here.  If the filesystem is  
mounted in data={journaled,ordered} mode it will have flushed the data  
to disk as part of the journal commit.  If there is an external  
journal, there were patches posted to have it flush the data on the  
filesystem device at transaction commit time.

Since fsync on any inode always implies sync of the journal, the only  
time that this would be needed is if we are running in no-journal  
mode, or possibly in data=writeback mode.

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ