Date: Thu, 05 Jun 2008 10:45:01 +0300 From: Andriy Gapon <avg@icyb.net.ua> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, freebsd-geom@freebsd.org Subject: Re: mystery: lock up after fs dump Message-ID: <4847997D.4060404@icyb.net.ua> In-Reply-To: <20080604161001.GF63348@deviant.kiev.zoral.com.ua> References: <4846AFC3.3050101@icyb.net.ua> <20080604152332.GE63348@deviant.kiev.zoral.com.ua> <4846B5D9.1050903@icyb.net.ua> <20080604161001.GF63348@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
on 04/06/2008 19:10 Kostik Belousov said the following: > SU are irrelevant to the problem I am thinking of. > > vfs_write_suspend() returns 0 when the filesystem being suspended is already > in suspend state. vfs_write_resume() clears the suspend state. > > vfs_write_suspend/vfs_write_resume are used both by snapshot code and > the gjournal. If two users of these interfaces interleave, then you could > get: > > thread1 thread2 > > vfs_write_suspend() > <- fs is suspended there > vfs_write_suspend() <- returns 0 > vfs_write_resume() > <- fs is no more suspended > thread2 is burned in flame > > Snapshots are protected against this because they are created through > the mount(2). The mount(2) locks the covered vnode and thus serializes > snapshot creation (I think there are further serialization points that > prevent simultaneous snapshotting of the same fs). > > There is nothing I can see that protects snapshots/gjournal interaction. Looks like something to be quite concerned about. Thank you for the analysis. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4847997D.4060404>