Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 6 Mar 2013 10:52:05 +0400
From:      Lev Serebryakov <lev@FreeBSD.org>
To:        Don Lewis <truckman@FreeBSD.org>
Cc:        mckusick@mckusick.com, freebsd-fs@FreeBSD.org
Subject:   Re: Panic in ffs_valloc (Was: Unexpected SU+J inconsistency AGAIN -- please, don't shift topic to ZFS!)
Message-ID:  <958644234.20130306105205@serebryakov.spb.ru>
In-Reply-To: <201303060643.r266hBWU015053@gw.catspoiler.org>
References:  <1352492388.20130302002244@serebryakov.spb.ru> <201303060643.r266hBWU015053@gw.catspoiler.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Hello, Don.
You wrote 6 =DC=D0=E0=E2=D0 2013 =D3., 10:43:11:

DL> When growing a file, the data *must* be written before writing the block
DL> pointer that points to it.  If this ordering isn't obeyed, then a system
DL> crash that occurs between the block pointer write and the data write
DL> would result in the file containing whatever garbage was in the data
DL> block.  That garbage could be the confidential contents of some other
DL> user's previously deleted file.
 It  is why confidential data should be zeored-out before file deletion
 :)
  But here is another way: add "stream id" for all writes. FS could
 mark each write by vnode address (or inode number + FS id) and
 drivers, which need high performance could add additional logic to do
 selective barriers. All other FSes (which don't need barriers) and
 drivers (which don't need this optimization) will work as it is now.
 It doesn't look like tight coupling, as this stream id could be
 anything FS want (information of FS structure will not leak though
 it) and 0 if FS don't want to use this feature.


--=20
// Black Lion AKA Lev Serebryakov <lev@FreeBSD.org>




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?958644234.20130306105205>