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  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:   Thu, 16 Jan 2020 11:16:12 +0100
From:   Christoph Hellwig <>
To:     Andreas Dilger <>
Cc:     David Howells <>,
        Christoph Hellwig <>,
        Qu Wenruo <>,
        linux-fsdevel <>,
        Al Viro <>,
        "Theodore Y. Ts'o" <>,
        "Darrick J. Wong" <>,
        Chris Mason <>, Josef Bacik <>,
        David Sterba <>,
        linux-ext4 <>,
        linux-xfs <>,
        linux-btrfs <>,
        Linux Kernel Mailing List <>
Subject: Re: Problems with determining data presence by examining extents?

On Wed, Jan 15, 2020 at 12:48:44PM -0700, Andreas Dilger wrote:
> I don't think either of those will be any better than FIEMAP, if the reason
> is that the underlying filesystem is filling in holes with actual data
> blocks to optimize the IO pattern.  SEEK_HOLE would not find a hole in
> the block allocation, and would happily return the block of zeroes to
> the caller.  Also, it isn't clear if SEEK_HOLE considers an allocated but
> unwritten extent to be a hole or a block?

It is supposed to treat unwritten extents that are not dirty as holes.
Note that fiemap can't even track the dirty state, so it will always give
you the wrong answer in some cases.  And that is by design given that it
is a debug tool to give you the file system extent layout and can't be
used for data integrity purposes.

Powered by blists - more mailing lists