Date: Wed, 08 Mar 2006 13:33:46 -0700 From: Scott Long <scottl@samsco.org> To: Eric Anderson <anderson@centtech.com> Cc: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org, Ruslan Ermilov <ru@FreeBSD.org>, Kris Kennaway <kris@obsecurity.org>, Tor Egge <tegge@FreeBSD.org> Subject: Re: cvs commit: src/sys/ufs/ufs ufs_lookup.c Message-ID: <440F3FAA.5090804@samsco.org> In-Reply-To: <440ED585.4090706@centtech.com> References: <200603080214.k282EdBH054091@repoman.freebsd.org> <20060308070632.GA52377@ip.net.ua> <20060308081625.GA55281@xor.obsecurity.org> <20060308104000.GC52377@ip.net.ua> <440ED585.4090706@centtech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Eric Anderson wrote: > Ruslan Ermilov wrote: > >> On Wed, Mar 08, 2006 at 03:16:25AM -0500, Kris Kennaway wrote: >> >> >>> On Wed, Mar 08, 2006 at 09:06:32AM +0200, Ruslan Ermilov wrote: >>> >>> >>>> On Wed, Mar 08, 2006 at 02:14:39AM +0000, Tor Egge wrote: >>>> >>>> >>>>> tegge 2006-03-08 02:14:39 UTC >>>>> >>>>> FreeBSD src repository >>>>> >>>>> Modified files: >>>>> sys/ufs/ufs ufs_lookup.c Log: >>>>> Don't set IN_CHANGE and IN_UPDATE on inodes for potentially >>>>> suspended >>>>> file systems. This could cause deadlocks when creating snapshots. >>>>> Reviewed by: jeff >>>>> Revision Changes Path >>>>> 1.80 +0 -1 src/sys/ufs/ufs/ufs_lookup.c >>>>> >>>>> >>>> >>>> Like for example "ls -l /filesystem/.snap" when "fsck -B" is in place? >>>> >>> >>> Is that a deadlock, or just the process being suspended until fsck >>> finishes? >>> > > > I think the only options we have to fix this is to either make the .snap > directory 'hidden' (which is not a feature yet), or to possibly cache > the inode information on parent directories containing snapshots, so > when a fs is suspended or a snapshot is in progress, a stat of the > parent directory of the snapshots' doesn't block until the snapshot > finishes. > There has been brief discussion on freebsd-fs@ about adding a 'hidden' > flag (usable with chflags) to files and directories, and tools like ls, > etc, that would normally stat each file/dir in a directory would ignore, > unless a special option was used. That would not stop other tools doing > stat calls from seeing it though, but I think most of the blocking > happens when a user does an ls -al in the directory. > > > Eric > > > > The only way to effectively avoid the problem would be to teach UFS to completely ignore the '.snap' directory entry when doing a readdir and lookup. That is not the same as what is being discussed with having a special hiiden hint flag. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?440F3FAA.5090804>