[haiku-commits] Re: r35194 - in haiku/trunk/src/add-ons/kernel/file_systems/layers: . log_overlay

  • From: "Michael Lotz" <mmlr@xxxxxxxx>
  • To: haiku-commits@xxxxxxxxxxxxx
  • Date: Wed, 20 Jan 2010 13:44:03 +0000

> On 2010-01-20 at 06:01:28 [+0100], mmlr@xxxxxxxx wrote:
> > +static status_t
> > +overlay_put_vnode(fs_volume *volume, fs_vnode *vnode, bool reenter)
> > +{
> > +    DO_LOG("put_vnode reenter: %s\n", reenter ? "yes" : "no");
> [...]
> 
> > +static status_t
> > +overlay_remove_vnode(fs_volume *volume, fs_vnode *vnode, bool 
> > reenter)
> > +{
> > +    DO_LOG("remove_vnode reenter: %s\n", reenter ? "yes" : "no");
> 
> Those two are a bit problematical, if you log to file. The reason 
> lies in 
> the unused vnode management of the VFS. Let's say some syscall or 
> whatever 
> causes BFS for the boot volume to be entered. BFS calls the VFS's 
> get_vnode() (e.g. for an index) and later put_vnode(). Either call 
> (currently only the latter) can cause unrelated unused vnodes to be 
> freed. 
> If one of those belongs to the volume with the log overlay, either of 
> these 
> two hooks is called. The write() will reenter BFS, potentially causing 
> a 
> deadlock. I don't know our BFS implementation well enough to say 
> whether a 
> deadlock can actually happen (under BeOS it could), but since file 
> systems 
> are not required to deal with those situations, I wouldn't risk it 
> anyway.

I see, thanks for the pointer! Do you see a way how to circumvent this 
situation? Maybe writing into an allocated buffer and periodically 
flushing to the file from a dedicated thread? The volume of logged data 
can be relatively high depending on the use-pattern, so it'd require 
quite a bit of buffer space to not slow things down too much.

Regards
Michael

Other related posts: