From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Woodhouse Subject: Re: Hi Date: 19 Feb 2003 15:22:48 +0000 Sender: linux-fsdevel-owner@vger.kernel.org Message-ID: <1045668167.19863.27.camel@passion.cambridge.redhat.com> References: <20030218150457.20101.qmail@webmail30.rediffmail.com> <20030218163422.GC1399@arthur.ubicom.tudelft.nl> <1045609648.18245.0.camel@imladris.demon.co.uk> <86adgsuxrl.fsf@trasno.mitica> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: Erik Mouw , Rajaram Suresh Gaunker , linux-fsdevel@vger.kernel.org, kernelnewbies@nl.linux.org Return-path: To: Juan Quintela In-Reply-To: <86adgsuxrl.fsf@trasno.mitica> List-Id: linux-fsdevel.vger.kernel.org On Wed, 2003-02-19 at 14:54, Juan Quintela wrote (re encryption): > If you do it at the filesystem layer you: > a- leave the filesystem structure (i.e. names) unencrypted Why would you want to do that? It's not really an invariant property of encryption-capable file systems, surely? You can crypt the names if you want to. > b- you just don't care if you are not able to recover things at fsck > time :( Likewise. It might be decreed that file sizes and directory tree structure are an acceptable leak of information and hence you can have a fsck which just doesn't grok either filenames, permissions or data -- or you might decide that's not an acceptable leak, and require the key in order to fsck it. You need the key in order to fsck a file system on an encrypted block device _anyway_, right? > c- you are really clever and finds a way to encrypt all the filesystem > and recovering from a crash Parse error. > Apart from that, doing it at the block layer should be much, much > easier :) Filesystems are hard. Let's go shopping :) Doing redundancy at the block layer is much much easier too. That doesn't necessarily make it not suck when a raid rebuild is pointlessly copying blocks which aren't actually _referenced_ by the file system, because it doesn't have the knowledge about the layout that the file system does. -- dwmw2