Re: Attempt at "stat light" implementation

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

 



Oleg Drokin wrote:
On Apr 7, 2009, at 11:22 AM, jim owens wrote:

 - who is going to fix (and keep fixed) those gui file managers
   (and stop users from "ls -l" or viewing properties)?

The idea is once this gets upstream, ls (and then possibly
filemanagers) will start to use this call.
Then it will eventualy propagate to users the natural way.

you can lead them to water, but can't keep them from peeing in it :)

The thing is, e.g. in Lustre there are different kind of locks you
would get for different inode attributes and these 2 RPCs to
get them separately 5 minutes apart from each other would actually
save us some RPCs, since there would not be lock ping pong to
invalidate the locks held by a client protecting e.g. directory
nlink count (that the client does not care about) when another dir
is created in that dir.

I would have been happy with more RPCs if we even got 10 seconds
of extra time on our shared lock before doing the invalidate and
switch to the exclusive heavy attr lock.  It was all the heavy
calls at subsecond intervals after the light ones that really
hurt.  But if you start seeing that kind of traffic I guess you
can always code it to change light requests to heavy ones and
cache them.

jim
--
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