From owner-freebsd-geom@FreeBSD.ORG Sun Apr 15 07:04:39 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4FA2116A400; Sun, 15 Apr 2007 07:04:39 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [83.98.131.211]) by mx1.freebsd.org (Postfix) with ESMTP id E3BCF13C45B; Sun, 15 Apr 2007 07:04:38 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id CEE0E1CC40; Sun, 15 Apr 2007 09:04:36 +0200 (CEST) Date: Sun, 15 Apr 2007 09:04:36 +0200 From: Ed Schouten To: Rink Springer Message-ID: <20070415070436.GQ81821@hoeg.nl> References: <20070414115959.GN81821@hoeg.nl> <20070414160629.GA82214@rink.nu> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CfiwpigK2vfmwpN3" Content-Disposition: inline In-Reply-To: <20070414160629.GA82214@rink.nu> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Laurens Timmermans , FreeBSD GEOM Subject: Re: New GEOM module: geom_xboxhd X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2007 07:04:39 -0000 --CfiwpigK2vfmwpN3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Rink Springer wrote: > Some comments: >=20 > (1) g_xboxhd_checkmagic(): You look at uint32_t* buf, which you have just > g_free()'d; this seems wrong. I know this is debugging code, but you > could just get rid of these lines all the same ;-) Thanks. Fixed that. :) > (2) I consider the for-loop in line 125 a bit kludgy - why not add all > 'standard' partitions (of which you know they are always there) in > this loop, and if the disk was larger, add a final paritition > containing the rest? This makes the code prettier to read, in my > opinion. I now took a different approach; I added OFF_MAX to the offsets[] list, so the scratch space can also be added the same way as the other partitions. > (3) This may be personal preference, but I consider a check of 4 bytes on > address 0x600 a bit weak - usually, the first 63 sectors or so after = the > boot sector are skipped during partitioning (most general boot > managers reside there), so there may be no telling what's in there. > However, there doesn't seem to be a better way to identify Xbox > harddisks, which makes me wonder whether we should keep this in the X= BOX > kernel config file only, possibly commented out in LINT. We could also check the magic of the Xbox partitions. The first 4 bytes of the partitions should always be "FATX". I personally do not favour this, because that would mean this module won't match if you newfs one of the Xbox partitions by accident. Adding it to LINT wouldn't hurt, because LINT is only used for compile-time testing, right? > Anyway, apart from this, it looks functional and something the xbox port > could very well use. I'd like to get this in the tree, so people with > more geom-fu are very welcome to take a look! >=20 > Have you tried what sysinstall(8) does when it sees such a layout? It'd > be a shame if it nuked the partition table... :-) Not yet :-) --=20 Ed Schouten WWW: http://g-rave.nl/ --CfiwpigK2vfmwpN3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGIc6E52SDGA2eCwURAnxHAJ49M2Ixr3RV/cDXnQ6rL7Ifso+RWwCfQWPj XYIs0cSu7fcglQRKfb/iyaY= =Tata -----END PGP SIGNATURE----- --CfiwpigK2vfmwpN3-- From owner-freebsd-geom@FreeBSD.ORG Sun Apr 15 11:17:06 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 31EA716A400; Sun, 15 Apr 2007 11:17:06 +0000 (UTC) (envelope-from rink@thunderstone.rink.nu) Received: from mx1.rink.nu (thunderstone.rink.nu [80.112.228.34]) by mx1.freebsd.org (Postfix) with ESMTP id E45FB13C46E; Sun, 15 Apr 2007 11:17:05 +0000 (UTC) (envelope-from rink@thunderstone.rink.nu) Received: from localhost (localhost [127.0.0.1]) by mx1.rink.nu (Postfix) with ESMTP id BB655D4C5D; Sun, 15 Apr 2007 13:13:28 +0200 (CEST) X-Virus-Scanned: amavisd-new at rink.nu Received: from mx1.rink.nu ([127.0.0.1]) by localhost (thunderstone.rink.nu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GwZ5by9PimAh; Sun, 15 Apr 2007 13:13:20 +0200 (CEST) Received: from thunderstone.rink.nu (localhost [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.rink.nu (Postfix) with ESMTP id A5B17D4C5C; Sun, 15 Apr 2007 13:13:20 +0200 (CEST) Received: (from rink@localhost) by thunderstone.rink.nu (8.13.8/8.13.8/Submit) id l3FBDK7h098180; Sun, 15 Apr 2007 13:13:20 +0200 (CEST) (envelope-from rink) Date: Sun, 15 Apr 2007 13:13:20 +0200 From: Rink Springer To: Ed Schouten Message-ID: <20070415111320.GA94418@rink.nu> References: <20070414115959.GN81821@hoeg.nl> <20070414160629.GA82214@rink.nu> <20070415070436.GQ81821@hoeg.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070415070436.GQ81821@hoeg.nl> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: dwight@berendse.org, Rink Springer , Laurens Timmermans , FreeBSD GEOM Subject: Re: New GEOM module: geom_xboxhd X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2007 11:17:06 -0000 Hi Ed, On Sun, Apr 15, 2007 at 09:04:36AM +0200, Ed Schouten wrote: > > Have you tried what sysinstall(8) does when it sees such a layout? It'd > > be a shame if it nuked the partition table... :-) > > Not yet :-) A friend of mine, Dwight Berendse (added to CC), has just tried this using my soon-to-be-released new 6-STABLE FreeBSD/xbox CD. It worked nicely on a newly-prepared Xbox harddisk, but sysinstall(8) does not use the information. A quick inspection (Argh, I should study and not code, dammit...) yields that libdisk(3) actually ignores the XBOXHD partitions (refer to /usr/src/lib/libdisk/open_disk.c); and thus, sysinstall(8) will not see them. Therefore, even though the module works, I think we'd need some extra effort to make this behave nicely with sysinstall(8) :-/ Regards, -- Rink P.W. Springer - http://rink.nu "It is such a quiet thing, to fall. But yet a far more terrible thing, to admit it." - Darth Traya From owner-freebsd-geom@FreeBSD.ORG Sun Apr 15 12:53:14 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EC89216A402; Sun, 15 Apr 2007 12:53:14 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [83.98.131.211]) by mx1.freebsd.org (Postfix) with ESMTP id B4ACF13C483; Sun, 15 Apr 2007 12:53:14 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 108DE1CC42; Sun, 15 Apr 2007 14:53:13 +0200 (CEST) Date: Sun, 15 Apr 2007 14:53:13 +0200 From: Ed Schouten To: Rink Springer , dwight@berendse.org Message-ID: <20070415125313.GS81821@hoeg.nl> References: <20070414115959.GN81821@hoeg.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IfZ+tgy+ooJOsAAy" Content-Disposition: inline In-Reply-To: <20070414115959.GN81821@hoeg.nl> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: Laurens Timmermans , FreeBSD GEOM Subject: Re: New GEOM module: geom_xboxhd X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2007 12:53:15 -0000 --IfZ+tgy+ooJOsAAy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Ed Schouten wrote: > Linux has an evil hack to work around this; they have modified the x86 > partition table code to start at 7645MB and create some device nodes > (hda51 to hda55) which represent the partitions from the Xbox itself. I > just wrote a GEOM module that just generates ad0s1 to ad0s5 and when the > disk is big enough an ad0s6. After some more research; it looks like we don't need to modify sysinstall to make it work on the Microsoft Xbox. The Linux folks do write the MBR at the beginning of the disk and hope that the original software doesn't touch it afterwards (which it doesn't). The first partition in the partition table always starts at 15633072 sectors. So I just altered the GEOM_XBOXHD module to not create our scratch space at the end. We always create 5 slices, pointing to the partitions used by the Microsoft Xbox itself. You don't really need the module, but it could come in handy for folks who want to tamper around with FATX. When you install FreeBSD, go to the partitioning dialog and create a partition with a size of 15633072 sectors. Then create a second partition after that and delete the first one. You should do something like this: http://g-rave.nl/junk/freebsd-xbox-partition.png When done, install FreeBSD like you normally do. When done, the contents of /dev/ should look like this: | $ ls -l /dev/ad0?? | crw-r----- 1 root operator 0, 94 Apr 15 14:27 /dev/ad0s2 | crw-r----- 1 root operator 0, 118 Apr 15 14:27 /dev/ad0x1 | crw-r----- 1 root operator 0, 119 Apr 15 14:27 /dev/ad0x2 | crw-r----- 1 root operator 0, 120 Apr 15 14:27 /dev/ad0x3 | crw-r----- 1 root operator 0, 121 Apr 15 14:27 /dev/ad0x4 | crw-r----- 1 root operator 0, 122 Apr 15 14:27 /dev/ad0x5 The s2 is the partition with FreeBSD and x[1-5] are the slices which contain the Xbox filesystems. Rink/Dwight, can you create a new install CD with the latest geom_xboxhd module and test whether you're able to install an Xbox with FreeBSD, which still boots the original software and FreeBSD after the installation? We should probably write a HOWTO when all of this works. I know it's a dirty approach, but it's compatible with Xbox-Linux, which also means it should probably work with an unmodified version of Cromwell. You should also be able to create a system that can still start games, boot Linux and FreeBSD as well. Yours, --=20 Ed Schouten WWW: http://g-rave.nl/ --IfZ+tgy+ooJOsAAy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGIiA552SDGA2eCwURAidtAJ4j4hAbHFdWjnsAT8w1kAlynx+eUACeJiON JZd5lyqoUyyKwksxoLZ0ck8= =bDdT -----END PGP SIGNATURE----- --IfZ+tgy+ooJOsAAy-- From owner-freebsd-geom@FreeBSD.ORG Sun Apr 15 19:09:55 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 733CA16A400 for ; Sun, 15 Apr 2007 19:09:55 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: from palm.hoeg.nl (mx0.hoeg.nl [83.98.131.211]) by mx1.freebsd.org (Postfix) with ESMTP id 3C19A13C480 for ; Sun, 15 Apr 2007 19:09:55 +0000 (UTC) (envelope-from ed@hoeg.nl) Received: by palm.hoeg.nl (Postfix, from userid 1000) id 9D45B1CC2A; Sun, 15 Apr 2007 21:09:53 +0200 (CEST) Date: Sun, 15 Apr 2007 21:09:53 +0200 From: Ed Schouten To: Rene Ladan Message-ID: <20070415190953.GA98082@hoeg.nl> References: <20070414115959.GN81821@hoeg.nl> <46227755.6010208@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7AUc2qLy4jB3hD7Z" Content-Disposition: inline In-Reply-To: <46227755.6010208@gmail.com> User-Agent: Mutt/1.5.15 (2007-04-06) Cc: freebsd-geom@freebsd.org Subject: Re: New GEOM module: geom_xboxhd X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2007 19:09:55 -0000 --7AUc2qLy4jB3hD7Z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Rene Ladan wrote: > Can you confirm that the slices are created if you first plug in the > xbox harddisk and kldload the module afterwards? I once wrote a GEOM > module to slice xbox360 media (kern/107707), which only works if you > first kldload it and _then_ plug in the media. This is caused by > pp->mediasize =3D=3D 0 in the taste function. Yes, it works. The only problem is that kldloading without disconnecting the md deadlocks my machine because I guess it is indefinately waiting for all dependencies to disappear. > Note that you'll need a physical harddisk for the test because the > behaviour is always correct when using md images. I suspect that the > bug is near /sys/cam/scsi/scsi_da.c It works in both cases. I performed tests on a 10 GB disk afterwards. Thanks for the tips :-) --=20 Ed Schouten WWW: http://g-rave.nl/ --7AUc2qLy4jB3hD7Z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGIniB52SDGA2eCwURAvjmAJ0VjATJJ87AMdA/WljC5o7QH2IfAQCeOUM2 k/mdDr+5pw8FLIrpPkFezQ0= =bTjH -----END PGP SIGNATURE----- --7AUc2qLy4jB3hD7Z-- From owner-freebsd-geom@FreeBSD.ORG Sun Apr 15 19:21:29 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 511F016A415 for ; Sun, 15 Apr 2007 19:21:29 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.freebsd.org (Postfix) with ESMTP id AF63013C4BD for ; Sun, 15 Apr 2007 19:21:28 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so796564ugh for ; Sun, 15 Apr 2007 12:21:27 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=h2UN81GjkMVOXVDiNXNBr2SBcxtE/yKt59Iv2bEDoAny47vtKgiW4YcRfvqaV2uBdeF1tgOpsQHTWSgC4w6MPctUj8lQd190LvOCvGJnDnJuExcUVYnFNnTAU4DhKW11L2crKM4+yV1V+sHSGt1VIDrTXM02MX2w9JQrtYIQZ+Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=OoHhdoiV6F89jyj8khbGAvQKDhWQPHzsHY5/aSuFGsPlAvnmv93dUH5HmZNQqcovwt0RD6ImQz3lC0DZFoEGY0pT17EDQNlcy1dW/wPTfjaEQZc7s2TkmNUrG8JPfhcI45njKVku9gZg7gtD+Ie9NVYYweKF0l6FMcDXq3Togas= Received: by 10.67.96.1 with SMTP id y1mr3743039ugl.1176664887787; Sun, 15 Apr 2007 12:21:27 -0700 (PDT) Received: from ?192.168.123.202? ( [195.241.221.201]) by mx.google.com with ESMTP id 34sm5705507uga.2007.04.15.12.21.26; Sun, 15 Apr 2007 12:21:27 -0700 (PDT) Message-ID: <46227B36.7020805@gmail.com> Date: Sun, 15 Apr 2007 21:21:26 +0200 From: Rene Ladan User-Agent: Thunderbird 1.5.0.10 (X11/20070320) MIME-Version: 1.0 To: Ed Schouten References: <20070414115959.GN81821@hoeg.nl> <46227755.6010208@gmail.com> <20070415190953.GA98082@hoeg.nl> In-Reply-To: <20070415190953.GA98082@hoeg.nl> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-geom@freebsd.org Subject: Re: New GEOM module: geom_xboxhd X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2007 19:21:29 -0000 Ed Schouten schreef: > * Rene Ladan wrote: >> Can you confirm that the slices are created if you first plug in the >> xbox harddisk and kldload the module afterwards? I once wrote a GEOM >> module to slice xbox360 media (kern/107707), which only works if you >> first kldload it and _then_ plug in the media. This is caused by >> pp->mediasize == 0 in the taste function. > > Yes, it works. The only problem is that kldloading without disconnecting > the md deadlocks my machine because I guess it is indefinately waiting > for all dependencies to disappear. > >> Note that you'll need a physical harddisk for the test because the >> behaviour is always correct when using md images. I suspect that the >> bug is near /sys/cam/scsi/scsi_da.c > > It works in both cases. I performed tests on a 10 GB disk afterwards. > Thanks for the tips :-) > Strange... in my case loading the module afterwards didn't work either when burning the image to a CD-RW and using that CD as the physical medium. That was back in January 2007. Both geom_xboxhd and geom_xbox360 check pp->mediasize in their taste functions right after setting up the GEOM trace, so their behaviour should be similar. Regards, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 From owner-freebsd-geom@FreeBSD.ORG Sun Apr 15 19:31:05 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4BEB816A41B for ; Sun, 15 Apr 2007 19:31:05 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.172]) by mx1.freebsd.org (Postfix) with ESMTP id 9746913C45B for ; Sun, 15 Apr 2007 19:31:04 +0000 (UTC) (envelope-from r.c.ladan@gmail.com) Received: by ug-out-1314.google.com with SMTP id 71so797581ugh for ; Sun, 15 Apr 2007 12:31:03 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=oxp5/QSCBfGvwfrluo7kukSqfs8iWvPNPcTNdM39NxW1/q5HrgcAYglFpuztD1T3O80E+/w7/uhHzZ3+h+2M8LxdJQaJ5/vlwh2hhRDOu+OfIw1vd0JyJzUI32Z8OL1eDbHJGzQx4mKrCUAOI5Tz+quVXh4siGXIGXBr1miOIzM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=kAPsgemA67I47Fp4X+XYLODN/Chy1Cjs5Ig0/sRSD1GPsKiWLp81dyv3bHnpyjl53KM1eFtHLRSTfxxSHgFL7th9Rwyyz45e4FGUIJ99EFFmQEzHYINkcIBUDLJ5gpF2ruo4/g4yGr5G8fSLLOxQoycXC/KMqLkbLyC//g5TsBM= Received: by 10.66.250.17 with SMTP id x17mr3730138ugh.1176663907999; Sun, 15 Apr 2007 12:05:07 -0700 (PDT) Received: from ?192.168.123.202? ( [195.241.221.201]) by mx.google.com with ESMTP id 13sm1678368ugb.2007.04.15.12.05.07; Sun, 15 Apr 2007 12:05:07 -0700 (PDT) Message-ID: <46227755.6010208@gmail.com> Date: Sun, 15 Apr 2007 21:04:53 +0200 From: Rene Ladan User-Agent: Thunderbird 1.5.0.10 (X11/20070320) MIME-Version: 1.0 To: Ed Schouten References: <20070414115959.GN81821@hoeg.nl> In-Reply-To: <20070414115959.GN81821@hoeg.nl> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-geom@freebsd.org Subject: Re: New GEOM module: geom_xboxhd X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Apr 2007 19:31:05 -0000 Ed Schouten schreef: > Hello, > > One of the problems of the current FreeBSD/xbox port is that it's not > possible to install FreeBSD, while leaving the existing software alone. > The Microsoft Xbox uses a custom disk layout which doesn't have a > partition table format which specifies the geometries. All partitions > are hardcoded. > [...] > My Xbox isn't capable anymore to deal with original Xbox harddisks > anymore, so I tested it on my desktop with a snapshot of an Xbox > harddisk from a friend of mine (thanks Laurens!). > [...] Can you confirm that the slices are created if you first plug in the xbox harddisk and kldload the module afterwards? I once wrote a GEOM module to slice xbox360 media (kern/107707), which only works if you first kldload it and _then_ plug in the media. This is caused by pp->mediasize == 0 in the taste function. Note that you'll need a physical harddisk for the test because the behaviour is always correct when using md images. I suspect that the bug is near /sys/cam/scsi/scsi_da.c Thanks, Rene -- GPG fingerprint = E738 5471 D185 7013 0EE0 4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net) "It won't fit on the line." -- me, 2001 From owner-freebsd-geom@FreeBSD.ORG Mon Apr 16 11:08:29 2007 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6297716A4C9 for ; Mon, 16 Apr 2007 11:08:29 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 517C213C4AD for ; Mon, 16 Apr 2007 11:08:29 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (linimon@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l3GB8Tlr042793 for ; Mon, 16 Apr 2007 11:08:29 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l3GB8RmN042789 for freebsd-geom@FreeBSD.org; Mon, 16 Apr 2007 11:08:27 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 16 Apr 2007 11:08:27 GMT Message-Id: <200704161108.l3GB8RmN042789@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: linimon set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-geom@FreeBSD.org Cc: Subject: Current problem reports assigned to you X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Apr 2007 11:08:29 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/73177 geom kldload geom_* causes panic due to memory exhaustion o kern/76538 geom [gbde] nfs-write on gbde partition stalls and continue o kern/83464 geom [geom] [patch] Unhandled malloc failures within libgeo o kern/84556 geom [geom] GBDE-encrypted swap causes panic at shutdown o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/89102 geom [geom_vfs] [panic] panic when forced unmount FS from u o bin/90093 geom fdisk(8) incapable of altering in-core geometry o kern/90582 geom [geom_mirror] [panic] Restore cause panic string (ffs_ o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML 10 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/78131 geom gbde "destroy" not working. o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/94632 geom [geom] Kernel output resets input while GELI asks for f kern/105390 geom [geli] filesystem on a md backed by sparse file with s o kern/107707 geom [geom] [patch] add new class geom_xbox360 to slice up p bin/110705 geom gmirror control utility does not exit with correct exi 6 problems total. From owner-freebsd-geom@FreeBSD.ORG Fri Apr 20 13:22:17 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3C08416A401 for ; Fri, 20 Apr 2007 13:22:17 +0000 (UTC) (envelope-from mike@nux.co.uk) Received: from smtp.nildram.co.uk (smtp.nildram.co.uk [195.112.4.54]) by mx1.freebsd.org (Postfix) with ESMTP id A9AB313C44C for ; Fri, 20 Apr 2007 13:22:16 +0000 (UTC) (envelope-from mike@nux.co.uk) Received: from office.nux.co.uk (unknown [82.133.40.67]) by smtp.nildram.co.uk (Postfix) with ESMTP id 821EE2B7010 for ; Fri, 20 Apr 2007 13:44:01 +0100 (BST) Received: (qmail 47823 invoked by uid 2223); 20 Apr 2007 12:44:03 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 20 Apr 2007 12:44:03 -0000 Date: Fri, 20 Apr 2007 13:44:03 +0100 (BST) From: Mike Wolman X-X-Sender: mike@nux.eros.office To: freebsd-geom@freebsd.org, freebsd-fs@freebsd.org Message-ID: <20070420133854.G45782@nux.eros.office> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-767011191-1177073043=:45782" Cc: Subject: lazy mirror / live backup X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 13:22:17 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-767011191-1177073043=:45782 Content-Type: TEXT/PLAIN; charset=uk.cp850.kbd; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Hi List, I'd like the ability to have gmirror do a more efficient re-silvering (or= =20 re-syncing) of the mirror members when a planned disconnect occurs. This=20 would significantly reduce the mirror rebuild time for any component which= =20 had been deactivated, for network mirrors using ggated devices this would= =20 also reduce network usage and could be used for remote asynced mirrors=20 thus providing a live backup for laptops/workstations. Main Points When a normal mirror breaks this module must keep track of which block in= =20 the mirror have changed. - This can be done by keeping a list/map of just the block which change. - This list/map needs to be stored on a device not provided by the mirror= =20 or in memory. If this list is stored in memory on rebooting the machine any= =20 deattached drive would require a full resync so a way of saving dumping=20 this list to permanent storage would be required as this would be a=20 problem for large mirrors over slow links. Example uses: Usb/Firewire external drive nightly full backup. If a mirror is contracted with 3 components: ad1, umass1 and umass2 umass1 and umass2 are backup devices taken home on alternate nights by=20 different users, always allowing for a device to have a full 1 day old=20 backup at a remote location. This module should be able to use the change log for multiple devices=20 preserving the changes until all components are upto date. Should one of= =20 the usb devices fail and is removed from the mirror the change log should= =20 be cleared (provided all other components are upto date) allowing for=20 drive failers and stopping the block change log growing indefinitely. It= =20 should be possible to use the same change log for more than one device. Normal full backups to usb devices can take many hours, this should reduce= =20 the time to only the amount of data added within the period the device was= =20 last attached to the mirror. Example use for disaster recovery - slow links: If the mirror consist of 2 components ad1 and ggatec1 with component=20 ggatec1 being on a slow link. A flush period tuneable could be used by deactivating the ggatec component= =20 and reactivating it allowing for an asynchronous mirror - =E1 la rsync but= =20 faster as there is no file list etc. A tuneable may be required to only sync blocks which have not been changed= =20 in xx seconds/minutes to prevent the same blocks being transferred too=20 often. A tuneable to specify the speed at which gmirror syncronises the out of=20 sync component will be required - This would possibly be useful for normal= =20 gmirror use on a busy server when rebuilding a drive, as gmirror currently= =20 uses all available write speed to do so - limiting rebuild speed may=20 therefore prevent drive failures. Live backup of laptop/workstation If the mirror is created using a local disk ad0 and a ggated mounted=20 device ggate0 with a balance algorithm preferring ad0. When the network is unavailable gmirror starts to keep track of the=20 changed blocks. On reconnection to the network and activating the ggatec=20 component the list of changed blocks can be flushed. Should the same=20 block have changed more than once only the last change needs to be sent -= =20 reducing network usage. The main problem with mirroring the whole system drive is that any swap=20 changes will need to be ignored. Other Considerations/Suggestions: - Gmirrror will need somehow need to be informed that a drive has actually= =20 failed and is not just temporarily disconnected. - Data structure consideration difference between a list of block numbers= =20 that have changed, and a block bitmap. A block bitmap is perfect for=20 this, and only requires 1bit per block of storage, max. No more. A list= =20 of block numbers can get *HUGE* though, because the block numbers are=20 probably all 64bit numbers, so it will be 64x the amount of space required= =20 to store the list, not to mention the issues of sorting and maintaining it - For determining the size of this 'block change map', you could use the=20 ceiling of the max number of blocks. so, a 100Gb storage mirror, would=20 have roughly 200000000 512b blocks. So, 200million bits (using a bitmap=20 to store when a block needs resyncing or not (0 no sync, 1 sync) is=20 roughly 24MB. You could pretty easily keep that in memory, but if the size= =20 was 1Tb, you'd be at around 240MB, so that starts to get a little much.=20 Since this would be able to be enabled/disabled, it may not be an issue. - Possibly, you could cheat. Instead of marking each storage block=20 (512byte sector) as needing sync or not, you could do it in 16KB chunks.=20 So, if any sector inside that 16KB chunk was written, resync the whole=20 chunk. That reduces your memory footprint for a 100GB mirror down to=20 something less than 1MB! That means a 1Tb mirror would need only 7-10MB.=20 You'll resync a little extra data, but since drives cache and the GEOM=20 layer does requests efficiently in larger sizes anyhow, this might=20 actually perform better anyway. If there is anyone has further suggestions for this idea please let me=20 know and if there are and developers interested in this i may be able to=20 provide/donate some hardware - sorry not new - a laptop, desktop and some= =20 hard drives - and can setup a machine for any network related testing. --0-767011191-1177073043=:45782-- From owner-freebsd-geom@FreeBSD.ORG Fri Apr 20 15:27:49 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 986B416A400 for ; Fri, 20 Apr 2007 15:27:49 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 2724E13C469 for ; Fri, 20 Apr 2007 15:27:48 +0000 (UTC) (envelope-from gcubfg-freebsd-geom@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hev1R-0001B7-TP for freebsd-geom@freebsd.org; Fri, 20 Apr 2007 17:27:41 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Apr 2007 17:27:41 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 20 Apr 2007 17:27:41 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-geom@freebsd.org From: Ivan Voras Date: Fri, 20 Apr 2007 17:27:13 +0200 Lines: 95 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4A9CCDB6C7A3597A594040D8" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.10 (X11/20060911) X-Enigmail-Version: 0.94.2.0 Sender: news Cc: freebsd-current@freebsd.org Subject: GPT as default? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 15:27:49 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4A9CCDB6C7A3597A594040D8 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi! My accepted GSoC project this year is making a graphical FreeBSD=20 installer (see http://wiki.freebsd.org/finstall). One of the first=20 functional (not related to UI) things the installer does is disk=20 partitioning, and I'm trying to simplify this step. Currently, the=20 FreeBSD default is classic BSD partitions on top of MSDOS partitions,=20 and there are a couple of inconvenient things about this arrangement: 1. There can be only 4 MSDOS partitions and 8 BSD partitions per table 2. BSD partitions by convention or backwards compatibility have special=20 entries for "b" and "c" ("b" is by convention swap, "c" is because of=20 backward compatibility "the whole disk") 3. MSDOS and BSD partitions are limited in size to 2 TB Many systems (including MacOS X and Solaris) are moving to GPT=20 partitions (http://en.wikipedia.org/wiki/GUID_Partition_Table), mostly=20 because they don't have the above limitations. My proposal is that we=20 deprecate BSD labels and move to GPT in 7.0 (or more correctly, if the=20 stars were to be benevolent on us, on the new systems that are installed = by the new GPT-aware installer :) ). The FreeBSD kernel supports GPT, and AFAIK the ability to modify them=20 in-place was recently added with the "unified" GPT slicer. There are two = things that are stopping total use of GPT right now: 1. Dual-booting (e.g. between Windows and FreeBSD) 2. Boot code limitations First can be somewhat avoided by supporting a hybrid model, and using=20 MSDOS partitions as exist on the computer, and (since GEOM is flexible)=20 creating GPT partitions inside the MSDOS partition dedicated to FreeBSD=20 (i.e. just like now, only using GPT instead of BSD labels). The second is more serious: FreeBSD boot code cannot boot from a GPT=20 partition. Part of the problem is that GPT uses GUIDs for distinguishing partition=20 types, so the current code that recognizes various partition types=20 (Linux, FreeBSD, NTFS - the famous "F1" prompt) may need to be thrown=20 out since each GUID is 16 bytes long and AFAIK there's only about 300=20 bytes in the MBR for the boot code. GPT specification encourages using=20 different GUIDs for different purposes, so a swap partition would have a = different GUID than a UFS partition, which would have a different GUID=20 than a ZFS partition. I think UFS reserves a few sectors at the file=20 system start for the second stage boot code, but I don't know if ZFS=20 follows in this fashion. Except for this, and looking at the specification=20 (http://technet2.microsoft.com/WindowsServer/en/library/bdeda920-1f08-468= 3-9ffb-7b4b50df0b5a1033.mspx?mfr=3Dtrue),=20 the partition format is "sane" - it contains plain 64-bit LBAs (offsets=20 of sectors on the disk, so maximum disk/partition size is 2^64 * 512=20 bytes) that can AFAIK be directly used to access data. Thee are some minor issues, like CRC32 checksums of GPT data included in = the tables, and I don't know if it would be worth the code to include=20 it, but this should be all. The above discussion assumes the classical boot model (MBR -> chaining=20 to other partitions -> higher stage boot loaders) and not EFI. Now, the problem is - is someone with enough assembler knowledge=20 interested in implementing a GPT-aware boot loader? :) Due to the size constraint, the boot loaders would probably have to be=20 split - one for MSDOS partitions, one for GPT partitions. --------------enig4A9CCDB6C7A3597A594040D8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGKNvYldnAQVacBcgRAubaAJsFHL/NoQXw0DoHlk/69ASIaatbbgCfRBUO pwt1cHQJKjfjE+gt4piV6C8= =UAyy -----END PGP SIGNATURE----- --------------enig4A9CCDB6C7A3597A594040D8-- From owner-freebsd-geom@FreeBSD.ORG Fri Apr 20 17:15:24 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4949216A407; Fri, 20 Apr 2007 17:15:24 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 069CA13C43E; Fri, 20 Apr 2007 17:15:23 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id C1BE4207E; Fri, 20 Apr 2007 19:15:19 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id AF36C2049; Fri, 20 Apr 2007 19:15:19 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 8133E542C; Fri, 20 Apr 2007 19:15:17 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Ivan Voras References: Date: Fri, 20 Apr 2007 19:15:17 +0200 In-Reply-To: (Ivan Voras's message of "Fri, 20 Apr 2007 17:27:13 +0200") Message-ID: <86wt076k7u.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: GPT as default? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 17:15:24 -0000 Ivan Voras writes: > Many systems (including MacOS X and Solaris) are moving to GPT > partitions (http://en.wikipedia.org/wiki/GUID_Partition_Table), mostly > because they don't have the above limitations. My proposal is that we > deprecate BSD labels and move to GPT in 7.0 (or more correctly, if the > stars were to be benevolent on us, on the new systems that are > installed by the new GPT-aware installer :) ). Not unless geom_gpt receives considerable attention. Currently, it is not even possible to list the GPT, let alone create new partitions, if one of the partitions is open. GPT can not be the default partitioning scheme until this is addressed. > The second is more serious: FreeBSD boot code cannot boot from a GPT > partition. > > Part of the problem is that GPT uses GUIDs for distinguishing > partition types, so the current code that recognizes various partition > types (Linux, FreeBSD, NTFS - the famous "F1" prompt) may need to be > thrown out since each GUID is 16 bytes long and AFAIK there's only > about 300 bytes in the MBR for the boot code. DOS partitions normally start on a cylinder boundary, even though cylinders no longer mean anything. This means there is plenty of space for code and data between the MBR and the first partition. I don't know if this is also the case with GPT. > Now, the problem is - is someone with enough assembler knowledge > interested in implementing a GPT-aware boot loader? :) Capable, yes. Interested, perhaps. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-geom@FreeBSD.ORG Fri Apr 20 17:23:52 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DABF216A400; Fri, 20 Apr 2007 17:23:52 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.183]) by mx1.freebsd.org (Postfix) with ESMTP id 935B613C4AD; Fri, 20 Apr 2007 17:23:52 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/smtpout13/MantshX 4.0) with ESMTP id l3KGgpvX023153; Fri, 20 Apr 2007 09:42:52 -0700 (PDT) Received: from [192.168.5.252] (209-128-86-226.bayarea.net [209.128.86.226]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id l3KGgoM7027616 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Apr 2007 09:42:50 -0700 (PDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3E23566F-DB23-48EF-85F6-23617113219D@mac.com> Content-Transfer-Encoding: 7bit From: Marcel Moolenaar Date: Fri, 20 Apr 2007 09:41:49 -0700 To: Ivan Voras X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Cc: freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Using G_PART with MBR/BSD instead [was: Re: GPT as default?] X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 17:23:53 -0000 On Apr 20, 2007, at 8:27 AM, Ivan Voras wrote: > My accepted GSoC project this year is making a graphical FreeBSD > installer (see http://wiki.freebsd.org/finstall). One of the first > functional (not related to UI) things the installer does is disk > partitioning, and I'm trying to simplify this step. *snip* > The FreeBSD kernel supports GPT, and AFAIK the ability to modify > them in-place was recently added with the "unified" GPT slicer. > There are two things that are stopping total use of GPT right now: *snip* You can achieve the same (i.e. simplify partitioning), but without going off into the woods (i.e. try to boot from GPT). The new GEOM partitioning class currently only understands GPT and APM, but can be easily extended to support MBR and BSD schemes as well as the SUN scheme. Extending the GEOM partitioning class that way allows you to work the problem based on a single unified API, which mostly abstracts the gory details and should allow you to simplify things. This probably is more fruitful that trying to change how disks are being partitioned. The whole idea behind the GPART GEOM class is that it's to be extended in the way I described. I'm working on a userland tool for it and we could greatly benefit from each other's work. Which for you means that you may actually have time to work on the installer, rather than see you time spent on disk partitioning alone. For me it means that I have feedback about missing functionality before I finish the tool, which should help write the tool in such a way that the missing functionality can be added easily later, if not right away. For FreeBSD the advantage is that things will start to come together in a logical design and hopefully end up being implemented completely. Just a thought, -- Marcel Moolenaar xcllnt@mac.com From owner-freebsd-geom@FreeBSD.ORG Fri Apr 20 17:36:35 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 605C216A407; Fri, 20 Apr 2007 17:36:35 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.183]) by mx1.freebsd.org (Postfix) with ESMTP id 4877A13C457; Fri, 20 Apr 2007 17:36:35 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin08-en2 [10.13.10.153]) by smtpout.mac.com (Xserve/smtpout13/MantshX 4.0) with ESMTP id l3KHaUNR021077; Fri, 20 Apr 2007 10:36:30 -0700 (PDT) Received: from [172.24.104.161] (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/smtpin08/MantshX 4.0) with ESMTP id l3KHaSeg003854 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 20 Apr 2007 10:36:29 -0700 (PDT) In-Reply-To: <86wt076k7u.fsf@dwp.des.no> References: <86wt076k7u.fsf@dwp.des.no> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <619464E1-1CB4-4CFC-9ECF-7FC90DC24A20@mac.com> Content-Transfer-Encoding: quoted-printable From: Marcel Moolenaar Date: Fri, 20 Apr 2007 10:35:28 -0700 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Cc: freebsd-current@freebsd.org, Ivan Voras , freebsd-geom@freebsd.org Subject: Re: GPT as default? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 17:36:35 -0000 On Apr 20, 2007, at 10:15 AM, Dag-Erling Sm=F8rgrav wrote: > Ivan Voras writes: >> Many systems (including MacOS X and Solaris) are moving to GPT >> partitions (http://en.wikipedia.org/wiki/GUID_Partition_Table), =20 >> mostly >> because they don't have the above limitations. My proposal is that we >> deprecate BSD labels and move to GPT in 7.0 (or more correctly, if =20= >> the >> stars were to be benevolent on us, on the new systems that are >> installed by the new GPT-aware installer :) ). > > Not unless geom_gpt receives considerable attention. It receives attention. > Currently, it is not even possible to list the GPT, let alone create > new partitions, if one of the partitions is open. GPT can not be the > default partitioning scheme until this is addressed. You can list with the -r option. You cannot create unless you allow foot-shooting in GEOM (i.e. set kern.geom.debugflags=3D16). The latter a known side-effect of GEOM and has nothing to do with GPT itself. Anyway: The new G_PART class is there to fix it... >> The second is more serious: FreeBSD boot code cannot boot from a GPT >> partition. >> >> Part of the problem is that GPT uses GUIDs for distinguishing >> partition types, so the current code that recognizes various =20 >> partition >> types (Linux, FreeBSD, NTFS - the famous "F1" prompt) may need to be >> thrown out since each GUID is 16 bytes long and AFAIK there's only >> about 300 bytes in the MBR for the boot code. > > DOS partitions normally start on a cylinder boundary, even though > cylinders no longer mean anything. This means there is plenty of > space for code and data between the MBR and the first partition. > > I don't know if this is also the case with GPT. It isn't. If disk space is needed, one can always create a partition for it. There's no need to stuff things in anonymous sectors. --=20 Marcel Moolenaar xcllnt@mac.com From owner-freebsd-geom@FreeBSD.ORG Fri Apr 20 18:23:30 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BA70B16A406 for ; Fri, 20 Apr 2007 18:23:30 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 7A19313C46E for ; Fri, 20 Apr 2007 18:23:30 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.60.100]) by phk.freebsd.dk (Postfix) with ESMTP id CA43217380; Fri, 20 Apr 2007 17:57:15 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l3KHvFsH052687; Fri, 20 Apr 2007 17:57:15 GMT (envelope-from phk@critter.freebsd.dk) To: Ivan Voras From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 20 Apr 2007 17:27:13 +0200." Date: Fri, 20 Apr 2007 17:57:15 +0000 Message-ID: <52686.1177091835@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: GPT as default? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 18:23:30 -0000 In message , Ivan Voras writes: >Currently, the >FreeBSD default is classic BSD partitions on top of MSDOS partitions, >and there are a couple of inconvenient things about this arrangement: The BSD partitioning should be discontinued as fast and firmly as possible. By all means go GPT. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Fri Apr 20 21:09:16 2007 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B130E16A40E for ; Fri, 20 Apr 2007 21:09:16 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from sippysoft.com (gk.360sip.com [72.236.70.226]) by mx1.freebsd.org (Postfix) with ESMTP id 32BD413C487 for ; Fri, 20 Apr 2007 21:09:16 +0000 (UTC) (envelope-from sobomax@FreeBSD.org) Received: from [192.168.1.47] ([204.244.149.125]) (authenticated bits=0) by sippysoft.com (8.13.8/8.13.8) with ESMTP id l3KKupNa058428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 20 Apr 2007 13:56:58 -0700 (PDT) (envelope-from sobomax@FreeBSD.org) Message-ID: <462928C7.8090400@FreeBSD.org> Date: Fri, 20 Apr 2007 13:55:35 -0700 From: Maxim Sobolev Organization: Sippy Software, Inc. User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Scott Long References: <52686.1177091835@critter.freebsd.dk> <46292461.5090503@samsco.org> In-Reply-To: <46292461.5090503@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Poul-Henning Kamp , freebsd-current@FreeBSD.org, Ivan Voras , freebsd-geom@FreeBSD.org Subject: Re: GPT as default? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 21:09:16 -0000 Scott Long wrote: > Poul-Henning Kamp wrote: >> In message , Ivan Voras writes: >> >>> Currently, the FreeBSD default is classic BSD partitions on top of >>> MSDOS partitions, and there are a couple of inconvenient things about >>> this arrangement: >> >> The BSD partitioning should be discontinued as fast and firmly >> as possible. By all means go GPT. >> > > An i386/amd64 bootloader needs to be written that can understand GPT. > My understanding is that the ia64 EFI/GPT loader has very few reusable > bits. It probably crazy idea, but I wonder if it's feasible to have "mini-GEOM" layer in loader, so that it's possible to use existing GEOM classes codebase there with little or no modifications. -Maxim From owner-freebsd-geom@FreeBSD.ORG Fri Apr 20 21:16:23 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3044B16A402 for ; Fri, 20 Apr 2007 21:16:23 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id DDC2A13C459 for ; Fri, 20 Apr 2007 21:16:22 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l3KKb6jJ059272; Fri, 20 Apr 2007 14:37:07 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <46292461.5090503@samsco.org> Date: Fri, 20 Apr 2007 14:36:49 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: Poul-Henning Kamp References: <52686.1177091835@critter.freebsd.dk> In-Reply-To: <52686.1177091835@critter.freebsd.dk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Fri, 20 Apr 2007 14:37:07 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org, Ivan Voras , freebsd-geom@freebsd.org Subject: Re: GPT as default? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Apr 2007 21:16:23 -0000 Poul-Henning Kamp wrote: > In message , Ivan Voras writes: > >> Currently, the >> FreeBSD default is classic BSD partitions on top of MSDOS partitions, >> and there are a couple of inconvenient things about this arrangement: > > The BSD partitioning should be discontinued as fast and firmly > as possible. By all means go GPT. > An i386/amd64 bootloader needs to be written that can understand GPT. My understanding is that the ia64 EFI/GPT loader has very few reusable bits. Scott From owner-freebsd-geom@FreeBSD.ORG Sat Apr 21 06:49:45 2007 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4660F16A403; Sat, 21 Apr 2007 06:49:45 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id D90CB13C4B7; Sat, 21 Apr 2007 06:49:44 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.60.100]) by phk.freebsd.dk (Postfix) with ESMTP id 23E8017382; Sat, 21 Apr 2007 06:49:43 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.1/8.14.1) with ESMTP id l3L6nfvb055081; Sat, 21 Apr 2007 06:49:41 GMT (envelope-from phk@critter.freebsd.dk) To: Maxim Sobolev From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 20 Apr 2007 13:55:35 MST." <462928C7.8090400@FreeBSD.org> Date: Sat, 21 Apr 2007 06:49:41 +0000 Message-ID: <55080.1177138181@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Scott Long , freebsd-current@FreeBSD.org, Ivan Voras , freebsd-geom@FreeBSD.org Subject: Re: GPT as default? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2007 06:49:45 -0000 In message <462928C7.8090400@FreeBSD.org>, Maxim Sobolev writes: >Scott Long wrote: >> Poul-Henning Kamp wrote: >>> In message , Ivan Voras writes: >>> >>>> Currently, the FreeBSD default is classic BSD partitions on top of >>>> MSDOS partitions, and there are a couple of inconvenient things about >>>> this arrangement: >>> >>> The BSD partitioning should be discontinued as fast and firmly >>> as possible. By all means go GPT. >>> >> >> An i386/amd64 bootloader needs to be written that can understand GPT. >> My understanding is that the ia64 EFI/GPT loader has very few reusable >> bits. > >It probably crazy idea, but I wonder if it's feasible to have >"mini-GEOM" layer in loader, so that it's possible to use existing GEOM >classes codebase there with little or no modifications. That's actually an interesting idea... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-geom@FreeBSD.ORG Sat Apr 21 07:39:41 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 90C0416A401; Sat, 21 Apr 2007 07:39:41 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.freebsd.org (Postfix) with ESMTP id 5091613C457; Sat, 21 Apr 2007 07:39:41 +0000 (UTC) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 3CFD82083; Sat, 21 Apr 2007 09:39:37 +0200 (CEST) X-Spam-Tests: AWL X-Spam-Learn: disabled X-Spam-Score: 0.0/3.0 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on tim.des.no Received: from dwp.des.no (des.no [80.203.243.180]) by smtp.des.no (Postfix) with ESMTP id A49172049; Sat, 21 Apr 2007 09:39:36 +0200 (CEST) Received: by dwp.des.no (Postfix, from userid 1001) id 7DF0F54B2; Sat, 21 Apr 2007 09:39:36 +0200 (CEST) From: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?=) To: Marcel Moolenaar References: <86wt076k7u.fsf@dwp.des.no> <619464E1-1CB4-4CFC-9ECF-7FC90DC24A20@mac.com> Date: Sat, 21 Apr 2007 09:39:36 +0200 In-Reply-To: <619464E1-1CB4-4CFC-9ECF-7FC90DC24A20@mac.com> (Marcel Moolenaar's message of "Fri, 20 Apr 2007 10:35:28 -0700") Message-ID: <863b2u18hz.fsf@dwp.des.no> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, Ivan Voras , freebsd-geom@freebsd.org Subject: Re: GPT as default? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2007 07:39:41 -0000 Marcel Moolenaar writes: > On Apr 20, 2007, at 10:15 AM, Dag-Erling Sm=F8rgrav wrote: > > Currently, it is not even possible to list the GPT, let alone create > > new partitions, if one of the partitions is open. GPT can not be the > > default partitioning scheme until this is addressed. > You can list with the -r option. You cannot create unless you allow > foot-shooting in GEOM (i.e. set kern.geom.debugflags=3D16). The latter > a known side-effect of GEOM and has nothing to do with GPT itself. No, it is a known side effect of geom_gpt's poor design. Compare with geom_bsd, for instance. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-geom@FreeBSD.ORG Sat Apr 21 07:54:04 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0FF6416A401; Sat, 21 Apr 2007 07:54:04 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id BB52D13C43E; Sat, 21 Apr 2007 07:54:03 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id l3L7rqOM066844; Sat, 21 Apr 2007 01:53:52 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4629C2FE.9030301@samsco.org> Date: Sat, 21 Apr 2007 01:53:34 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <86wt076k7u.fsf@dwp.des.no> <619464E1-1CB4-4CFC-9ECF-7FC90DC24A20@mac.com> <863b2u18hz.fsf@dwp.des.no> In-Reply-To: <863b2u18hz.fsf@dwp.des.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Sat, 21 Apr 2007 01:53:52 -0600 (MDT) X-Spam-Status: No, score=-1.4 required=5.5 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-geom@freebsd.org, Marcel Moolenaar , Ivan Voras , freebsd-current@freebsd.org Subject: Re: GPT as default? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2007 07:54:04 -0000 Dag-Erling Smørgrav wrote: > Marcel Moolenaar writes: >> On Apr 20, 2007, at 10:15 AM, Dag-Erling Smørgrav wrote: >>> Currently, it is not even possible to list the GPT, let alone create >>> new partitions, if one of the partitions is open. GPT can not be the >>> default partitioning scheme until this is addressed. >> You can list with the -r option. You cannot create unless you allow >> foot-shooting in GEOM (i.e. set kern.geom.debugflags=16). The latter >> a known side-effect of GEOM and has nothing to do with GPT itself. > > No, it is a known side effect of geom_gpt's poor design. Compare with > geom_bsd, for instance. > And as much as it pains me to say it, DES is right here ;-) geom_gpt needs to implement the appropriate verbs to allow apps to instruct the gpt instance to modify itself, instead of forcing apps to blindly overwrite it. Scott From owner-freebsd-geom@FreeBSD.ORG Sat Apr 21 10:30:20 2007 Return-Path: X-Original-To: freebsd-geom@hub.freebsd.org Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 193B116A407 for ; Sat, 21 Apr 2007 10:30:20 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id E1E8613C4C5 for ; Sat, 21 Apr 2007 10:30:19 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.4/8.13.4) with ESMTP id l3LAUJgA029613 for ; Sat, 21 Apr 2007 10:30:19 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.4/8.13.4/Submit) id l3LAUJSn029607; Sat, 21 Apr 2007 10:30:19 GMT (envelope-from gnats) Date: Sat, 21 Apr 2007 10:30:19 GMT Message-Id: <200704211030.l3LAUJSn029607@freefall.freebsd.org> To: freebsd-geom@FreeBSD.org From: "Rene Ladan" Cc: Subject: Re: kern/107707: [geom] [patch] add new class geom_xbox360 to slice up xbox360 media X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rene Ladan List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2007 10:30:20 -0000 The following reply was made to PR kern/107707; it has been noted by GNATS. From: "Rene Ladan" To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/107707: [geom] [patch] add new class geom_xbox360 to slice up xbox360 media Date: Sat, 21 Apr 2007 11:58:55 +0200 2007-04-20 : added support for the new 512 MB memory units. The new patch is at the same location and tested with the 64 MB and 512 MB memory units and the 20 GB hard disk. From owner-freebsd-geom@FreeBSD.ORG Sat Apr 21 16:34:53 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DC77816A401; Sat, 21 Apr 2007 16:34:53 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.175]) by mx1.freebsd.org (Postfix) with ESMTP id C37A113C489; Sat, 21 Apr 2007 16:34:53 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/smtpout05/MantshX 4.0) with ESMTP id l3LGYbCl000324; Sat, 21 Apr 2007 09:34:42 -0700 (PDT) Received: from [192.168.5.252] (209-128-86-226.bayarea.net [209.128.86.226]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id l3LGYZsv012974 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 21 Apr 2007 09:34:36 -0700 (PDT) In-Reply-To: <4629C2FE.9030301@samsco.org> References: <86wt076k7u.fsf@dwp.des.no> <619464E1-1CB4-4CFC-9ECF-7FC90DC24A20@mac.com> <863b2u18hz.fsf@dwp.des.no> <4629C2FE.9030301@samsco.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <91BC1CF6-6C72-4263-A99A-C24FC209586E@mac.com> Content-Transfer-Encoding: quoted-printable From: Marcel Moolenaar Date: Sat, 21 Apr 2007 09:33:34 -0700 To: Scott Long X-Mailer: Apple Mail (2.752.3) X-Brightmail-Tracker: AAAAAA== X-Brightmail-scanned: yes Cc: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , freebsd-current@freebsd.org, Ivan Voras , freebsd-geom@freebsd.org Subject: Re: GPT as default? X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2007 16:34:54 -0000 On Apr 21, 2007, at 12:53 AM, Scott Long wrote: > Dag-Erling Sm=F8rgrav wrote: >> Marcel Moolenaar writes: >>> On Apr 20, 2007, at 10:15 AM, Dag-Erling Sm=F8rgrav wrote: >>>> Currently, it is not even possible to list the GPT, let alone =20 >>>> create >>>> new partitions, if one of the partitions is open. GPT can not =20 >>>> be the >>>> default partitioning scheme until this is addressed. >>> You can list with the -r option. You cannot create unless you allow >>> foot-shooting in GEOM (i.e. set kern.geom.debugflags=3D16). The = latter >>> a known side-effect of GEOM and has nothing to do with GPT itself. >> No, it is a known side effect of geom_gpt's poor design. Compare =20 >> with >> geom_bsd, for instance. > > And as much as it pains me to say it, DES is right here ;-) geom_gpt > needs to implement the appropriate verbs to allow apps to instruct the > gpt instance to modify itself, instead of forcing apps to blindly > overwrite it. Those verbs exist. There's no poor design There's only a long time to get from A to B. --=20 Marcel Moolenaar xcllnt@mac.com From owner-freebsd-geom@FreeBSD.ORG Sat Apr 21 22:10:54 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AE5C616A400 for ; Sat, 21 Apr 2007 22:10:54 +0000 (UTC) (envelope-from lists@lrnx.ath.cx) Received: from postfix1-g20.free.fr (postfix1-g20.free.fr [212.27.60.42]) by mx1.freebsd.org (Postfix) with ESMTP id 4DEA713C45A for ; Sat, 21 Apr 2007 22:10:54 +0000 (UTC) (envelope-from lists@lrnx.ath.cx) Received: from smtp5-g19.free.fr (smtp5-g19.free.fr [212.27.42.35]) by postfix1-g20.free.fr (Postfix) with ESMTP id 7D07BE57C28 for ; Sat, 21 Apr 2007 23:42:34 +0200 (CEST) Received: from hermes.lrnx.net (fr141-1-82-237-217-212.fbx.proxad.net [82.237.217.212]) by smtp5-g19.free.fr (Postfix) with ESMTP id C950F43336 for ; Sat, 21 Apr 2007 23:42:32 +0200 (CEST) Received: from [192.168.1.17] (xpf@awax.blois.fr.lrnx.local [192.168.1.17]) by hermes.lrnx.net (8.13.6/8.13.6) with ESMTP id l3LLgW2C075387 for ; Sat, 21 Apr 2007 23:42:32 +0200 (CEST) (envelope-from lists@lrnx.ath.cx) Message-ID: <462A8548.3080505@lrnx.ath.cx> Date: Sat, 21 Apr 2007 23:42:32 +0200 From: Pierre-Francois LAURAND User-Agent: Thunderbird 2.0.0.0 (X11/20070421) MIME-Version: 1.0 To: freebsd-geom@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (hermes.lrnx.net [82.237.217.212]); Sat, 21 Apr 2007 23:42:32 +0200 (CEST) X-Virus-Scanned: ClamAV 0.90.1/3146/Sat Apr 21 21:39:19 2007 on astra.blois.fr.lrnx.local X-Virus-Status: Clean Subject: gmirror name conflict X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2007 22:10:54 -0000 Hi, I'm looking for the right way to migrate a couple of gmirrored drives ( gm0 ) from one box to another one with an already configured gmirror : gm0, too. My goal is just to rename gm0 from the original box to gm1 on the new one, keeping datas of the mirror. Here is the way I consider to follow : old# gmirror desactivate gm0 /dev/da0s2 old# gmirror desactivate gm0 /dev/da1s2 ... new# gmirror label -n gm1 /dev/da2s2 new# gmirror insert gm1 /dev/da3s2 new# gmirror configure -a gm1 Can I be sure to keep my mirrored datas clean following these steps ? -- pfl From owner-freebsd-geom@FreeBSD.ORG Sat Apr 21 22:42:50 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 8D6E916A400 for ; Sat, 21 Apr 2007 22:42:50 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id 34A1B13C45B for ; Sat, 21 Apr 2007 22:42:49 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 7D10F45CD9; Sun, 22 Apr 2007 00:42:48 +0200 (CEST) Received: from localhost (public-gprs74242.centertel.pl [91.94.163.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 6241845681; Sun, 22 Apr 2007 00:42:37 +0200 (CEST) Date: Sun, 22 Apr 2007 00:42:00 +0200 From: Pawel Jakub Dawidek To: Pierre-Francois LAURAND Message-ID: <20070421224200.GG46583@garage.freebsd.pl> References: <462A8548.3080505@lrnx.ath.cx> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xs+9IvWevLaxKUtW" Content-Disposition: inline In-Reply-To: <462A8548.3080505@lrnx.ath.cx> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL autolearn=no version=3.0.4 Cc: freebsd-geom@freebsd.org Subject: Re: gmirror name conflict X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Apr 2007 22:42:50 -0000 --xs+9IvWevLaxKUtW Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Apr 21, 2007 at 11:42:32PM +0200, Pierre-Francois LAURAND wrote: > Hi, >=20 > I'm looking for the right way to migrate a couple of gmirrored drives ( > gm0 ) from one box to another one with an already configured gmirror : > gm0, too. > My goal is just to rename gm0 from the original box to gm1 on the new > one, keeping datas of the mirror. >=20 > Here is the way I consider to follow : >=20 > old# gmirror desactivate gm0 /dev/da0s2 > old# gmirror desactivate gm0 /dev/da1s2 > ... > new# gmirror label -n gm1 /dev/da2s2 > new# gmirror insert gm1 /dev/da3s2 > new# gmirror configure -a gm1 >=20 > Can I be sure to keep my mirrored datas clean following these steps ? Yeah, but a bit simpler: # gmirror stop gm0 # gmirror label gm1 da2s2 da3s2 --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --xs+9IvWevLaxKUtW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGKpM4ForvXbEpPzQRAkGPAJ0QP53X6JPHuMjcwy62q/dC9KbZZgCgyfAO JksAWtPXn0BSip8e4D3BW7k= =Znxn -----END PGP SIGNATURE----- --xs+9IvWevLaxKUtW--