linux-ext4 - Re: [ext3] Changes to block device after an ext3 mount point has been remounted readonly

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]

Date:	Mon, 22 Feb 2010 23:32:52 +0100
From:	Jan Kara <jack@...e.cz>
To:	Camille Moncelier <pix@...life.org>
Cc:	linux-fsdevel@...r.kernel.org, Andreas Dilger <adilger@....com>,
	ext4 development <linux-ext4@...r.kernel.org>
Subject: Re: [ext3] Changes to block device after an ext3 mount point has
	been remounted readonly

> On Thu, Feb 18, 2010 at 10:41 PM, Andreas Dilger <adilger@....com> wrote:
> 
> > Are you sure this isn't because e2fsck has been run at boot time and changed
> > e.g. the "last checked" timestamp in the superblock?
> >
> No, I replaced /sbin/init by something which compute the sha1sum of
> the root partition, display it then call /sbin/init and I can see that
> the hash has changed after mount -o remount,ro.
> 
> As little as I understand, I managed to make a diff between two
> hexdump of small images where changes happened after I created a file
> and remounted the fs ro and it seems that, the driver didn't wrote
> changes to the disk until unmount  ( The hexdump clearly shows that
> /lost+found and /test file has been written after the umount )
> 
> workaround: Is there some knob in /proc or /sys which can trigger all
> pending changes to disk ? ( Like /proc/sys/vm/drop_caches but for
> filesystems ? )
  I've looked at your script. The problem is that "echo s >/proc/sysrq_trigger"
isn't really a data integrity operation. In particular it does not wait on
IO to finish (with the new writeback code it does not even wait for IO to be
submitted) so you sometimes take the image checksum before the sync actually
happens. If you used sync(1) instead, everything should work as expected...

								Honza
-- 
Jan Kara <jack@...e.cz>
SuSE CR Labs
--
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