On Tue, Jun 26, 2012 at 8:12 AM, Lionel Cons <lionelcons1...@googlemail.com> wrote: > On 26 June 2012 14:51, <casper....@oracle.com> wrote: > We've already asked our Netapp representative. She said it's not hard > to add that.
Did NetApp tell you that they'll add support for using the NFSv4 LINK operation on source objects that are directories?! I'd be extremely surprised! Or did they only tell you that they'll add support for using the NFSv4 REMOVE operation on non-empty directories? The latter is definitely feasible (although it could fail due to share deny OPENs of files below, say, but hey). The former is... not sane. >> I'd suggest whether you can restructure your code and work without this. > > It would require touching code for which we don't have sources anymore > (people gone, too). It would also require to create hard links to the > results files directly, which means linking 15000+ files per directory > with a minimum of 30000 directories. Each day (this is CERN after > all). Oh, I see. But you still don't want hardlinks to directories! Instead you might be able to use LD_PRELOAD to emulate the behavior that the application wants. The app is probably implementing rename(), so just detect the sequence and map it to an actual rename(2). > The other way around would be to throw the SPARC machines away and go > with Netapp. So Solaris is just a fileserver here? Nico -- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
