Re: NFS serving off NTFS panic

[Dmitri Nikulin <dnikulin@xxxxxxxxxxxxxxx>]

Matthew Dillon wrote:

> +	if (nvp) {
> +		vput(nvp);
> +		nvp = NULL;
> +	}
> 	    
>  
Maybe a better 'solution' (at least a more globally useful hack) would 
be to have vput() do nothing if its argument is NULL. This means any 
other file systems (of which I assume there are none, but you can never 
be too sure) which are susceptible to this 'oops' will suddenly work as 
expected.

The way it looks now it's adding more and more exceptions rather than 
avoiding a problem, so perhaps a review of the NTFS code's design is 
overdue. Do enough people use it for it to matter?

I'm sorry but the only machine I had under DragonFly had to be put to 
another use (it went from sandbox to production gateway, because the 
existing gateway had a disk failure) so I can't immediately test this 
patch, but maybe someone with the resources can help out. Knowing my 
curiosity I'll get another rig up eventually, but for now my hands are tied.

On another note, is it such a good idea sticking to the direct IO style 
that all the BSDs use for NFS? It certainly does lead to amazing 
performance, but it means not all file systems work the same; I wasn't 
surprised to find that Linux, with a (by default) abstraction between 
file systems under NFS, could serve off NTFS perfectly. NetBSD didn't 
show any files on the volume, and so far DragonFly has crashed. I'm not 
even giving FreeBSD a chance. If it can be done cleanly, maybe a better 
abstraction wouldn't be so bad; if new file systems are added they can 
be supported as NFS exports as soon as they work as locals. Just an idea 
though, I'm certainly no kernel developer.