From owner-freebsd-fs@FreeBSD.ORG Mon Jan 9 15:07:19 2006 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 980E716A41F for ; Mon, 9 Jan 2006 15:07:19 +0000 (GMT) (envelope-from snezhko@indorsoft.ru) Received: from indor.net.tomline.ru (indor.net.tomline.ru [213.183.100.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id C207543D45 for ; Mon, 9 Jan 2006 15:07:17 +0000 (GMT) (envelope-from snezhko@indorsoft.ru) Received: from SNEZHKO by indorsoft.ru (MDaemon.PRO.v7.2.2.R) with ESMTP id md50000043424.msg for ; Mon, 09 Jan 2006 21:07:04 +0600 X-AntiVirus: Checked by Dr.Web [version: 4.32b, engine: 4.32b, virus records: 132805, updated: 29.12.2005] To: freebsd-fs@freebsd.org From: Victor Snezhko Date: Mon, 09 Jan 2006 21:06:57 +0600 Message-ID: User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (windows-nt) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Processed: indor.net.tomline.ru, Mon, 09 Jan 2006 21:07:04 +0600 (not processed: spam filter disabled) X-Return-Path: snezhko@indorsoft.ru X-MDaemon-Deliver-To: freebsd-fs@freebsd.org X-VVS-Spam: false Subject: mount_smbfs, windows 2003 domain shares and NETSMBCRYPTO X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2006 15:07:19 -0000 Hello, Recently I wanted to mount a windows share to my freebsd(-current) box. Windows share resides on a machine that is a part of domain, domain controller is Windows 2003 machine. I used # mount_smbfs -W MYDOMAIN //domain_user@SERVER/share mountpoint and got "Authentication error" (password was right) Surprisingly, when I tried to google a bit for a reason, I didn't find any decent solution. Most pages suggest turning off digital signing on the domain controller, and others contain whining about the fact that modifying DC's settings is not allowed for security reasons. Only here: http://www.opennet.ru/tips/info/585.shtml I saw recommendation(in Russian) to recompile a kernel with those kernel options: options NETSMB #SMB/CIFS requester options NETSMBCRYPTO #encrypted password support for SMB options LIBMCHAIN #mbuf management library options LIBICONV options SMBFS I was dumb enough to ignore it, (and it's outdated anyway, as at least LIBMCHAIN and LIBICONV can be loaded (and are loaded) as a modules by need). I went to dig into sources and found that option NETSMBCRYPTO is a solution. On my -current box it is the only option that needs to be added to make things work. Hope this message will be more helpful than bullshit about turning off signing on DC (it works, but it's just not right). Couple of questions: 1) Would it be right to include this hint to a mount_smbfs manpage? I could prepare a patch and send it to the doc@ maillist. 2) Is there a reason for this option not being in GENERIC? It's absence makes mount_smbfs in conjunction with default kernel more and more useless (as time passes and more domain controllers jump to windows 2003). -- WBR, Victor V. Snezhko E-mail: snezhko@indorsoft.ru From owner-freebsd-fs@FreeBSD.ORG Tue Jan 10 07:55:18 2006 Return-Path: X-Original-To: freebsd-fs@FreeBSD.org Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4D0916A41F for ; Tue, 10 Jan 2006 07:55:18 +0000 (GMT) (envelope-from jlb@tid.es) Received: from correo.tid.es (tidos.tid.es [193.145.240.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2018D43D45 for ; Tue, 10 Jan 2006 07:55:17 +0000 (GMT) (envelope-from jlb@tid.es) Received: from tid (filvit [192.168.48.202]) by tid.hi.inet (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0ISV002NQA0FGK@tid.hi.inet> for freebsd-fs@FreeBSD.org; Tue, 10 Jan 2006 08:55:28 +0100 (MET) Received: from jlb (jlb.hi.inet [10.95.14.82]) by tid.hi.inet (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with SMTP id <0ISV007JYA0FEN@tid.hi.inet> for freebsd-fs@FreeBSD.org; Tue, 10 Jan 2006 08:55:27 +0100 (MET) Date: Tue, 10 Jan 2006 09:03:29 +0100 From: Javier Lazareno Blas To: freebsd-fs@FreeBSD.org Message-id: <003201c615bc$577fb520$520e5f0a@jlb> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-Priority: 3 X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-scores: Clean:85.02094 C:22 M:0 S:5 R:5 X-imss-settings: Baseline:2 C:1 M:1 S:2 R:1 (0.0100 0.0100) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: ntfs driver X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2006 07:55:18 -0000 Hi all, i am reading the source of the ntfs driver, and i don=B4t = understand why it uses two different structures for files? (ntnode and = fnode) do you know why?= From owner-freebsd-fs@FreeBSD.ORG Tue Jan 10 16:30:44 2006 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D8B8F16A41F for ; Tue, 10 Jan 2006 16:30:44 +0000 (GMT) (envelope-from mday@apple.com) Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E19E43D45 for ; Tue, 10 Jan 2006 16:30:42 +0000 (GMT) (envelope-from mday@apple.com) Received: from relay7.apple.com (relay7.apple.com [17.128.113.37]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id k0AGUeu6006859; Tue, 10 Jan 2006 08:30:40 -0800 (PST) Received: from [17.202.43.217] (doomsday.apple.com [17.202.43.217]) by relay7.apple.com (Apple SCV relay) with ESMTP id 40569229; Tue, 10 Jan 2006 08:30:40 -0800 (PST) In-Reply-To: <003201c615bc$577fb520$520e5f0a@jlb> References: <003201c615bc$577fb520$520e5f0a@jlb> Mime-Version: 1.0 (Apple Message framework v749) X-Priority: 3 Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <0DB067B1-6E62-437F-AA48-D48D89C13C91@apple.com> Content-Transfer-Encoding: quoted-printable From: Mark Day Date: Tue, 10 Jan 2006 08:30:35 -0800 To: Javier Lazareno Blas X-Mailer: Apple Mail (2.749) X-Brightmail-Tracker: AAAAAA== Cc: freebsd-fs@freebsd.org Subject: Re: ntfs driver X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2006 16:30:45 -0000 On Jan 10, 2006, at 12:03 AM, Javier Lazareno Blas wrote: > Hi all, i am reading the source of the ntfs driver, and i don=B4t =20 > understand why it uses two different structures for files? (ntnode =20 > and fnode) do you know why? That's because NTFS allows multiple streams per file. The ntnode is =20 the per-file structure, and the fnode is the per-stream structure. -Mark From owner-freebsd-fs@FreeBSD.ORG Wed Jan 11 10:47:13 2006 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE7CB16A41F for ; Wed, 11 Jan 2006 10:47:13 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from geri.cc.fer.hr (geri.cc.fer.hr [161.53.72.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3486643D45 for ; Wed, 11 Jan 2006 10:47:12 +0000 (GMT) (envelope-from ivoras@fer.hr) Received: from geri.cc.fer.hr (localhost.cc.fer.hr [127.0.0.1]) by geri.cc.fer.hr (8.13.4/8.13.1) with ESMTP id k0BAivuo002302 for ; Wed, 11 Jan 2006 11:44:57 +0100 (CET) (envelope-from ivoras@fer.hr) Received: from localhost (ivoras@localhost) by geri.cc.fer.hr (8.13.4/8.13.1/Submit) with ESMTP id k0BAivPa002299 for ; Wed, 11 Jan 2006 11:44:57 +0100 (CET) (envelope-from ivoras@fer.hr) X-Authentication-Warning: geri.cc.fer.hr: ivoras owned process doing -bs Date: Wed, 11 Jan 2006 11:44:57 +0100 (CET) From: Ivan Voras Sender: ivoras@geri.cc.fer.hr To: freebsd-fs@freebsd.org Message-ID: <20060111114021.F2193@geri.cc.fer.hr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: ANN: TDFS X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2006 10:47:14 -0000 For future reference and list archive searching I'm announcing that I've put TDFS ("trivially distributed file system") on SourceForge at: http://sourceforge.net/projects/tdfs The .tar.gz archive mentioned in previous posting(s) contains a link to the new address. Comments, reviews and questions are welcome! -- Preserve wildlife -- pickle a squirrel today! From owner-freebsd-fs@FreeBSD.ORG Thu Jan 12 21:30:04 2006 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0296A16A41F for ; Thu, 12 Jan 2006 21:30:04 +0000 (GMT) (envelope-from user@dhp.com) Received: from shell.dhp.com (shell.dhp.com [199.245.105.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8307D43D69 for ; Thu, 12 Jan 2006 21:30:03 +0000 (GMT) (envelope-from user@dhp.com) Received: by shell.dhp.com (Postfix, from userid 896) id 44F4B312FA; Thu, 12 Jan 2006 16:30:02 -0500 (EST) Date: Thu, 12 Jan 2006 16:30:02 -0500 (EST) From: user To: freebsd-fs@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: preventing deadlocks in snapshot directories - unexplained X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2006 21:30:04 -0000 I have asked this before, but nobody answered ... If you have multiple snapshots, how do you segregate them in order to avoid the deadlocks that the ".snap" directory is supposed to fix ? I understand why a snapshot is created in (mount)/.snap - but what if I have multiple snapshots running simultaneously ? My instinct was that they just needed to be in different, non-recursive directories - like this: /.snap/snap1/snapshot_file /.snap/snap2/snapshot_file /.snap/snap3/snapshot_file However, I just noticed that when I: cd /.snap rm -rf snap3 the _entire_ /.snap directory locks up until that command completes. If I go in with another shell and: cd /.snap ls -asl that command hangs until the deletion of /.snap/snap3 completes. So, this leads me to conclude that actually, I need to do this: /.snap/snapshot_file /.snap2/snapshot_file /.snap3/snapshot_file Am I correct ? Why did my first strategy fail ? Why did /.snap lock up even when the snapshot files were a full directory level deeper ? Is there _anything else_ I should know about running multiple snapshots ? Thanks. From owner-freebsd-fs@FreeBSD.ORG Fri Jan 13 13:34:45 2006 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDE8C16A428 for ; Fri, 13 Jan 2006 13:34:45 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 52C4B43D4C for ; Fri, 13 Jan 2006 13:34:43 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (iforgf@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k0DDYa2n024958 for ; Fri, 13 Jan 2006 14:34:37 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k0DDYZEA024957; Fri, 13 Jan 2006 14:34:35 +0100 (CET) (envelope-from olli) Date: Fri, 13 Jan 2006 14:34:35 +0100 (CET) Message-Id: <200601131334.k0DDYZEA024957@lurza.secnetix.de> From: Oliver Fromme To: freebsd-fs@FreeBSD.ORG In-Reply-To: X-Newsgroups: list.freebsd-fs User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.11-STABLE (i386)) Cc: Subject: Re: preventing deadlocks in snapshot directories - unexplained X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-fs@FreeBSD.ORG List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2006 13:34:46 -0000 user wrote: > I have asked this before, but nobody answered ... Many people tend to be reluctant answering questions from anonymous users (or they don't bother reading their questions at all). > If you have multiple snapshots, how do you segregate them in order to > avoid the deadlocks that the ".snap" directory is supposed to fix ? As far as I know, using that directory is just a matter of convention. You can place snapshots anywhere else, and it doesn't make a difference. The only thing special about ".snap" is that it is created by default by newfs(1), and it is expected to exist by the snapshot support of the dump(8) and fsck(8) tools (for dumping live file systems and background fsck, respectively). > I understand why a snapshot is created in (mount)/.snap - but what if I > have multiple snapshots running simultaneously ? It doesn't make a difference. > 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, which can take quite some time, depending on the size of the file system, because a lot of data has to be updated. So, that blocking is to be expected (unfortunately). > So, this leads me to conclude that actually, I need to do this: > > /.snap/snapshot_file > /.snap2/snapshot_file > /.snap3/snapshot_file No, it doesn't make a difference. As far as I know, the snapshot code doesn't care about the directory name where the snapshot files are placed. 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. (On the statement print "42 monkeys" + "1 snake":) By the way, both perl and Python get this wrong. Perl gives 43 and Python gives "42 monkeys1 snake", when the answer is clearly "41 monkeys and 1 fat snake". -- Jim Fulton From owner-freebsd-fs@FreeBSD.ORG Fri Jan 13 14:39:55 2006 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B533B16A41F for ; Fri, 13 Jan 2006 14:39:55 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EECF43D8C for ; Fri, 13 Jan 2006 14:39:43 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id k0DEdfYe003418 for ; Fri, 13 Jan 2006 08:39:41 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <43C7BBAE.4040600@centtech.com> Date: Fri, 13 Jan 2006 08:39:42 -0600 From: Eric Anderson User-Agent: Thunderbird 1.5 (X11/20060112) MIME-Version: 1.0 To: freebsd-fs@freebsd.org References: <200601131334.k0DDYZEA024957@lurza.secnetix.de> In-Reply-To: <200601131334.k0DDYZEA024957@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1239/Thu Jan 12 05:36:22 2006 on mh1.centtech.com X-Virus-Status: Clean Subject: Re: preventing deadlocks in snapshot directories - unexplained X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2006 14:39:55 -0000 Oliver Fromme wrote: > user wrote: > > I have asked this before, but nobody answered ... > > Many people tend to be reluctant answering questions > from anonymous users (or they don't bother reading their > questions at all). > > > If you have multiple snapshots, how do you segregate them in order to > > avoid the deadlocks that the ".snap" directory is supposed to fix ? > > As far as I know, using that directory is just a matter of > convention. You can place snapshots anywhere else, and it > doesn't make a difference. The only thing special about > ".snap" is that it is created by default by newfs(1), and > it is expected to exist by the snapshot support of the > dump(8) and fsck(8) tools (for dumping live file systems > and background fsck, respectively). > > > I understand why a snapshot is created in (mount)/.snap - but what if I > > have multiple snapshots running simultaneously ? > > It doesn't make a difference. > > > 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, which > can take quite some time, depending on the size of the > file system, because a lot of data has to be updated. > So, that blocking is to be expected (unfortunately). > > > So, this leads me to conclude that actually, I need to do this: > > > > /.snap/snapshot_file > > /.snap2/snapshot_file > > /.snap3/snapshot_file > > No, it doesn't make a difference. As far as I know, the > snapshot code doesn't care about the directory name where > the snapshot files are placed. > 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. 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. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-fs@FreeBSD.ORG Fri Jan 13 17:54:38 2006 Return-Path: X-Original-To: freebsd-fs@FreeBSD.ORG Delivered-To: freebsd-fs@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1CE2916A41F for ; Fri, 13 Jan 2006 17:54:38 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F14D43D49 for ; Fri, 13 Jan 2006 17:54:36 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (uhktgb@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id k0DHsYnb033840 for ; Fri, 13 Jan 2006 18:54:35 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id k0DHsYuN033839; Fri, 13 Jan 2006 18:54:34 +0100 (CET) (envelope-from olli) Date: Fri, 13 Jan 2006 18:54:34 +0100 (CET) Message-Id: <200601131754.k0DHsYuN033839@lurza.secnetix.de> From: Oliver Fromme To: freebsd-fs@FreeBSD.ORG In-Reply-To: <43C7BBAE.4040600@centtech.com> X-Newsgroups: list.freebsd-fs User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.11-STABLE (i386)) Cc: Subject: Re: preventing deadlocks in snapshot directories - unexplained X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-fs@FreeBSD.ORG List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2006 17:54:38 -0000 Eric Anderson wrote: > Oliver Fromme wrote: > > user 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 From owner-freebsd-fs@FreeBSD.ORG Fri Jan 13 20:31:17 2006 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7ABC16A41F for ; Fri, 13 Jan 2006 20:31:17 +0000 (GMT) (envelope-from user@dhp.com) Received: from shell.dhp.com (shell.dhp.com [199.245.105.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6720143D45 for ; Fri, 13 Jan 2006 20:31:17 +0000 (GMT) (envelope-from user@dhp.com) Received: by shell.dhp.com (Postfix, from userid 896) id 53870312F5; Fri, 13 Jan 2006 15:31:16 -0500 (EST) Date: Fri, 13 Jan 2006 15:31:16 -0500 (EST) From: user To: freebsd-fs@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: RE: preventing deadlocks in snapshot directories - unexplained X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2006 20:31:18 -0000 I'm sorry - I misspoke in my original post, and I don't think I made clear what it was I was witnessing. What I am saying is, I have snapshots that exist _two_ directories deep off of the mount point, such as: /.snap/snap_directory1/snapshot /.snap/snap_directory2/snapshot and what I am seeing is, if I: cd /.snap (note, no snapshots in here) rm -rf snap_directory1/ (note, deleting a dir containing snapshot) What happens is, other operations inside of /.snap lock up. Which is contradictory to what I expected, and to what you have explained thus far in response to my original post (many thanks for those responses). Both you and I seem to expect that operations would only be locked for the /.snap/snap_directory1/ directory. I am going to try to reproduce this ... The "solution" I proposed was : /.snap/snapshot /.snap2/snapshot /.snap3/snapshot Which isn't much different, but it prevents the existence of a non-snapshot directory that could accidently be put into use, or be a pwd, or otherwise statted while a snapshot is deleted, etc. Any thoughts / comments ? From owner-freebsd-fs@FreeBSD.ORG Fri Jan 13 21:21:06 2006 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6CA3B16A41F for ; Fri, 13 Jan 2006 21:21:06 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F55443D46 for ; Fri, 13 Jan 2006 21:21:05 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id k0DLL3aJ010178; Fri, 13 Jan 2006 15:21:03 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <43C819C1.1060706@centtech.com> Date: Fri, 13 Jan 2006 15:21:05 -0600 From: Eric Anderson User-Agent: Thunderbird 1.5 (X11/20060112) MIME-Version: 1.0 To: user References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1240/Fri Jan 13 10:57:12 2006 on mh1.centtech.com X-Virus-Status: Clean Cc: freebsd-fs@freebsd.org Subject: Re: preventing deadlocks in snapshot directories - unexplained X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2006 21:21:06 -0000 user wrote: > I'm sorry - I misspoke in my original post, and I don't think I made clear > what it was I was witnessing. > > What I am saying is, I have snapshots that exist _two_ directories deep > off of the mount point, such as: > > /.snap/snap_directory1/snapshot > /.snap/snap_directory2/snapshot > > and what I am seeing is, if I: > > cd /.snap (note, no snapshots in here) > > rm -rf snap_directory1/ (note, deleting a dir containing snapshot) > > What happens is, other operations inside of /.snap lock up. Which is > contradictory to what I expected, and to what you have explained thus far > in response to my original post (many thanks for those responses). Both > you and I seem to expect that operations would only be locked for the > /.snap/snap_directory1/ directory. > > I am going to try to reproduce this ... > > The "solution" I proposed was : > > /.snap/snapshot > /.snap2/snapshot > /.snap3/snapshot > > Which isn't much different, but it prevents the existence of a > non-snapshot directory that could accidently be put into use, or be a pwd, > or otherwise statted while a snapshot is deleted, etc. > > Any thoughts / comments ? > What happens if you do: rm -f snap_directory1/snapshot rmdir snap_directory1 Does the same thing happen? Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------ From owner-freebsd-fs@FreeBSD.ORG Fri Jan 13 22:58:08 2006 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BFAD16A41F for ; Fri, 13 Jan 2006 22:58:08 +0000 (GMT) (envelope-from user@dhp.com) Received: from shell.dhp.com (shell.dhp.com [199.245.105.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22BEB43D48 for ; Fri, 13 Jan 2006 22:58:04 +0000 (GMT) (envelope-from user@dhp.com) Received: by shell.dhp.com (Postfix, from userid 896) id 9741B312F5; Fri, 13 Jan 2006 17:57:59 -0500 (EST) Date: Fri, 13 Jan 2006 17:57:59 -0500 (EST) From: user To: Eric Anderson In-Reply-To: <43C819C1.1060706@centtech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-fs@freebsd.org Subject: Re: preventing deadlocks in snapshot directories - unexplained X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2006 22:58:08 -0000 On Fri, 13 Jan 2006, Eric Anderson wrote: > What happens if you do: > > rm -f snap_directory1/snapshot > rmdir snap_directory1 > > Does the same thing happen? I will try that as I try to reproduce the problem. I am aware that there are two "lags" when creating a snapshot - the lock that occurs in the snapshot directory for the entire course of creation/destruction, and also a short system-wide lag that occurs for a small portion of the time of creation/destruction. It is possible that on a heavily taxed system, the two could be confused for one another, which is possibly what happened when I noticed the one-deep directory "locking" when I deleted a two-deep directory snapshot. I think the main, conceptual question I am asking is this - what is the difference between these three strategies: #1: /.snap/snapshot1 /.snap/snapshot2 /.snap/snapshot3 #2 /.snap/snapdir1/snapshot1 /.snap/snapdir2/snapshot2 /.snap/snapdir3/snapshot3 #3 /.snap/snapshot1 /.snap2/snapshot2 /.snap3/snapshot3 Now, so far in this thread, some have claimed that #2 and #3 are identical, which seems reasonable. My only problem is that I _think_ I am seeing problems with #2. We'll see. However, what about #1 above ? In that case, all of the snapshots are in one directory, and I feel that this is dangerous, or at least poorly done - isn't there a very real possibility of a deadlock there, because you could be creating a snapshot in /.snap at the same time as you delete one (or create a different one ?) The man page says nothing about multiple snapshots, etc., and I want to know if, one way or another, it is a good instinct on my part to make sure multiple snapshots do not end up in the exact same directory... thanks. From owner-freebsd-fs@FreeBSD.ORG Sat Jan 14 10:11:54 2006 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CB2A416A41F for ; Sat, 14 Jan 2006 10:11:54 +0000 (GMT) (envelope-from bp@vertex.kz) Received: from relay.vertex.kz (relay.vertex.kz [212.19.129.142]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0668743D45 for ; Sat, 14 Jan 2006 10:11:53 +0000 (GMT) (envelope-from bp@vertex.kz) Received: from lion.butya.kz (localhost [127.0.0.1]) by relay.vertex.kz (Postfix) with SMTP id 5DA035CA0; Sat, 14 Jan 2006 16:11:51 +0600 (ALMT) Received: from relay.vertex.kz (localhost [127.0.0.1]) by localhost.vertex.kz (Postfix) with ESMTP id 34F655B48; Sat, 14 Jan 2006 16:11:51 +0600 (ALMT) Received: by relay.vertex.kz (Postfix, from userid 1000) id 2C6DC5B47; Sat, 14 Jan 2006 16:11:51 +0600 (ALMT) Date: Sat, 14 Jan 2006 16:11:51 +0600 From: Boris Popov To: Victor Snezhko Message-ID: <20060114101151.GT99226@vertex.kz> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6i Cc: freebsd-fs@freebsd.org Subject: Re: mount_smbfs, windows 2003 domain shares and NETSMBCRYPTO X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2006 10:11:54 -0000 On Mon, Jan 09, 2006 at 09:06:57PM +0600, Victor Snezhko wrote: > > I went to dig into sources and found that option NETSMBCRYPTO is a > solution. On my -current box it is the only option that needs to be > added to make things work. > > Hope this message will be more helpful than bullshit about turning > off signing on DC (it works, but it's just not right). > > Couple of questions: > > 1) Would it be right to include this hint to a mount_smbfs manpage? > I could prepare a patch and send it to the doc@ maillist. I think so. > > 2) Is there a reason for this option not being in GENERIC? It's > absence makes mount_smbfs in conjunction with default kernel more > and more useless (as time passes and more domain controllers jump > to windows 2003). There can be some restrictions with supplying cryptography in the GENERIC config, but I'm not the right person to answer such questions. -- Boris Popov From owner-freebsd-fs@FreeBSD.ORG Sat Jan 14 12:23:54 2006 Return-Path: X-Original-To: freebsd-fs@freebsd.org Delivered-To: freebsd-fs@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 666F416A41F for ; Sat, 14 Jan 2006 12:23:54 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C019443D45 for ; Sat, 14 Jan 2006 12:23:53 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.25] ([192.168.42.25]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id k0ECNpAd035802; Sat, 14 Jan 2006 06:23:51 -0600 (CST) (envelope-from anderson@centtech.com) Message-ID: <43C8ED57.4070605@centtech.com> Date: Sat, 14 Jan 2006 06:23:51 -0600 From: Eric Anderson User-Agent: Thunderbird 1.5 (X11/20060112) MIME-Version: 1.0 To: user References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1241/Sat Jan 14 04:00:03 2006 on mh2.centtech.com X-Virus-Status: Clean Cc: freebsd-fs@freebsd.org Subject: Re: preventing deadlocks in snapshot directories - unexplained X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2006 12:23:54 -0000 user wrote: > On Fri, 13 Jan 2006, Eric Anderson wrote: > > >> What happens if you do: >> >> rm -f snap_directory1/snapshot >> rmdir snap_directory1 >> >> Does the same thing happen? >> > > > I will try that as I try to reproduce the problem. > > I am aware that there are two "lags" when creating a snapshot - the lock > that occurs in the snapshot directory for the entire course of > creation/destruction, and also a short system-wide lag that occurs for a > small portion of the time of creation/destruction. > > It is possible that on a heavily taxed system, the two could be confused > for one another, which is possibly what happened when I noticed the > one-deep directory "locking" when I deleted a two-deep directory snapshot. > The second lag you are talking about is when writes are suspended to that particular filesystem, which is so brief, it's unlikely you noticed it. > I think the main, conceptual question I am asking is this - what is the > difference between these three strategies: > > #1: > > /.snap/snapshot1 > /.snap/snapshot2 > /.snap/snapshot3 > > #2 > > /.snap/snapdir1/snapshot1 > /.snap/snapdir2/snapshot2 > /.snap/snapdir3/snapshot3 > > #3 > > /.snap/snapshot1 > /.snap2/snapshot2 > /.snap3/snapshot3 > > > Now, so far in this thread, some have claimed that #2 and #3 are > identical, which seems reasonable. My only problem is that I _think_ I am > seeing problems with #2. We'll see. > > However, what about #1 above ? In that case, all of the snapshots are in > one directory, and I feel that this is dangerous, or at least poorly done > - isn't there a very real possibility of a deadlock there, because you > could be creating a snapshot in /.snap at the same time as you delete one > (or create a different one ?) > > The man page says nothing about multiple snapshots, etc., and I want to > know if, one way or another, it is a good instinct on my part to make sure > multiple snapshots do not end up in the exact same directory... > I'm not certain why it hangs for you - seems like I've been through this, and I could do some testing also next week. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------