Date: Wed, 6 Mar 2013 12:29:52 +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: <92952324.20130306122952@serebryakov.spb.ru> In-Reply-To: <201303060823.r268NNor015235@gw.catspoiler.org> References: <958644234.20130306105205@serebryakov.spb.ru> <201303060823.r268NNor015235@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., 12:23:23: >> DL> When growing a file, the data *must* be written before writing the b= lock >> DL> pointer that points to it. If this ordering isn't obeyed, then a sy= stem >> 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 >> :) DL> Performance when deleting multi-gigabyte, low-value files would kind of DL> suck if we did that ... It should be application-level decision. And user-level, really :) Yes, I'm paranoid, and delete all sensitive data with special software, which does several passes of writing zeroes, ones and random garbage :) --=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?92952324.20130306122952>