Re: [fuse-devel] [PATCH 01/25] VFS: move attr_kill logic from notify_change into helper function

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On the other hand, the filesystem writers here are declaring their own
> setattr operation. Is it unreasonable for them to take responsibility
> for handling this too? 

We have about half of all the in-tree filesystems declaring
->setattr(), and out of those only two that we know would use this.
Others haven't commented, which proably means, they just don't care
about this issue.

And even if most of them would make use of this feature, a inode flag
or filesystem flag for a smooth and backward compatible migration is
just so much better than risking to break filesystems.

And yes, I'm thinking about in-tree filesystems as well.  I'm sure you
did a thorough audit of all filesystems, but we are all human and can
make mistakes.  It is _always_ safer to not change an API which could
cause silent breakage.  And IMO, that's far more important than the
beauty of an interface (and ->setattr() is not beautiful with or
without an inode flag).

> Another alternative might be to rename notify_change(). I don't really
> like gratuitously breaking the API, though, and that function is
> referenced in a lot of documentation. Changing it might be confusing...

Oh no.  I'd like less breakage not more.

Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux