linux-kernel - Re: Integration of SCST in the mainstream Linux kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.LFD.1.00.0802041530150.3034@hp.linux-foundation.org>
Date:	Mon, 4 Feb 2008 15:45:19 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Jeff Garzik <jeff@...zik.org>
cc:	"J. Bruce Fields" <bfields@...ldses.org>,
	"Nicholas A. Bellinger" <nab@...ux-iscsi.org>,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	Vladislav Bolkhovitin <vst@...b.net>,
	Bart Van Assche <bart.vanassche@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	FUJITA Tomonori <fujita.tomonori@....ntt.co.jp>,
	linux-scsi@...r.kernel.org, scst-devel@...ts.sourceforge.net,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Mike Christie <michaelc@...wisc.edu>
Subject: Re: Integration of SCST in the mainstream Linux kernel



On Mon, 4 Feb 2008, Jeff Garzik wrote:
> 
> Well, speaking as a complete nutter who just finished the bare bones of an
> NFSv4 userland server[1]...  it depends on your approach.

You definitely are a complete nutter ;)

> If the userland server is the _only_ one accessing the data[2] -- i.e. the
> database server model where ls(1) shows a couple multi-gigabyte files or a raw
> partition -- then it's easy to get all the semantics right, including file
> handles.  You're not racing with local kernel fileserving.

It's not really simple in general even then. The problems come with file 
handles, and two big issues in particular:

 - handling a reboot (of the server) without impacting the client really 
   does need a "look up by file handle" operation (which you can do by 
   logging the pathname to filehandle translation, but it certainly gets 
   problematic).

 - non-Unix-like filesystems don't necessarily have a stable "st_ino" 
   field (ie it may change over a rename or have no meaning what-so-ever, 
   things like that), and that makes trying to generate a filehandle 
   really interesting for them.

I do agree that it's possible - we obviously _did_ have a user-level NFSD 
for a long while, after all - but it's quite painful if you want to handle 
things well. Only allowing access through the NFSD certainly helps a lot, 
but still doesn't make it quite as trivial as you claim ;)

Of course, I think you can make NFSv4 to use volatile filehandles instead 
of the traditional long-lived ones, and that really should avoid almost 
all of the problems with doing a NFSv4 server in user space. However, I'd 
expect there to be clients that don't do the whole volatile thing, or 
support the file handle becoming stale only at certain well-defined points 
(ie after renames, not at random reboot times).

			Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/