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>