Date: Fri, 13 Jan 2006 18:54:34 +0100 (CET) From: Oliver Fromme <olli@lurza.secnetix.de> To: freebsd-fs@FreeBSD.ORG Subject: Re: preventing deadlocks in snapshot directories - unexplained Message-ID: <200601131754.k0DHsYuN033839@lurza.secnetix.de> In-Reply-To: <43C7BBAE.4040600@centtech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Eric Anderson wrote: > Oliver Fromme wrote: > > user <user@dhp.com> wrote: > > > cd /.snap > > > rm -rf snap3 > > > > > > the _entire_ /.snap directory locks up until that command completes. > > > > Well, yes, certain file system operations are blocked > > until the removal of the snapshot is complete > > Well, its ok to put snapshots anywhere, but when operations on a > snapshot file are in progress, stat calls on the snapshot file will > block. I think this is his problem. Yes, very probably. > I wonder how painful it would be > to have stat's on snapshot files return with (something) when a snapshot > operation is in progress, instead of blocking, or even if that is possible. I don't think it would be very painful to modify the code so it returns a cached (or even completely faked) copy of the snapshot file's stat structure, instead of blocking. (Disclaimer: I haven't had a closer look at the code.) On a related note, Netapp filers have the ability to hide the snapshot directory. You can still cd into it and access files within it (provided you know their full path), but it doesn't appear in directory listings. That feature prevents innocent "ls -lR", find(1) and other recursive commands from accidentally entering the snapshot directory, and it is also excluded from shell globbing. It would be very useful for FreeBSD to behave the same, too, possibly controlled by a sysctl. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "Python is an experiment in how much freedom programmers need. Too much freedom and nobody can read another's code; too little and expressiveness is endangered." -- Guido van Rossum
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200601131754.k0DHsYuN033839>