Re: [zfs-discuss] History of EPERM for unlink() of directories on ZFS?
On Tue, Jun 26, 2012 at 8:12 AM, Lionel Cons wrote: > On 26 June 2012 14:51, 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 3 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
Re: [zfs-discuss] History of EPERM for unlink() of directories on ZFS?
>We've already asked our Netapp representative. She said it's not hard >to add that. And symlinks don't work for this? I'm amazed because we're talking about the same file system. Or is it that the code you have does the hardlinking? If you want this rfo Oracle, you would need to talk to an Oracle representative and not in a mailing list (for illumos email will work I suppose) >> 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 3 directories. Each day (this is CERN after >all). I'm assuming then that it is the code for which you don't have the source which does the hardlinking? I'm still not sure why symlinks won't work or for that matter loopback mounts. Casper ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] History of EPERM for unlink() of directories on ZFS?
On 26 June 2012 14:51, wrote: > >>> To be honest, I think we should also remove this from all other >>> filesystems and I think ZFS was created this way because all modern >>> filesystems do it that way. >> >>This may be wrong way to go if it breaks existing applications which >>rely on this feature. It does break applications in our case. > > I don't think this isn't supported on most Linux filesystems either. > > What do you use it for? > >>Anyway, we've added this to the list of mandatory features and see >>what we can procure with that. > > > Not much? We've already asked our Netapp representative. She said it's not hard to add that. > 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 3 directories. Each day (this is CERN after all). The other way around would be to throw the SPARC machines away and go with Netapp. > For one, it requires the application to run with root (older versions) or > with specific privileges which aren't, e.g., available in non-global zones. The code runs with privileges anyway. Lionel ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] History of EPERM for unlink() of directories on ZFS?
>> To be honest, I think we should also remove this from all other >> filesystems and I think ZFS was created this way because all modern >> filesystems do it that way. > >This may be wrong way to go if it breaks existing applications which >rely on this feature. It does break applications in our case. I don't think this isn't supported on most Linux filesystems either. What do you use it for? >Anyway, we've added this to the list of mandatory features and see >what we can procure with that. Not much? I'd suggest whether you can restructure your code and work without this. For one, it requires the application to run with root (older versions) or with specific privileges which aren't, e.g., available in non-global zones. Casper ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] History of EPERM for unlink() of directories on ZFS?
On 25 June 2012 11:33, wrote: > >>Does someone know the history which led to the EPERM for unlink() of >>directories on ZFS? Why was this done this way, and not something like >>allowing the unlink and execute it on the next scrub or remount? > > > It's not about the unlink(), it's about the link() and unlink(). > But not allowing link & unlink, you force the filesystem to contain only > trees and not graphs. > > It also allows you to create directories were ".." points to a directory > were the inode cannot be found, simply because it was just removed. > > The support for link() on directories in ufs has always given issues > and would create problems fsck couldn't fix. > > To be honest, I think we should also remove this from all other > filesystems and I think ZFS was created this way because all modern > filesystems do it that way. This may be wrong way to go if it breaks existing applications which rely on this feature. It does break applications in our case. Anyway, we've added this to the list of mandatory features and see what we can procure with that. Lionel ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
Re: [zfs-discuss] History of EPERM for unlink() of directories on ZFS?
>Does someone know the history which led to the EPERM for unlink() of >directories on ZFS? Why was this done this way, and not something like >allowing the unlink and execute it on the next scrub or remount? It's not about the unlink(), it's about the link() and unlink(). But not allowing link & unlink, you force the filesystem to contain only trees and not graphs. It also allows you to create directories were ".." points to a directory were the inode cannot be found, simply because it was just removed. The support for link() on directories in ufs has always given issues and would create problems fsck couldn't fix. To be honest, I think we should also remove this from all other filesystems and I think ZFS was created this way because all modern filesystems do it that way. Casper ___ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
