Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 20 Oct 1997 09:47:57 +0200
From:      Poul-Henning Kamp <phk@critter.freebsd.dk>
To:        "John S. Dyson" <toor@dyson.iquest.net>
Cc:        roberto@keltia.freenix.fr (Ollivier Robert), current@FreeBSD.ORG
Subject:   Re: nullfs & current 
Message-ID:  <406.877333677@critter.freebsd.dk>
In-Reply-To: Your message of "Sun, 19 Oct 1997 20:43:01 CDT." <199710200143.UAA05747@dyson.iquest.net> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <199710200143.UAA05747@dyson.iquest.net>, "John S. Dyson" writes:
>Ollivier Robert said:
>> According to John S. Dyson:
>> > The VM system holds a reference.  You have to do a vnode_pager_uncache whe
>n
>> > deleting a file.
>> 
>> Wait... Isn't ufs_remove() supposed to do that ? ufs_remove() is called by
>> null_bypass() by an indirect call (VCALL()) and it seemed safe to consider
>> that the lower level was supposed to DTR.
>> 
>> Do I have to create a null_remove() function in order to call
>> vnode_pager_uncache inside it ?
>> 
>nullfs should really share the VM object with the lower filesystem, but genera
>lly
>what you say is true, even if you don't share the object.  The complexity is
>one reason that I haven't fixed it.  It IS fixable reasonably though.

No, this is wrong.  Nullfs can only share the VM object if the
permissions are the same, consider a read-only mounted nullfs for
instance.

calling vnode_pager_uncache() null_remove() would be wrong, the file
may still be open.

In FFS we only call vnode_pager_uncache in ffs_unmount()...

Whatever needs to be done should probably be done in null_inactive(),
look at sys/ufs/ufs/ufs_inode.c:ufs_inactive().

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?406.877333677>