From owner-freebsd-questions@freebsd.org Thu Sep 10 22:03:06 2015 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C23EAA02AAF for ; Thu, 10 Sep 2015 22:03:06 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) Received: from alogt.com (alogt.com [69.36.191.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9FFF11778 for ; Thu, 10 Sep 2015 22:03:06 +0000 (UTC) (envelope-from erichsfreebsdlist@alogt.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=alogt.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-ID:Subject:To:From:Date; bh=ODsA8Qr1PgKsfRt/g2PO0+TJD3pnjqIxLE3t7Yr/Ak4=; b=ZJj1AoTcpx/i3SchDN6WRL+a9tu8pSdn5xJ7HjsAhhzzstQYH0TJmIDDk+8ra/+5Tkrc1EuZowsXaZOW1Rx6cdmqWNEipSSb0g2ixVsz/9GIh/44ei4bH8wb5YJpbR/obwfeu6Inlw5KDsc8xD6Y09iaoC4Jr3p8ubvCDtuZe0w=; Received: from [114.124.29.181] (port=23245 helo=X220.alogt.com) by sl-508-2.slc.westdc.net with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.85) (envelope-from ) id 1Za9vl-000bVi-64 for freebsd-questions@freebsd.org; Thu, 10 Sep 2015 16:03:04 -0600 Date: Fri, 11 Sep 2015 06:02:51 +0800 From: Erich Dollansky To: freebsd-questions@freebsd.org Subject: Re: mdconfig creating file based memory disk Message-ID: <20150911060251.5cd303ba@X220.alogt.com> In-Reply-To: References: <20150910111034.20b97c41@X220.alogt.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sl-508-2.slc.westdc.net X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alogt.com X-Get-Message-Sender-Via: sl-508-2.slc.westdc.net: authenticated_id: erichsfreebsdlist@alogt.com X-Source: X-Source-Args: X-Source-Dir: X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2015 22:03:07 -0000 Hi, On Thu, 10 Sep 2015 13:44:18 -0400 "Chad J. Milios" wrote: > > On Sep 9, 2015, at 11:10 PM, Erich Dollansky > > wrote: > > > > I just came across a simple question. What will happen when I create > > two memory disks using the same file? > > > > Example: > > > > mdconfig -f /usr/home/swap/swapfile -u 0 > > mdconfig -f /usr/home/swap/swapfile -u 1 > > > > and then I do a > > > > swapon /dev/md0 > > swapon /dev/md1 > > > > It gives me double the size of 'swapfile' as swap space. It is > > obvious to me that this must fail. > > > > Shouldn't there be a note in the documentation? > > Perhaps, but if we documented every way in which FreeBSD allows one > to shoot oneself in the foot, the docs would probably more than > triple in size. :) > > This is an interesting experiment but I can't imagine anyone inviting > the danger while actually expecting to get away with such a the experiment started after I did not find any information if mdconfig will lock the file. If the file would be locked, nothing would happen. The problems happens with any other scenario in which a file is used as the base for the memory disk. It just happened that I needed the swap. The problem is that the software using the memory disk has to way to find out if it is the sole user. It is just the scenario you are describing. > Imagine the following analog: a hypothetical database software which > mmap()s a file possibly larger than physical memory to rely on the VM > > So without inspecting the relevant kernel source myself, based on the > little experiment you've conducted, I can imagine the swap perhaps Swap is not the problem. Swap must rely on the space it got assigned to have it exclusively. > > On the outset of the experiment you describe, my expectation was > almost certain spectacular failure. Anything else actually is quite > curious and if such a config doesn't just burst right into flames I > consider it quite a testament to sound *nix engineering. I'd be > interested to hear someone exercise it with more swapping out and > paging in of data and verifying the data and semantics. I did this other test with normally mounted file systems. As it is one file, what happens in one file system, is mirrored into the other one. mdconfig is the bottle neck. If mdconfig would lock the file for exclusive access, this would not happen. I should have a lock at the sources when time permits this. Erich