xfs
[Top] [All Lists]

Re: XFS information leak during crash

To: mikulas@xxxxxxxxxxxxxxxxxxxxxxxx
Subject: Re: XFS information leak during crash
From: Glen Overby <overby@xxxxxxx>
Date: Wed, 2 Nov 2005 18:41:56 -0600 (CST)
Cc: nathans@xxxxxxx, linux-kernel@xxxxxxxxxxxxxxx, linux-xfs@xxxxxxxxxxx
In-reply-to: message from Mikulas Patocka sent 3 November 2005
References: <20051102212722.GC6759@fi.muni.cz> <20051103101107.O6239737@wobbly.melbourne.sgi.com> <Pine.LNX.4.62.0511030116160.2023@artax.karlin.mff.cuni.cz>
Sender: linux-xfs-bounce@xxxxxxxxxxx
On November 3, Mikulas Patocka wrote:
> BTW. Why does it sometimes overwrite files with zeros after crash and 
> journal replay then? I thought that this was because it tries to avoid 
> users seeing uninitialized data.

It doesn't overwrite the file with zeros.  You're getting an inode
that has a non-zero size, but no data in the file.  That is, a file
that is a single hole.  This happens because XFS logs metadata
quickly, but the data in the file gets written more slowly.

You'll see the same zeroing if you create a sparse file: write a
megabyte of data, lseek forward a megabyte, and write another megabyte
of data.  When reading the area you lseeked over, it will read as
zeros.

The same is done for files that were preallocated, but haven't been
written to (that is, the file has unwritten extents).

You can look at the files in question with xfs_bmap -v and see that
there's no extents there.

Glen Overby


<Prev in Thread] Current Thread [Next in Thread>