Date: Wed, 08 Mar 2006 07:00:53 -0600 From: Eric Anderson <anderson@centtech.com> To: Ruslan Ermilov <ru@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, Tor Egge <tegge@freebsd.org>, cvs-all@freebsd.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: cvs commit: src/sys/ufs/ufs ufs_lookup.c Message-ID: <440ED585.4090706@centtech.com> In-Reply-To: <20060308104000.GC52377@ip.net.ua> References: <200603080214.k282EdBH054091@repoman.freebsd.org> <20060308070632.GA52377@ip.net.ua> <20060308081625.GA55281@xor.obsecurity.org> <20060308104000.GC52377@ip.net.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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 -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?440ED585.4090706>