From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Sat, 14 May 2005 18:33:47 -0400 From: Russ Cox To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Subject: Re: [9fans] Plan 9 server controls impaired and steps taken before In-Reply-To: <1fdacd4aa6b0973c15386e1f8e7aa6df@ar.aichi-u.ac.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <775b8d190505101428367bf34e@mail.gmail.com> <56b14b2f88d235622337c5374aaaca01@plan9.ucalgary.ca> <32a656c205051017331a03d59f@mail.gmail.com> <32a656c2050514101155984a58@mail.gmail.com> <1fdacd4aa6b0973c15386e1f8e7aa6df@ar.aichi-u.ac.jp> Topicbox-Message-UUID: 4c25e110-ead0-11e9-9d60-3106f5b1d025 > > There is a window (I think ten seconds) between snap -a > > and fossil deciding to start archiving. If you access any > > file in those ten seconds then enough of the root gets > > copied-on-write that you shouldn't see the deadlock at all. > > >=20 > What happens if some accesses come from Internet during that time ? > Files in /sys/log/* are big enough. > Sorry I couldn't understand "the root". The root of the tree of files and blocks. It's copy-on-write after a snapshot but snap -a locks the blocks while it is archiving. If the block has already been copied, no big deal. If it's still the one in the file tree (not been copied-on-write yet) then you can't access it until the archiver finishes. I should fix this to be some sort of read lock but it's not completely straightforward. Russ