|
From: Nikolaus R. <Nik...@ra...> - 2018-07-18 19:39:04
|
On Jul 18 2018, Satya Prakash GS <g.s...@gm...> wrote:
> Hi,
>
> Ours is a distributed filesystem and we are using fuse to access our
> filesystem locally.
> Inode numbers in our filesystem get reused, however our filesystem has
> a concept similar to generation number which gets bumped up on every
> reuse. Our inode numbers are bigger than 8-bytes and we coulnd't
> squeeze in the generation number into the ino that we serve fuse
> kernel.
>
> Inode numbers created by one fuse node could potentially be deleted by
> the other node. This leads to EBUSY errors in mkdir (mkdir does "do I
> know this inode check. If kernel thinks it knows this inode then it
> complains that the inode is busy"). One way to fix this issue is by
> maintaining a replica of the kernel dentry cache in our userspace.
I'm surprised that you are getting away without doing this already. How
do you handle unlink of potentially open files if you do not keep track
of the lookup count?
> Every time I serve the inode I should first check if this inode exists
> in the userspace cache and if it does, then do
> fuse_lowlevel_notify_inval_entry on that dentry. However, things could
> get a lot simpler if the generation number served in mkdir is used in
> resolving conflicts in kernel. Is this already addressed. If so,
> kindly tell me which release has this fix. We are currently in 2.7 and
> we cherry-picked few fixes from 2.9.
I don't think this is implemented. Since this would be a change in the
kernel, the libfuse version would also be irrelevant, you'd have to look
at the Linux kernel version.
Best,
-Nikolaus
--
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
|