From owner-svn-src-head@freebsd.org Mon Aug 28 18:24:39 2017 Return-Path: Delivered-To: svn-src-head@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 7AB88E11A3A for ; Mon, 28 Aug 2017 18:24:39 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 40AF28396E for ; Mon, 28 Aug 2017 18:24:39 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-vk0-x22c.google.com with SMTP id s199so3696748vke.1 for ; Mon, 28 Aug 2017 11:24:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sippysoft-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=33tc/8SmD62NIxEHBQbMDYjAquR8JhJxLrr6RlZ2wA4=; b=XDAMqJdzybrbrPb4rT5aFP8u2GCjEPnXrQDr/5JP2Z8/KvITuphUhPVYr4k6j8IhaS WixvH5kDGu0CwWVHdYIzpu5mR5o8GZLHgsewMEj5MmOfzuT4PqZcLzavegkEbdjGS8TW sOAUOdTcYCo/qYNACN1suYA2J3kWZBX5Api4bDm6yrCSj/ro6GJ0PrUV9eqdXe8wVoho u4O4elI0a9KLy74iBeeffXwLolCigJw1/DX8C3n8j9+er1a2tSWHhrq3QOUdgas3mDIq eyxqC7m9cYCmAY34eQdKztmLXiHrEFk9GSm0vp9U8P4dz6IiLrDXgIUOL3jgP4rbYO4Z 3/OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=33tc/8SmD62NIxEHBQbMDYjAquR8JhJxLrr6RlZ2wA4=; b=kS28Pp5+h+5VRkiBwj/zMeCQdUum3ojfbs9nOwwNHMdcLUIzVuxcLFuPD8HAGP4svJ K67OdkgtYUym0cUROUsS9CS21GglaLBAxOMfZKuoKajEtQE4NJ0Jei5IpadIIdJdjy/o dfqpfl2Jde6AA3VcU5npWD3cTdji1N7SX1FPGvfteftVeQlxVJaOwDbHGPPobw+nnm3U IguQTYuSxG7OnIUDxmVz9IPTbWtVcyJt5S+KsAgNatgDRmrrVGYDK4LdpBrcz3UyYX1Q eb2kyKxgmrqx+SE1okCZ3YWgQT8ARJE2Oym026uHdGaIo3w4ifBf7ZwBAIdesY3GA/5/ mq3g== X-Gm-Message-State: AHYfb5iMK0BgBeuRcxdYeDD1PuMYbj0eq+eIGu15HHlgVpMxoH1ZXjGz x5voJcxf37FpveSnM0EtvOFjxX59m6gq X-Received: by 10.31.96.212 with SMTP id u203mr932580vkb.30.1503944678132; Mon, 28 Aug 2017 11:24:38 -0700 (PDT) MIME-Version: 1.0 Sender: sobomax@sippysoft.com Received: by 10.176.6.137 with HTTP; Mon, 28 Aug 2017 11:24:37 -0700 (PDT) In-Reply-To: <7384187.efIiCynxO3@ralph.baldwin.cx> References: <201708281554.v7SFs8fr014268@repo.freebsd.org> <7384187.efIiCynxO3@ralph.baldwin.cx> From: Maxim Sobolev Date: Mon, 28 Aug 2017 11:24:37 -0700 X-Google-Sender-Auth: -MTBsSe3_zRIIXTweq-5Ytgv0Ew Message-ID: Subject: Re: svn commit: r322969 - in head: sbin/mdconfig sys/dev/md sys/sys To: John Baldwin Cc: src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Aug 2017 18:24:39 -0000 Hi John, Thanks for your feedback! To address the points that you've raised: 1. I've tested on both 32 and 64 bit platforms, it seems not to be the case. See imp's comment and my reply here https://reviews.freebsd.org/D10457#216855 . Did I miss something? Can you post piece of C code that produces different sizeof(struct old) vs. sizeof(struct new) on some platform? 2. I disagree with the suggested direction, we specifically devised those to be "labels" not names. I.e. arbitrary description that may or may not be unique across the group of devices. This way we label devices linked to the build #X as such and then can bulk deallocate them if the build is found to be dead. If there is a need for some expressive symbolical id to supplement mdX with proper mapping into the /dev/md/* space that would be a separate attribute ({name,devname,nodename}?) in my view completely orthogonal to this one. Could be a nice feature on its own though, no doubt about it. -Max On Mon, Aug 28, 2017 at 9:19 AM, John Baldwin wrote: > On Monday, August 28, 2017 03:54:08 PM Maxim Sobolev wrote: > > Author: sobomax > > Date: Mon Aug 28 15:54:07 2017 > > New Revision: 322969 > > URL: https://svnweb.freebsd.org/changeset/base/322969 > > > > Log: > > Add ability to label md(4) devices. > > > > This feature comes from the fact that we rely memory-backed md(4) > > in our build process heavily. However, if the build goes haywire > > the allocated resources (i.e. swap and memory-backed md(4)'s) need > > to be purged. It is extremely useful to have ability to attach > > arbitrary labels to each of the virtual disks so that they can > > be identified and GC'ed if neecessary. > > > > MFC after: 4 weeks > > Differential Revision: https://reviews.freebsd.org/D10457 > > > > Modified: > > head/sbin/mdconfig/mdconfig.8 > > head/sbin/mdconfig/mdconfig.c > > head/sys/dev/md/md.c > > head/sys/sys/mdioctl.h > > > > Modified: head/sys/sys/mdioctl.h > > ============================================================ > ================== > > --- head/sys/sys/mdioctl.h Mon Aug 28 14:49:26 2017 (r322968) > > +++ head/sys/sys/mdioctl.h Mon Aug 28 15:54:07 2017 (r322969) > > @@ -49,7 +49,7 @@ enum md_types {MD_MALLOC, MD_PRELOAD, MD_VNODE, MD_SWA > > * Ioctl definitions for memory disk pseudo-device. > > */ > > > > -#define MDNPAD 97 > > +#define MDNPAD 96 > > struct md_ioctl { > > unsigned md_version; /* Structure layout version */ > > unsigned md_unit; /* unit number */ > > @@ -61,6 +61,7 @@ struct md_ioctl { > > u_int64_t md_base; /* base address */ > > int md_fwheads; /* firmware heads */ > > int md_fwsectors; /* firmware sectors */ > > + char *md_label; /* label of the device */ > > int md_pad[MDNPAD]; /* padding for future ideas */ > > }; > > This isn't correct on 64-bit platforms. MDNPAD needs to be 95 on those > platforms. > > It would be really neat if one could use the label more pervasively. For > example, it would be nice to do something like this: > > # mdconfig -a -t malloc -s 16M -L foo > # newfs /dev/md/foo > # mdconfig -d -L foo > > This would mean that labelled memory disks would not create /dev/mdX > entries, but would instead create /dev/md/