On Wed, Jun 04, 2008 at 06:33:45PM +0300, Andriy Gapon wrote: > on 04/06/2008 18:23 Kostik Belousov said the following: > > On Wed, Jun 04, 2008 at 06:07:47PM +0300, Andriy Gapon wrote: > [snip] > >> dumps are done on live filesystems using -L. > [snip] > >> 4. both systems have gjournal support (on 6.X it is added via a > >> "non-official" patch), there are gjournaled filesystems on both systems > >> and they are dumped. > > > > Do you use snapshots on the gjournaled fs ? I believe this is problematic. > > Yes, I do via dump -L. I don't otherwise (no mksnap_ffs). > I had some thoughts about that. > But... I remember discussing this on geom list and I think pjd said that > this should work and also it worked for me flawlessly except for that > one moment. > BTW, those filesystems are mounted like the following: > ufs, asynchronous, local, noatime, gjournal > This is to say that I do not mix gjournal and softupdates, which is also > possible (at least not prohibited).
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.
pgpOaEHFrzUnG.pgp
Description: PGP signature
