From owner-freebsd-current@FreeBSD.ORG Fri Mar 17 00:34:58 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6868C16A420 for ; Fri, 17 Mar 2006 00:34:58 +0000 (UTC) (envelope-from dmitry@atlantis.dp.ua) Received: from postman.atlantis.dp.ua (postman.atlantis.dp.ua [193.108.47.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE3CB43D45 for ; Fri, 17 Mar 2006 00:34:57 +0000 (GMT) (envelope-from dmitry@atlantis.dp.ua) Received: from smtp.atlantis.dp.ua (smtp.atlantis.dp.ua [193.108.46.231]) by postman.atlantis.dp.ua (8.13.1/8.13.1) with ESMTP id k2H0YsCx080184 for ; Fri, 17 Mar 2006 02:34:54 +0200 (EET) (envelope-from dmitry@atlantis.dp.ua) Date: Fri, 17 Mar 2006 02:34:54 +0200 (EET) From: Dmitry Pryanishnikov To: freebsd-current@freebsd.org Message-ID: <20060317012428.N52721@atlantis.atlantis.dp.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [patch] NetBSD disklabel support for geom_bsd X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2006 00:34:58 -0000 Hello! I've installed NetBSD 3.0 recently on the same HDD with FreeBSD-CURRENT and found that OSes just don't see each other's partitions. I thought that it would be convenient for FreeBSD developers if FreeBSD were able to understand NetBSD's disklabel as we borrow their code occasionally ;) After detailed analysis I understood the difference between disklabel formats: they are essentially the same except 2 points: 1) NetBSD people extended partition table to 16 entries vs. our 8. That's OK, we have place for 22 entries within 512-byte sector for disklabel offset 0, and 18 for offset 64 bytes (Alpha's case). 2) (most important) NetBSD disklabel describes partitions not slice-relative (like ours), but the whole device-relative. They have no slice devices, so their disklabel actually duplicates functionality of device slice table, and describes both NetBSD partitions and other slices as partitions. E.g., for my HDD I've got the following NetBSD disklabel: 16 partitions: # size offset fstype [fsize bsize cpg/sgs] a: 2097648 147942585 4.2BSD 2048 16384 21872 b: 2097648 150040233 swap c: 81931500 147942585 unused 0 0 d: 312579695 0 unused 0 0 e: 2088387 63 MSDOS f: 61440624 152137881 4.2BSD 2048 16384 28704 g: 10150560 213578505 4.2BSD 2048 16384 28456 and so on. So, from the FreeBSD's POV the only useful information from NetBSD disklabel are the entries which point within NetBSD slice (in my example, a-c,f,g). Others already have FreeBSD's counterparts (my NetBSD slice is ad0s3, but partition 'd' describes the whole ad0, and 'e' == ad0s1), and it would be wrong and even dangerous to keep them. I've created simple patches against geom_bsd.c for CURRENT and RELENG_6: ftp://external.atlantis.dp.ua/FreeBSD/geom_bsd/CURRENT.diff ftp://external.atlantis.dp.ua/FreeBSD/geom_bsd/RELENG_6.diff which implement recognition of NetBSD disklabel only on slicer level (no support for ioctls == no support for bsdlabel), but IMHO that's enough - rest can be done from the NetBSD itself. My patches are quite simple: 1. g_bsd_try() modified to accept large (>8) number of partitions; 2. g_bsd_taste() accepts NetBSD's slice type 169 and does special processing for it: truncates partition table to 8 entries, converts offsets from absolute to slice-relative, and removes entries which describe areas outside the NetBSD slice. I have verified these patches against 2 different NetBSD partition layouts, they work as expected (for the shown case, create ad0s3a-c, ad0s3f-g). The only drawback in my solution is that only first 8 partitions (of currently 16 NetBSD's) can be represented. If you'll create separate /, /usr, /var, /home and user-defined partition during NetBSD install, they'll be: 'a', 'f', 'g', 'h' and 'm' for my HDD layout, and 'm' will be unreachable from the FreeBSD. I could remap it to the free slot (e.g. 'd'), but I've decided not to do it, because it could add confusion IMHO. After all, both slices (FreeBSD and NetBSD) are usually managed by the same person, so [s]he'll create reasonable NetBSD partition layout. I hope my patch can be useful, and would like to get feedback about it. Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE