non file system based implementation of nio.file

[Tigran Mkrtchyan]

Hi Alan,

one of the Chimera goals is to be independent of NFS interface.

I have looked java.nio.File.* and my impression is that it's lot o work 
to make Chimera compatible with new API. Nevertheless it's possible and 
I will definitely try it out. Chimera has FsInodes ( unique file 
identifier ) which , you are right , is something like FileRef. I think 
extending FileRef, FileSystem, and FileSystemProvider is the first step.

I will try to build jdk7 and let you know. I guess it's a good poof for 
the API. Looks very promising.

Thanks,
	Tigran.


Alan Bateman wrote:
> Tigran Mkrtchyan wrote:
>>
>>
>> Hi,
>>
>>
>> I am one of the core developers of dCache project 
>> (http://www.dcache.org). We providing a distributed storage solution 
>> for High Energy Physics and currently dCache deployed on large number 
>> of national labs across the world.
>>
>> To make long story short.  The key point of dCache design is single 
>> name space with distributed data servers.  The namespace ( called 
>> Chinera ) is a  filesystem simulated on top of relational database . 
>> Every thing is pure java. On top of our API we implement several front 
>> ends - http server, file borwser, NFSv3 and NFSv4.1 and of course 
>> interface for dCache. To overcome limitations of standard java.io.File 
>> we have written lot of classes to cover symbolic links, NFSv4 ACLs, 
>> Unix-like stat, iterator over directory entries and so on.
>>
>> By looking at JavaOne presentations I find out that java7 will have 
>> most of it in core API. For us it makes sence to replace home grown 
>> staff with one which comes with java ( I have to support less code :) 
>> ). But we are currently in production and lot of labs still uses 
>> java5. For us it means that is we start to use interfaces from java7 
>> we have to include them into our distribution.
>>
>> As I understand, the code is distributed under GPLv2.
>>
> The dCache project looks very interesting but I don't think I have a 
> sufficient overview to say too much. If I understand correctly, Chimera 
> can act as an NFS server and so would be transparent to both native and 
> java applications where the file system is mounted. At the same time, I 
> see on one of your pages that the NFS interface is only for name space 
> operations in which case I/O to the files will not work - is that 
> correct? If so, then I assume there is a client or other library 
> required to access the "file system" - is that right? In that case, then 
> the provider interface in our API may be useful as it allows you to use 
> the API with other file system implementations. Do you perform 
> operations on files that differ from traditional I/O? I ask as perhaps 
> you will require some dCache specific extensions for those. I notice ID 
> <-> name space mapping which suggests to me that you access files by ID 
> rather than paths. This may require extending FileRef with operations 
> that access the file by ID for example.
> 
> As regards versions - yes, this API is in the works for Java SE 7. It 
> would be good to see if it meets your needs. The source code is indeed 
> GPLv2 (+ classpath exception) but we will have early access binaries 
> very soon. The API and implementation are still in development so there 
> will be ongoing change/refinement for a while. There isn't any plans to 
> release a standalone version for use with shipping JDK releases but 
> Kevin Bourrillion from Google is exploring this with a view to a 
> backport of the file system API on Linux.
> 
> -Alan.
> 
> 

-- 
________________________________________________________________________
Tigran Mkrtchyan                               DESY, IT,
tigran.mkrtchyan at desy.de                       Notkestrasse 85,
Tel: + 49 40 89983946                          Hamburg 22607,
Fax: + 49 40 89984429                          Germany.