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: <OF6546148C.B252F592-ON88257395.006383BB-88257395.0063FFA9@us.ibm.com>
Date:	Fri, 16 Nov 2007 10:12:14 -0800
From:	Bryan Henderson <hbryan@...ibm.com>
To:	Jörn Engel <joern@...fs.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Hisashi Hifumi <hifumi.hisashi@....ntt.co.jp>,
	linux-ext4@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH] ext3,4:fdatasync should skip metadata writeout

>fsync() will sync an inode even if only i_atime was changed.
>fdatasync() would ignore such changes.  I guess atime was the major
>reason for creating fdatasync() in the first place.

I think it was mtime.  One doesn't normally call any kind of sync when one 
is just reading the file.  But keeping an accurate mtime is often not 
worth the I/O.

And theoretically, there could be all kinds of "truly meta" metadata that 
changes as you write to the file but would probably be considered more 
expendable than the file's actual data.

But I think it was always intended that fdatasync() would sync the data in 
a meaningful way -- i.e. such that the data can be retrieved after a 
system failure; it surely wasn't meant for the user to understand 
filesystem internals.  I've heard the term "data-related metadata" to 
distinguish such things as allocation maps and pointer blocks from mtime, 
permissions, etc.

--
Bryan Henderson                     IBM Almaden Research Center
San Jose CA                         Filesystems

-
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