Bug 214326 - unionfs+nullfs strange behaviour
Summary: unionfs+nullfs strange behaviour
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.3-RELEASE
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-fs (Nobody)
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2016-11-08 14:33 UTC by root
Modified: 2023-12-28 12:07 UTC (History)
2 users (show)

See Also:


Attachments
An experimental patch for unionfs internal cache(Nov 8, 2016) (2.60 KB, patch)
2016-11-08 14:33 UTC, root
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description root 2016-11-08 14:33:21 UTC
Created attachment 176786 [details]
An experimental patch for unionfs internal cache(Nov 8, 2016)

** This report may be related to, or duplicate of Bug #186360 **

With unionfs+nullfs, I saw a strange behaviour.

# mkdir mountfrom1 mountfrom2 mountto
# mkdir mountfrom1/a
# touch mountfrom2/b
# mount -t unionfs mountfrom1 mountto
# mount -t nullfs mountfrom2 mountto/a
# ls mountto/a/b
ls: mountto/a/b: No such file or directory
# ls mountto/a
b
# ls mountto/a/b
mountto/a/b

I digged into unionfs module, and found 'unionfs_lookup' is returning different vnode for same single object 'a', for mount and later "ls" command.
It is caused by a bug in unionfs's internal cache (I think), and I solved it with an attached patch.

Well, my patch omits a check for 'ISLASTCN', but I don't know why the check is needed.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2023-12-28 12:07:25 UTC
Comment on attachment 176786 [details]
An experimental patch for unionfs internal cache(Nov 8, 2016)

^Triage: convert this to text/plain and set the Patch flag so that the
automation can see it.