From owner-freebsd-geom@FreeBSD.ORG Thu Aug 10 19:29:45 2006 Return-Path: X-Original-To: freebsd-geom@FreeBSD.org Delivered-To: freebsd-geom@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4CE3916A4DF; Thu, 10 Aug 2006 19:29:45 +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 4AC1943D66; Thu, 10 Aug 2006 19:29:41 +0000 (GMT) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 8BB0F5133B; Thu, 10 Aug 2006 21:29:40 +0200 (CEST) Received: from localhost (dkv208.neoplus.adsl.tpnet.pl [83.24.25.208]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 50F8550EA7; Thu, 10 Aug 2006 21:29:34 +0200 (CEST) Date: Thu, 10 Aug 2006 21:28:41 +0200 From: Pawel Jakub Dawidek To: Craig Boston , freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, freebsd-geom@FreeBSD.org Message-ID: <20060810192841.GA1345@garage.freebsd.pl> References: <20060808195202.GA1564@garage.freebsd.pl> <20060810184702.GA8567@nowhere> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="M9NhX3UHpAaciwkO" Content-Disposition: inline In-Reply-To: <20060810184702.GA8567@nowhere> 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=-0.5 required=3.0 tests=BAYES_00,RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: Subject: Re: GJournal (hopefully) final patches. 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: Thu, 10 Aug 2006 19:29:45 -0000 --M9NhX3UHpAaciwkO Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 10, 2006 at 01:47:23PM -0500, Craig Boston wrote: > Hi, >=20 > It's great to see this project so close to completion! I'm trying it > out on a couple machines to see how it goes. >=20 > A few comments and questions: >=20 > * It took me a little by surprise that it carves 1G out of the device > for the journal. Depending on the size of the device that can be a > pretty hefty price to pay (and I didn't see any mention of it in the > setup notes). For a couple of my smaller filesystems I reduced it to > 512MB. Perhaps some algorithm for auto-sizing the journal based on > the size / expected workload of the device would be in order? It will be pointed out in documentation when I finally prepare it. I don't have plans about autosizing currently. > * Attached is a quick patch for geom_eli to allow it to pass BIO_FLUSH > down to its backing device. It seems like the right thing to do and > fixes the "BIO_FLUSH not supported" warning on my laptop that uses a > geli encrypted disk. I've this already in my perforce tree. I also implemented BIO_FLUSH passing in gmirror and graid3. I also added a flag for gmirror and graid3 which says "don't resynchronize components after a power failure - trust they are consistent". And they are always consistent when placed below gjournal. > * On a different system, however, it complains about it even on a raw > ATA slice: >=20 > atapci1: port 0x1f0-0x1f7,0x3f6,0x170= -0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 > ata0: on atapci1 > ad0: 114473MB at ata0-master UDMA100 > GEOM_JOURNAL: BIO_FLUSH not supported by ad0s1e. >=20 > It seems like a reasonably modern controller and disk, at least it > should be capable of issuing a cache flush command. Not sure why it > doesn't like it :/ We would need to add some printfs to diagnoze this probably - you can try adding some lines to ad_init() to get this: if (atadev->param.support.command1 & ATA_SUPPORT_WRITECACHE) { if (ata_wc) ata_controlcmd(dev, ATA_SETFEATURES, ATA_SF_ENAB_WCACHE, 0, 0); else ata_controlcmd(dev, ATA_SETFEATURES, ATA_SF_DIS_WCACHE, 0, 0); } else { printf("ad_init: WRITE CACHE not supported by ad%d.\n", device_get_unit(dev)); } > * How "close" does the filesystem need to be to the gjournal device in > order for the UFS hooks to work? Directly on it? >=20 > The geom stack on my laptop currently looks something like this: >=20 > [geom_disk] ad0 <- [geom_eli] ad0.eli <- [geom_gpt] ad0.elip6 <- > [geom_label] gjtest <- [geom_journal] gjtest.journal <- UFS >=20 > I was wondering if an arrangement like this would work: >=20 > [geom_journal] ad0p6.journal <- [geom_eli] ad0p6.journaleli <- UFS >=20 > and if it would be any more efficient (journal the encrypted data > rather than encrypt the journal). Or even gjournal the whole disk at > once? When you mount file system it sends BIO_GETATTR "GJOURNAL::provider" requests. So as long as classes between the file system and gjournal provider pass BIO_GETATTR down, it will work. On my home machine I've the following configuration: raid3/DATA1.elid.journal So it's UFS over gjournal over bsdlabel over geli over raid3 over ata. I prefer to put gjournal on the top, because it gives consistency to layers below it. For example I can use geli with bigger sector size (sector size greater than disk sector size in encryption-only-mode can be unreliable on power failures, which is not the case when gjournal is above geli), I can turn off synchronization of gmirror/graid3 after a power failure, etc. On the other hand configuring geli on top of gjournal can be more effective for large files - geli will not encrypt the data twice. Fortunatelly with GEOM you can freely mix your puzzles. > Haven't been brave enough to try gjournal on root yet, but my /usr and > /compile (src, obj, ports) partitions are already on it so I'm sure I'll > try it soon ;) Markus Trippelsdorf reported that it doesn't work out of the box, but he manage to make it to work with some small changes to fsck_ffs(8). --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --M9NhX3UHpAaciwkO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.4 (FreeBSD) iD8DBQFE24jpForvXbEpPzQRAmenAKC/J05IojZltHSXJFETFfsgAqMYZwCdHXeQ /EXU/FMCMvMFGhyqVW6JlNE= =LvdY -----END PGP SIGNATURE----- --M9NhX3UHpAaciwkO--