From mboxrd@z Thu Jan 1 00:00:00 1970 From: "William A.(Andy) Adamson" Subject: Re: NFS4 crack Date: Mon, 19 Sep 2005 14:53:36 -0400 Message-ID: <20050919185336.758321BB7B@citi.umich.edu> References: <20050919133921.GA12208@lst.de> <20050919180240.GA26470@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Bryan Henderson , Christoph Hellwig , akpm@osdl.org, andros@citi.umich.edu, "J. Bruce Fields" , linux-fsdevel@vger.kernel.org, neilb@cse.unsw.edu.au Return-path: Received: from citi.umich.edu ([141.211.133.111]:34651 "EHLO citi.umich.edu") by vger.kernel.org with ESMTP id S932575AbVISSxh (ORCPT ); Mon, 19 Sep 2005 14:53:37 -0400 To: Christoph Hellwig In-reply-to: <20050919180240.GA26470@infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org > On Mon, Sep 19, 2005 at 10:13:49AM -0700, Bryan Henderson wrote: > > >FILENAMES ARE POLICY AND HAVE NO BUSINESS IN THE KERNEL > > > > I think that's a great policy, but we can't be all that righteous about it > > because we don't do it today. I have a system that has highly customized > > file names, so I'm pretty familiar with all the world's hardcoded file > > names. ISTR the Linux kernel hardcodes /sbin/init, /bin/sh, and > > /sbin/modprobe. > > They are not nice, but quite a bit different, as we are trying to execute > them, which can't have bad side-effects in case they don't exist. > > What nfsd does is expecting a directory to be present on which it can > do various operations. That's much worse then trying to execute or > even read from a file. what we could do is not provide a default, and turn off reboot recovery (no grace period) if the recovery directory is not configured. > Besides that all this directory handling really > belongs into userland as pointed out _three times_ now. We were anticipating placing data into files in the recovery directory at each OPEN and each LOCK call in order to limit the scope of the NFSv4 grace period to the state that was actually in use prior to the reboot. We therefore went ahead with a kernel implementation for performance reasons. -->Andy