Readdir d_off encoding

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

 



With the changes present in [1] and [2],

A short explanation of the change would be, we encode the subvol ID in the d_off, losing 'n + 1' bits in case the high order n+1 bits of the underlying xlator returned d_off is not free. (Best to read the commit message for [1] :) )

Although not related to the latest patch, here is something to consider for the future:

We now have DHT, AFR, EC(?), DHT over DHT (Tier) which need subvol encoding in the returned readdir offset. Due to this, the loss in bits _may_ cause unwanted offset behavior, when used in the current scheme. As we would end up eating more bits than what we do at present.

Or IOW, we could be invalidating the assumption "both EXT4/XFS are tolerant in terms of the accuracy of the value presented back in seekdir(). i.e, a seekdir(val) actually seeks to the entry which has the "closest" true offset."

Should we reconsider an in memory _cookie_ like approach that can help in this case?

It would invalidate (some or all based on the implementation) the following constraints that the current design resolves, (from, [1])
- Nothing to "remember in memory" or evict "old entries".
- Works fine across NFS server reboots and also NFS head failover.
- Tolerant to seekdir() to arbitrary locations.

But, would provide a more reliable readdir offset for use (when valid and not evicted, say).

How would NFS adapt to this? Does Ganesha need a better scheme when doing multi-head NFS fail over?

Thoughts?

Shyam
[1] http://review.gluster.org/#/c/4711/
[2] http://review.gluster.org/#/c/8201/
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel




[Index of Archives]     [Gluster Users]     [Ceph Users]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux