Re: update-link-count-parent POSIX xlator parameter

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

 



thanks!

Swiftonfile project needed file creation/deletion notifications (op+path) from glusterfs to update Swift's databases. inotify on bricks is not recursive and does not scale well. Looked into changelog (which logs only gfids). Even if one assumes that gfid to path conversion can be done efficiently, there was still the problem of converting gfid to path for deleted files which seems impossible.

Regards,
 -Prashanth Pai

----- Original Message -----
From: "Harshavardhana" <harsha@xxxxxxxxxxxxxxxxxx>
To: "Prashanth Pai" <ppai@xxxxxxxxxx>, bhubbard@xxxxxxxxxx, "Anand Avati" <avati@xxxxxxxxxxx>
Cc: "Ben England" <bengland@xxxxxxxxxx>, "gluster-devel" <gluster-devel@xxxxxxxxxxx>
Sent: Thursday, August 21, 2014 11:31:45 AM
Subject: Re:  update-link-count-parent POSIX xlator parameter

On Wed, Aug 20, 2014 at 10:04 PM, Prashanth Pai <ppai@xxxxxxxxxx> wrote:
> Hi,
>
> I recently came across this when I was looking for various ways to convert GFID to Path[1].
> I have tested "build-pgfid" option for basic sanity. It's documented in the commit msg of change[2]. Found one small issue[3]. There could be others.
> Users should be aware that these xattrs generated only for newly created dirs/files and are not built for already existing dirs/files.
>
> [1]: https://github.com/prashanthpai/sof-object-listing/blob/master/changelog/gfid-to-path.md
> [2]: http://review.gluster.org/5951
> [3]: http://review.gluster.org/8352
>

Explored quite a few options here

- https://gist.github.com/harshavardhana/b5d3c69db5312b84022f - was
one approach which was worked by Brad Hubbard which makes used of
kernel dentry caches.
- For ext4 you have
  # debugfs 'ncheck <inode_num>' <device>
- XFS provides something similar, but requires a umount
  # xfs_ncheck -i ino <device>
- Then stumbled across this since its specifically used by Quota, do
not know how hard its to expose this. But Avati indicated that this
would involve additional overheads for every call()
- The best possible solution is to use a database for such a mapping
(quite tricky) and requires a lot of internal work.

So in the end haven't come across an easier way out of this :-)

-- 
Religious confuse piety with mere ritual, the virtuous confuse
regulation with outcomes
_______________________________________________
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