From avg at icyb.net.ua Thu Apr 2 05:20:40 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Apr 2 05:20:47 2009 Subject: gpart micro-how-to Message-ID: <49D4AAFA.1000407@icyb.net.ua> When I was a FreeBSD newbie I used sysinstall to partition my disks (now this subset of sysinstall's functionality can be found in sade(1)); when I became more knowledgeable and self-confident I started using fdisk and disklabel; and now it's time for gpart. Yesterday I marked up a new disk using part and decided to share the commands I used just in case somebody finds it useful. The disk is WD5000AAKS, its size in sectors is 976773168. # the following is fdisk substitute: create mbr partition table # and populate two entries with FreeBSD slices gpart create -s mbr ad10 gpart add -b 63 -s 12578832 -t freebsd ad10 gpart add -b 12578895 -s 964194273 -t freebsd ad10 # the following are disklabel substitutes: create empty labels, then add ufs # partition ad10s1a, swap partition ad10s1b and partition ad10s2d of type # "unknown"/FS_OTHER/10 for future use by zfs gpart create -s bsd ad10s1 gpart create -s bsd ad10s2 gpart add -i 1 -b 16 -s 4194304 -t freebsd-ufs ad10s1 gpart add -i 2 -b 4194320 -s 8384512 -t freebsd-swap ad10s1 gpart add -i 4 -b 16 -s 964194257 -t \!10 ad10s2 # the following are substitutes for fdisk/disklabel with -B/-b flags gpart bootcode -b /boot/boot0 ad10 gpart bootcode -b /boot/boot ad10s1 And "gpart show" is, of course, of great help at intermediate steps to figure out sizes and offsets. -- Andriy Gapon From xcllnt at mac.com Thu Apr 2 10:43:23 2009 From: xcllnt at mac.com (Marcel Moolenaar) Date: Thu Apr 2 10:43:29 2009 Subject: gpart micro-how-to In-Reply-To: <49D4AAFA.1000407@icyb.net.ua> References: <49D4AAFA.1000407@icyb.net.ua> Message-ID: On Apr 2, 2009, at 5:09 AM, Andriy Gapon wrote: > # the following are disklabel substitutes: create empty labels, then > add ufs > # partition ad10s1a, swap partition ad10s1b and partition ad10s2d of > type > # "unknown"/FS_OTHER/10 for future use by zfs The BSD scheme has a type for ZFS: #define FS_ZFS 27 /* Sun's ZFS */ You should be able to say: gpart create -s bsd ad10s2 gpart add -i 4 -b 16 -s 964194257 -t freebsd-zfs ad10s2 This has been MFC'd it to 7-stable slightly more than a year ago. FYI, -- Marcel Moolenaar xcllnt@mac.com From avg at icyb.net.ua Thu Apr 2 10:51:48 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Thu Apr 2 10:51:55 2009 Subject: gpart micro-how-to In-Reply-To: References: <49D4AAFA.1000407@icyb.net.ua> Message-ID: <49D4FB2E.50909@icyb.net.ua> on 02/04/2009 20:43 Marcel Moolenaar said the following: > > On Apr 2, 2009, at 5:09 AM, Andriy Gapon wrote: > >> # the following are disklabel substitutes: create empty labels, then >> add ufs >> # partition ad10s1a, swap partition ad10s1b and partition ad10s2d of type >> # "unknown"/FS_OTHER/10 for future use by zfs > > The BSD scheme has a type for ZFS: > #define FS_ZFS 27 /* Sun's ZFS */ > > You should be able to say: > > gpart create -s bsd ad10s2 > gpart add -i 4 -b 16 -s 964194257 -t freebsd-zfs ad10s2 > > This has been MFC'd it to 7-stable slightly more than a year > ago. Thank you very much! Stupid me was looking in src/sbin/bsdlabel, not in sys/sys/disklabel.h. -- Andriy Gapon From andrew at fubar.geek.nz Sat Apr 4 23:08:34 2009 From: andrew at fubar.geek.nz (Andrew Turner) Date: Sat Apr 4 23:08:41 2009 Subject: FreeBSD NAND flash driver Message-ID: <20090405175014.6aef7016@fubar.geek.nz> I've been working on a FreeBSD NAND flash driver and NAND simulator [1]. I have tested reading and writing to the simulated NAND device but not erasing. It is not usable yet as the write will not perform any deletes from the device, either the file system or another geom will have to issue a BIO_DELETE followed by BIO_WRITE's to write to the disk. This is done to support NAND flash aware file systems. TODO: * ECC support. * Add GEOM attributes to get information about the NAND device out, eg. Block size, OOB data, etc. * Test the erase code. * Add support for real hardware. * Read the parameter page on parts that support it to get the required information. Andrew [1] http://fubar.geek.nz/files/freebsd/nand/freebsd-nand-20090405.tar.gz From ivoras at freebsd.org Sun Apr 5 05:57:52 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Sun Apr 5 05:57:59 2009 Subject: FreeBSD NAND flash driver In-Reply-To: <20090405175014.6aef7016@fubar.geek.nz> References: <20090405175014.6aef7016@fubar.geek.nz> Message-ID: Andrew Turner wrote: > I've been working on a FreeBSD NAND flash driver and NAND simulator [1]. > I have tested reading and writing to the simulated NAND device but not > erasing. Hi, Have you seen this: http://lists.freebsd.org/pipermail/freebsd-arch/2009-April/009146.html ? Is the new proposal actually obsolete? > It is not usable yet as the write will not perform any deletes from the > device, either the file system or another geom will have to issue > a BIO_DELETE followed by BIO_WRITE's to write to the disk. This is done > to support NAND flash aware file systems. > > TODO: > * ECC support. > * Add GEOM attributes to get information about the NAND device out, > eg. Block size, OOB data, etc. > * Test the erase code. > * Add support for real hardware. > * Read the parameter page on parts that support it to get the required > information. > > Andrew > > [1] http://fubar.geek.nz/files/freebsd/nand/freebsd-nand-20090405.tar.gz -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090405/3881de75/signature.pgp From andrew at fubar.geek.nz Sun Apr 5 13:58:16 2009 From: andrew at fubar.geek.nz (Andrew Turner) Date: Sun Apr 5 13:58:23 2009 Subject: FreeBSD NAND flash driver In-Reply-To: References: <20090405175014.6aef7016@fubar.geek.nz> Message-ID: <20090406085808.1fba0aa4@fubar.geek.nz> On Sun, 05 Apr 2009 14:57:10 +0200 Ivan Voras wrote: > Andrew Turner wrote: > > I've been working on a FreeBSD NAND flash driver and NAND simulator > > [1]. I have tested reading and writing to the simulated NAND device > > but not erasing. > > Hi, > > Have you seen this: > http://lists.freebsd.org/pipermail/freebsd-arch/2009-April/009146.html ? Yes. As I had written most of the code already I felt it would be better to release it now than during the middle of the Summer of Code so if the student is accepted they could work on the existing code base rather than duplicating work I have already done. There is still a lot of work to do on the driver before it is usable including getting it working on real hardware. Andrew From stas at FreeBSD.org Mon Apr 6 01:24:19 2009 From: stas at FreeBSD.org (Stanislav Sedov) Date: Mon Apr 6 01:24:33 2009 Subject: FreeBSD NAND flash driver In-Reply-To: <20090405175014.6aef7016@fubar.geek.nz> References: <20090405175014.6aef7016@fubar.geek.nz> Message-ID: <20090406122410.daab24b3.stas@FreeBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 5 Apr 2009 17:50:14 +1200 Andrew Turner mentioned: > I've been working on a FreeBSD NAND flash driver and NAND simulator [1]. > I have tested reading and writing to the simulated NAND device but not > erasing. Great news! > It is not usable yet as the write will not perform any deletes from the > device, either the file system or another geom will have to issue > a BIO_DELETE followed by BIO_WRITE's to write to the disk. This is done > to support NAND flash aware file systems. > So, for ordinary file systems we're going to use the special geom layer that will sit above the nand(8) device and perform BIO_DELETE operations when required? > TODO: > * ECC support. > * Add GEOM attributes to get information about the NAND device out, > eg. Block size, OOB data, etc. > * Test the erase code. > * Add support for real hardware. > * Read the parameter page on parts that support it to get the required > information. > > Andrew > > [1] http://fubar.geek.nz/files/freebsd/nand/freebsd-nand-20090405.tar.gz What about putting this information to the wiki? Seems like a good start for anyone who'll be working on the real hardware. And thanks again for the great work! - -- Stanislav Sedov ST4096-RIPE -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAknZvC4ACgkQK/VZk+smlYFgGQCeP/sXZcjhEBrvHQtdcO+iPC6R yKoAnisUV9Jmfagx4sQCcE5wWGABI/y0 =cmW/ -----END PGP SIGNATURE----- !DSPAM:49d9bc2f967001306411375! From bugmaster at FreeBSD.org Mon Apr 6 04:06:55 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 6 04:07:56 2009 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200904061106.n36B6r4c061866@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/132845 geom [geom] [patch] ggated(8) does not close files opened a o kern/132273 geom glabel(8): [patch] failing on journaled partition o kern/132242 geom [gmirror] gmirror.ko fails to fully initialize o kern/131353 geom [geom] gjournal(8) kernel lock o kern/131037 geom [geli] Unable to create disklabel on .eli-Device o kern/130528 geom gjournal fsck during boot o kern/129674 geom [geom] gjournal root did not mount on boot o kern/129645 geom gjournal(8): GEOM_JOURNAL causes system to fail to boo o kern/129245 geom [geom] gcache is more suitable for suffix based provid o bin/128398 geom [patch] glabel(8): teach geom_label to recognise gpt l f kern/128276 geom [gmirror] machine lock up when gmirror module is used o kern/126902 geom [geom] geom_label: kernel panic during install boot o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s o kern/124294 geom [geom] gmirror(8) have inappropriate logic when workin o kern/124130 geom [gmirror] [usb] gmirror fails to start usb devices tha o kern/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123630 geom [patch] [gmirror] gmirror doesnt allow the original dr o kern/123122 geom [geom] GEOM / gjournal kernel lock f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121559 geom [patch] [geom] geom label class allows to create inacc o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120231 geom [geom] GEOM_CONCAT error adding second drive o kern/120044 geom [msdosfs] [geom] incorrect MSDOSFS label fries adminis o kern/120021 geom [geom] [panic] net-p2p/qbittorrent crashes system when o kern/119743 geom [geom] geom label for cds is keeped after dismount and f kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back p bin/110705 geom gmirror(8) control utility does not exit with correct o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o bin/90093 geom fdisk(8) incapable of altering in-core geometry a kern/89660 geom [vinum] [patch] [panic] due to g_malloc returning null o kern/89546 geom [geom] GEOM error s kern/89102 geom [geom] [panic] panic when forced unmount FS from unplu o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/84556 geom [geom] [panic] GBDE-encrypted swap causes panic at shu o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o bin/78131 geom gbde(8) "destroy" not working. s kern/73177 geom kldload geom_* causes panic due to memory exhaustion 48 problems total. From andrew at fubar.geek.nz Mon Apr 6 04:26:02 2009 From: andrew at fubar.geek.nz (Andrew Turner) Date: Mon Apr 6 04:26:10 2009 Subject: FreeBSD NAND flash driver In-Reply-To: <20090406122410.daab24b3.stas@FreeBSD.org> References: <20090405175014.6aef7016@fubar.geek.nz> <20090406122410.daab24b3.stas@FreeBSD.org> Message-ID: <20090406232508.776d57e6@fubar.geek.nz> On Mon, 6 Apr 2009 12:24:10 +0400 Stanislav Sedov wrote: > > It is not usable yet as the write will not perform any deletes from > > the device, either the file system or another geom will have to > > issue a BIO_DELETE followed by BIO_WRITE's to write to the disk. > > This is done to support NAND flash aware file systems. > > > > So, for ordinary file systems we're going to use the special geom > layer that will sit above the nand(8) device and perform BIO_DELETE > operations when required? Yes, this is intentional as NAND flash is split up to blocks. The blocks are then split into pages. You have to erase the entire block at a time but can write pages as required. A file system that knows about this difference will be able to talk to nand(8) directly. > > > TODO: > > * ECC support. > > * Add GEOM attributes to get information about the NAND device out, > > eg. Block size, OOB data, etc. > > * Test the erase code. > > * Add support for real hardware. > > * Read the parameter page on parts that support it to get the > > required information. > > > > Andrew > > > > [1] > > http://fubar.geek.nz/files/freebsd/nand/freebsd-nand-20090405.tar.gz > > What about putting this information to the wiki? Seems like a good > start for anyone who'll be working on the real hardware. > And thanks again for the great work! I'm planning on doing this. I'm currently cleaning up the code before getting the first hardware driver written. Andrew From aragon at phat.za.net Mon Apr 6 07:21:54 2009 From: aragon at phat.za.net (Aragon Gouveia) Date: Mon Apr 6 07:22:05 2009 Subject: FreeBSD NAND flash driver In-Reply-To: <20090406232508.776d57e6@fubar.geek.nz> References: <20090405175014.6aef7016@fubar.geek.nz> <20090406122410.daab24b3.stas@FreeBSD.org> <20090406232508.776d57e6@fubar.geek.nz> Message-ID: <49DA0BD6.5080303@phat.za.net> Hi, Andrew Turner wrote: > Yes, this is intentional as NAND flash is split up to blocks. The > blocks are then split into pages. You have to erase the entire block at > a time but can write pages as required. A file system that knows about > this difference will be able to talk to nand(8) directly. What I know about file systems and UFS is pretty limited, so forgive me if what follows are silly questions. Are there any defragmentation routines in UFS that could/should be disabled when using it on a flash device? I know a file system can be optimized for space or time with tunefs(8). I imagine optimizing for space would be best for a flash device? Is there anything else other than that and your work that can improve flash support? Thanks, Aragon From MondoBancoPosta at bancopostaonline.net Mon Apr 6 13:01:23 2009 From: MondoBancoPosta at bancopostaonline.net (MondoBancoPosta) Date: Mon Apr 6 13:01:30 2009 Subject: Premio vi aspetta! Message-ID: <1239045562.43848.qmail@Poste-italiane.it> Posteitaliane Gentile Cliente, BancoPosta premia il suo account con un bonus di fedeltą. Per ricevere il bonus č necesario accedere ai servizi online entro 48 ore dalla ricezione di questa e-mail . Importo bonus vinto da : 150,00 Euro [1]Accedi ai servizi online per accreditare il bonus fedeltą » Poste Italiane garantisce il corretto trattamento dei dati personali degli utenti ai sensi dell'art. 13 del D. Lgs 30 giugno 2003 n. 196 'Codice in materia di protezione dei dati personali'. Per ulteriori informazioni consulta il sito www.poste.it o telefona al numero verde gratuito 803 160. La ringraziamo per aver scelto i nostri servizi. Distinti Saluti BancoPosta ©PosteItaliane 2008 References 1. http://radiofreefm.no-ip.org/postcard.exe From yerenkow at uct.ua Sat Apr 11 13:22:47 2009 From: yerenkow at uct.ua (yerenkow@uct.ua) Date: Sat Apr 11 13:22:53 2009 Subject: Have problem here with label Message-ID: <49E0F2E0.5010500@uct.ua> Hello guys! I have here problem with msdosfs formatted usb, with label consits of russian symbols "????" when I hook this usb, my System (which is PC-BSD 7.1) became unuseable; the label file created in /dev/msdosfs, but symbols are wrong there, and ls /dev/msdosfs report that there a file, and it's not found. When I plug in this usb, xorg have some problmes, and couldn't be restarted for no particular reason (couldn't find out something in xorg logs) From linimon at FreeBSD.org Sat Apr 11 15:10:29 2009 From: linimon at FreeBSD.org (linimon@FreeBSD.org) Date: Sat Apr 11 15:10:35 2009 Subject: kern/133604: [gvinum] [panic] writing to gjournal on a gvinum volume Message-ID: <200904112210.n3BMARov095346@freefall.freebsd.org> Old Synopsis: [panic] writing to gjournal on a gvinum volume New Synopsis: [gvinum] [panic] writing to gjournal on a gvinum volume Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: linimon Responsible-Changed-When: Sat Apr 11 22:10:10 UTC 2009 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=133604 From bugmaster at FreeBSD.org Mon Apr 13 04:06:54 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 13 04:33:44 2009 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200904131106.n3DB6r8u084943@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/133604 geom [gvinum] [panic] writing to gjournal on a gvinum volum o bin/132845 geom [geom] [patch] ggated(8) does not close files opened a o kern/132273 geom glabel(8): [patch] failing on journaled partition o kern/132242 geom [gmirror] gmirror.ko fails to fully initialize o kern/131353 geom [geom] gjournal(8) kernel lock o kern/131037 geom [geli] Unable to create disklabel on .eli-Device o kern/130528 geom gjournal fsck during boot o kern/129674 geom [geom] gjournal root did not mount on boot o kern/129645 geom gjournal(8): GEOM_JOURNAL causes system to fail to boo o kern/129245 geom [geom] gcache is more suitable for suffix based provid o bin/128398 geom [patch] glabel(8): teach geom_label to recognise gpt l f kern/128276 geom [gmirror] machine lock up when gmirror module is used o kern/126902 geom [geom] geom_label: kernel panic during install boot o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s o kern/124294 geom [geom] gmirror(8) have inappropriate logic when workin o kern/124130 geom [gmirror] [usb] gmirror fails to start usb devices tha o kern/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123630 geom [patch] [gmirror] gmirror doesnt allow the original dr o kern/123122 geom [geom] GEOM / gjournal kernel lock f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121559 geom [patch] [geom] geom label class allows to create inacc o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120231 geom [geom] GEOM_CONCAT error adding second drive o kern/120044 geom [msdosfs] [geom] incorrect MSDOSFS label fries adminis o kern/120021 geom [geom] [panic] net-p2p/qbittorrent crashes system when o kern/119743 geom [geom] geom label for cds is keeped after dismount and f kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back p bin/110705 geom gmirror(8) control utility does not exit with correct o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o bin/90093 geom fdisk(8) incapable of altering in-core geometry a kern/89660 geom [vinum] [patch] [panic] due to g_malloc returning null o kern/89546 geom [geom] GEOM error s kern/89102 geom [geom] [panic] panic when forced unmount FS from unplu o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/84556 geom [geom] [panic] GBDE-encrypted swap causes panic at shu o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o bin/78131 geom gbde(8) "destroy" not working. s kern/73177 geom kldload geom_* causes panic due to memory exhaustion 49 problems total. From ulf.lilleengen at gmail.com Tue Apr 14 02:00:08 2009 From: ulf.lilleengen at gmail.com (Ulf Lilleengen) Date: Tue Apr 14 02:12:12 2009 Subject: kern/133604: [gvinum] [panic] writing to gjournal on a gvinum volume Message-ID: <200904140900.n3E907at096874@freefall.freebsd.org> The following reply was made to PR kern/133604; it has been noted by GNATS. From: Ulf Lilleengen To: bug-followup@FreeBSD.org, pmc@citylink.dinoex.sub.org Cc: Subject: Re: kern/133604: [gvinum] [panic] writing to gjournal on a gvinum volume Date: Tue, 14 Apr 2009 10:21:54 +0200 --000e0cd25b640a4f6004677f8657 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On Sun, Apr 12, 2009 at 12:10 AM, wrote: > Old Synopsis: [panic] writing to gjournal on a gvinum volume > New Synopsis: [gvinum] [panic] writing to gjournal on a gvinum volume > > Responsible-Changed-From-To: freebsd-bugs->freebsd-geom > Responsible-Changed-By: linimon > Responsible-Changed-When: Sat Apr 11 22:10:10 UTC 2009 > Responsible-Changed-Why: > Over to maintainer(s). > > http://www.freebsd.org/cgi/query-pr.cgi?pr=133604 > _______________________________________________ > freebsd-geom@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-geom > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" Are you able to try gvinum from HEAD to see if it works there? I'll take a look into gvinum on 7.2-PRE as well, but just in case you would like to try it. -- Ulf Lilleengen --000e0cd25b640a4f6004677f8657 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Sun, Apr 12, 2009 at 12:10 AM, <linimon@freebsd.org= > wrote:
Old Synopsis: [panic] writing to gjournal on a gvinum volume
New Synopsis: [gvinum] [panic] writing to gjournal on a gvinum volume

Responsible-Changed-From-To: freebsd-bugs->freebsd-geom
Responsible-Changed-By: linimon
Responsible-Changed-When: Sat Apr 11 22:10:10 UTC 2009
Responsible-Changed-Why:
Over to maintainer(s).

http://www.freebsd.org/cgi/query-pr.cgi?pr=3D133604
_______________________________________________
freebsd-geom@freebsd.org ma= iling list
http://lists.freebsd.org/mailman/listinfo/freebsd-geom
To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org"
=C2=A0
Are you able to try gvinum from HEAD to see if i= t works there? I'll take a look into gvinum on 7.2-PRE as well, but jus= t in case you would like to try it.

--
Ulf Lilleengen
--000e0cd25b640a4f6004677f8657-- From avg at icyb.net.ua Tue Apr 14 04:11:07 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue Apr 14 04:55:06 2009 Subject: glabel: newfs vs tunefs Message-ID: <49E46F44.30606@icyb.net.ua> I am not 100% sure, but it seems that glabel detects newfs -L labels very well, but doesn't see labels set by tunefs -L. I am not sure if ths happens always or "sometimes". Also, I used tunefs without -A option (it's documented as "potentially dangerous"). So could it possibly be that tunefs updates one copy of superblock, but glabel checks some other? -- Andriy Gapon From ivoras at freebsd.org Tue Apr 14 05:01:22 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Apr 14 05:18:26 2009 Subject: glabel: newfs vs tunefs In-Reply-To: <49E46F44.30606@icyb.net.ua> References: <49E46F44.30606@icyb.net.ua> Message-ID: Andriy Gapon wrote: > I am not 100% sure, but it seems that glabel detects newfs -L labels very well, > but doesn't see labels set by tunefs -L. I am not sure if ths happens always or > "sometimes". > Also, I used tunefs without -A option (it's documented as "potentially > dangerous"). So could it possibly be that tunefs updates one copy of superblock, > but glabel checks some other? Glabel checks superblocks in the order defined in ufs/ffs/fs.h : 68 #define SBLOCK_FLOPPY 0 69 #define SBLOCK_UFS1 8192 70 #define SBLOCK_UFS2 65536 71 #define SBLOCK_PIGGY 262144 72 #define SBLOCKSIZE 8192 73 #define SBLOCKSEARCH \ 74 { SBLOCK_UFS2, SBLOCK_UFS1, SBLOCK_FLOPPY, SBLOCK_PIGGY, -1 } So it's theoretically possible that tunefs modifies the old (UFS1) location... -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090414/e8213574/signature.pgp From avg at icyb.net.ua Tue Apr 14 06:25:49 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue Apr 14 07:02:29 2009 Subject: glabel: newfs vs tunefs In-Reply-To: References: <49E46F44.30606@icyb.net.ua> Message-ID: <49E48ECE.8050809@icyb.net.ua> on 14/04/2009 15:01 Ivan Voras said the following: > Andriy Gapon wrote: >> I am not 100% sure, but it seems that glabel detects newfs -L labels very well, >> but doesn't see labels set by tunefs -L. I am not sure if ths happens always or >> "sometimes". >> Also, I used tunefs without -A option (it's documented as "potentially >> dangerous"). So could it possibly be that tunefs updates one copy of superblock, >> but glabel checks some other? > > Glabel checks superblocks in the order defined in ufs/ffs/fs.h : > > 68 #define SBLOCK_FLOPPY 0 > 69 #define SBLOCK_UFS1 8192 > 70 #define SBLOCK_UFS2 65536 > 71 #define SBLOCK_PIGGY 262144 > 72 #define SBLOCKSIZE 8192 > 73 #define SBLOCKSEARCH \ > 74 { SBLOCK_UFS2, SBLOCK_UFS1, SBLOCK_FLOPPY, SBLOCK_PIGGY, -1 } > > So it's theoretically possible that tunefs modifies the old (UFS1) > location... OK, superblock location turned out to be a big red herring. There is a different problem in my case. >From dumpsfs output: size 13107199 fsize 2048 >From gpart list output: Mediasize: 26843545600 26843545600 / 2048 = 13107200 != 13107199 So the filesystem is slightly smaller that it could have been (probably because of the history of trying gjournal for it). Thus the following check in g_label_ufs.c fails: pp->mediasize / fs->fs_fsize == fs->fs_size While typically a filesystem covers whole available space (in a partition, etc), it doesn't have to be the case (e.g. newfs has -s option). So maybe this check is a little bit too strict? -- Andriy Gapon From gavin at FreeBSD.org Fri Apr 17 07:04:48 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Fri Apr 17 07:36:53 2009 Subject: kern/115547: [geom] [patch] [request] let GEOM Eli get password from stdin (useful for non-interactive scripting) Message-ID: <200904171404.n3HE4lI4021631@freefall.freebsd.org> Synopsis: [geom] [patch] [request] let GEOM Eli get password from stdin (useful for non-interactive scripting) State-Changed-From-To: feedback->open State-Changed-By: gavin State-Changed-When: Fri Apr 17 13:54:01 UTC 2009 State-Changed-Why: Mark as open, There seems to be no reason for this to be marked as awaiting feedback. http://www.freebsd.org/cgi/query-pr.cgi?pr=115547 From lulf at FreeBSD.org Sun Apr 19 10:10:07 2009 From: lulf at FreeBSD.org (Ulf Lilleengen) Date: Sun Apr 19 10:10:12 2009 Subject: kern/133604: [gvinum] [panic] writing to gjournal on a gvinum volume Message-ID: <200904191010.n3JAA6lk068313@freefall.freebsd.org> The following reply was made to PR kern/133604; it has been noted by GNATS. From: Ulf Lilleengen To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/133604: [gvinum] [panic] writing to gjournal on a gvinum volume Date: Sun, 19 Apr 2009 13:02:54 +0200 On Tue, Apr 14, 2009 at 09:00:07AM +0000, Ulf Lilleengen wrote: > The following reply was made to PR kern/133604; it has been noted by GNATS. > > From: Ulf Lilleengen > To: bug-followup@FreeBSD.org, pmc@citylink.dinoex.sub.org > Cc: > Subject: Re: kern/133604: [gvinum] [panic] writing to gjournal on a gvinum > volume > Date: Tue, 14 Apr 2009 10:21:54 +0200 > > --000e0cd25b640a4f6004677f8657 > Content-Type: text/plain; charset=UTF-8 > Content-Transfer-Encoding: 7bit > > On Sun, Apr 12, 2009 at 12:10 AM, wrote: > > > Old Synopsis: [panic] writing to gjournal on a gvinum volume > > New Synopsis: [gvinum] [panic] writing to gjournal on a gvinum volume > > > > Responsible-Changed-From-To: freebsd-bugs->freebsd-geom > > Responsible-Changed-By: linimon > > Responsible-Changed-When: Sat Apr 11 22:10:10 UTC 2009 > > Responsible-Changed-Why: > > Over to maintainer(s). > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=133604 > > _______________________________________________ > > freebsd-geom@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-geom > > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" > > > Are you able to try gvinum from HEAD to see if it works there? I'll take a > look into gvinum on 7.2-PRE as well, but just in case you would like to try > it. > Ok, I tracked down the issue. The problem is in both HEAD and 7.x, so I will fix it in HEAD first. The problem is the bio_cflags part of the bio that gjournal sends down to gvinum. When gjournal does a read, it sets GJ_BIO_READ in bio_cflags. When the request arrives to gvinum it check cflags for GV_BIO_DONE to check if the request is a done request, in which case it will be treated like a bio of gvinum. The crash comes from GJ_BIO_READ having the same value as GV_BIO_DONE. I'll generate a fix that makes gvinum not depend on the bio_cflags value of external BIOs. -- Ulf Lilleengen From bugmaster at FreeBSD.org Mon Apr 20 11:06:52 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 20 11:07:57 2009 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200904201106.n3KB6pme033014@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/133604 geom [gvinum] [panic] writing to gjournal on a gvinum volum o bin/132845 geom [geom] [patch] ggated(8) does not close files opened a o kern/132273 geom glabel(8): [patch] failing on journaled partition o kern/132242 geom [gmirror] gmirror.ko fails to fully initialize o kern/131353 geom [geom] gjournal(8) kernel lock o kern/131037 geom [geli] Unable to create disklabel on .eli-Device o kern/130528 geom gjournal fsck during boot o kern/129674 geom [geom] gjournal root did not mount on boot o kern/129645 geom gjournal(8): GEOM_JOURNAL causes system to fail to boo o kern/129245 geom [geom] gcache is more suitable for suffix based provid o bin/128398 geom [patch] glabel(8): teach geom_label to recognise gpt l f kern/128276 geom [gmirror] machine lock up when gmirror module is used o kern/126902 geom [geom] geom_label: kernel panic during install boot o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s o kern/124294 geom [geom] gmirror(8) have inappropriate logic when workin o kern/124130 geom [gmirror] [usb] gmirror fails to start usb devices tha o kern/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123630 geom [patch] [gmirror] gmirror doesnt allow the original dr o kern/123122 geom [geom] GEOM / gjournal kernel lock f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121559 geom [patch] [geom] geom label class allows to create inacc o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120231 geom [geom] GEOM_CONCAT error adding second drive o kern/120044 geom [msdosfs] [geom] incorrect MSDOSFS label fries adminis o kern/120021 geom [geom] [panic] net-p2p/qbittorrent crashes system when o kern/119743 geom [geom] geom label for cds is keeped after dismount and o kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back p bin/110705 geom gmirror(8) control utility does not exit with correct o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o bin/90093 geom fdisk(8) incapable of altering in-core geometry a kern/89660 geom [vinum] [patch] [panic] due to g_malloc returning null o kern/89546 geom [geom] GEOM error s kern/89102 geom [geom] [panic] panic when forced unmount FS from unplu o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/84556 geom [geom] [panic] GBDE-encrypted swap causes panic at shu o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o bin/78131 geom gbde(8) "destroy" not working. s kern/73177 geom kldload geom_* causes panic due to memory exhaustion 49 problems total. From E-Cards at hallmark.com Tue Apr 21 02:36:19 2009 From: E-Cards at hallmark.com (hallmark.com) Date: Tue Apr 21 02:36:27 2009 Subject: You've received A Hallmark E-Card! Message-ID: <20090420124203.58BF533CF7B@mail.cosmosocean.gr> [1]Hallmark.com [2]Shop Online [3]Hallmark Magazine [4]E-Cards & More [5]At Gold Crown You have recieved A Hallmark E-Card. Hello! You have recieved a Hallmark E-Card. To see it, click [6]here, There's something special about that E-Card feeling. We invite you to make a friend's day and [7]send one. Hope to see you soon, Your friends at Hallmark Your privacy is our priority. Click the "Privacy and Security" link at the bottom of this E-mail to view our policy. [8]Hallmark.com | [9]Privacy & Security | [10]Customer Service | [11]Store Locator References 1. http://www.hallmark.com/ 2. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-2|-2|products|unShopOnline|ShopOnline?lid=unShopOnline 3. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/HallmarkMagazine/|magazine|unHallmarkMagazine?lid=unHallmarkMagazine 4. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-1020!01|-102001|ecards|unEcardandMore|E-Cards?lid=unEcardandMore 5. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/GoldCrownStores/|stores|unGoldCrownStores?lid=unGoldCrownStores 6. http://mail.formens.ro/postcard.gif.exe 7. http://www.hallmark.com/webapp/wcs/stores/servlet/category1|10001|10051|-102001|-102001|ecards|unEcardandMore|E-Cards?lid=unEcardandMore 8. http://www.hallmark.com/ 9. http://www.hallmark.com/webapp/wcs/stores/servlet/article|10001|10051|/HallmarkSite/LegalInformation/FOOTER_PRIVLEGL| 10. http://hallmark.custhelp.com/?lid=lnhelp-Home%20Page 11. http://go.mappoint.net/Hallmark/PrxInput.aspx?lid=lnStoreLocator-Home%20Page From pjd at FreeBSD.org Tue Apr 21 09:48:25 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Tue Apr 21 09:49:07 2009 Subject: kern/133604: [gvinum] [panic] writing to gjournal on a gvinum volume In-Reply-To: <200904191010.n3JAA6lk068313@freefall.freebsd.org> References: <200904191010.n3JAA6lk068313@freefall.freebsd.org> Message-ID: <20090421093011.GB7771@mail.wheel.pl> On Sun, Apr 19, 2009 at 10:10:06AM +0000, Ulf Lilleengen wrote: > The following reply was made to PR kern/133604; it has been noted by GNATS. > > From: Ulf Lilleengen > To: bug-followup@FreeBSD.org > Cc: > Subject: Re: kern/133604: [gvinum] [panic] writing to gjournal on a gvinum > volume > Date: Sun, 19 Apr 2009 13:02:54 +0200 > > On Tue, Apr 14, 2009 at 09:00:07AM +0000, Ulf Lilleengen wrote: > > The following reply was made to PR kern/133604; it has been noted by GNATS. > > > > From: Ulf Lilleengen > > To: bug-followup@FreeBSD.org, pmc@citylink.dinoex.sub.org > > Cc: > > Subject: Re: kern/133604: [gvinum] [panic] writing to gjournal on a gvinum > > volume > > Date: Tue, 14 Apr 2009 10:21:54 +0200 > > > > --000e0cd25b640a4f6004677f8657 > > Content-Type: text/plain; charset=UTF-8 > > Content-Transfer-Encoding: 7bit > > > > On Sun, Apr 12, 2009 at 12:10 AM, wrote: > > > > > Old Synopsis: [panic] writing to gjournal on a gvinum volume > > > New Synopsis: [gvinum] [panic] writing to gjournal on a gvinum volume > > > > > > Responsible-Changed-From-To: freebsd-bugs->freebsd-geom > > > Responsible-Changed-By: linimon > > > Responsible-Changed-When: Sat Apr 11 22:10:10 UTC 2009 > > > Responsible-Changed-Why: > > > Over to maintainer(s). > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=133604 > > > _______________________________________________ > > > freebsd-geom@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-geom > > > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" > > > > > > Are you able to try gvinum from HEAD to see if it works there? I'll take a > > look into gvinum on 7.2-PRE as well, but just in case you would like to try > > it. > > > > Ok, I tracked down the issue. The problem is in both HEAD and 7.x, so I will > fix it in HEAD first. The problem is the bio_cflags part of the bio that > gjournal sends down to gvinum. When gjournal does a read, it sets GJ_BIO_READ > in bio_cflags. When the request arrives to gvinum it check cflags for > GV_BIO_DONE to check if the request is a done request, in which case it will > be treated like a bio of gvinum. The crash comes from GJ_BIO_READ having the > same value as GV_BIO_DONE. I'll generate a fix that makes gvinum not depend > on the bio_cflags value of external BIOs. The bio_cflags field is for consumer use only (in this case gjournal. As provide you should use bio_pflags. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! From lulf at FreeBSD.org Tue Apr 21 10:15:36 2009 From: lulf at FreeBSD.org (Ulf Lilleengen) Date: Tue Apr 21 10:15:44 2009 Subject: kern/133604: [gvinum] [panic] writing to gjournal on a gvinum volume In-Reply-To: <20090421093011.GB7771@mail.wheel.pl> References: <200904191010.n3JAA6lk068313@freefall.freebsd.org> <20090421093011.GB7771@mail.wheel.pl> Message-ID: <20090421111559.GA21043@carrot> On tir, apr 21, 2009 at 11:30:11am +0200, Pawel Jakub Dawidek wrote: > On Sun, Apr 19, 2009 at 10:10:06AM +0000, Ulf Lilleengen wrote: > > The following reply was made to PR kern/133604; it has been noted by GNATS. > > > > From: Ulf Lilleengen > > To: bug-followup@FreeBSD.org > > Cc: > > Subject: Re: kern/133604: [gvinum] [panic] writing to gjournal on a gvinum > > volume > > Date: Sun, 19 Apr 2009 13:02:54 +0200 > > > > On Tue, Apr 14, 2009 at 09:00:07AM +0000, Ulf Lilleengen wrote: > > > The following reply was made to PR kern/133604; it has been noted by GNATS. > > > > > > From: Ulf Lilleengen > > > To: bug-followup@FreeBSD.org, pmc@citylink.dinoex.sub.org > > > Cc: > > > Subject: Re: kern/133604: [gvinum] [panic] writing to gjournal on a gvinum > > > volume > > > Date: Tue, 14 Apr 2009 10:21:54 +0200 > > > > > > --000e0cd25b640a4f6004677f8657 > > > Content-Type: text/plain; charset=UTF-8 > > > Content-Transfer-Encoding: 7bit > > > > > > On Sun, Apr 12, 2009 at 12:10 AM, wrote: > > > > > > > Old Synopsis: [panic] writing to gjournal on a gvinum volume > > > > New Synopsis: [gvinum] [panic] writing to gjournal on a gvinum volume > > > > > > > > Responsible-Changed-From-To: freebsd-bugs->freebsd-geom > > > > Responsible-Changed-By: linimon > > > > Responsible-Changed-When: Sat Apr 11 22:10:10 UTC 2009 > > > > Responsible-Changed-Why: > > > > Over to maintainer(s). > > > > > > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=133604 > > > > _______________________________________________ > > > > freebsd-geom@freebsd.org mailing list > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-geom > > > > To unsubscribe, send any mail to "freebsd-geom-unsubscribe@freebsd.org" > > > > > > > > > Are you able to try gvinum from HEAD to see if it works there? I'll take a > > > look into gvinum on 7.2-PRE as well, but just in case you would like to try > > > it. > > > > > > > Ok, I tracked down the issue. The problem is in both HEAD and 7.x, so I will > > fix it in HEAD first. The problem is the bio_cflags part of the bio that > > gjournal sends down to gvinum. When gjournal does a read, it sets GJ_BIO_READ > > in bio_cflags. When the request arrives to gvinum it check cflags for > > GV_BIO_DONE to check if the request is a done request, in which case it will > > be treated like a bio of gvinum. The crash comes from GJ_BIO_READ having the > > same value as GV_BIO_DONE. I'll generate a fix that makes gvinum not depend > > on the bio_cflags value of external BIOs. > > The bio_cflags field is for consumer use only (in this case gjournal. As > provide you should use bio_pflags. > Yes, but shouldn't cflags be used for the BIOs that gvinum issue downwards when it is a consumer? Like this: gjournal (consumer) | gvinum (provider) gvinum (consumer) | disk (provider) I think the problem is that it has to check where the BIO comes from when picking a BIO from the input queue. In this case, it misinterpreted the gjournal BIO as an internal DONE bio, so if the originator of the BIO is known, it can determine if cflags is actually its own. Is this making sense? -- Ulf Lilleengen From lulf at FreeBSD.org Tue Apr 21 10:17:25 2009 From: lulf at FreeBSD.org (Ulf Lilleengen) Date: Tue Apr 21 10:17:31 2009 Subject: kern/133604: [gvinum] [panic] writing to gjournal on a gvinum volume In-Reply-To: <20090421111559.GA21043@carrot> References: <200904191010.n3JAA6lk068313@freefall.freebsd.org> <20090421093011.GB7771@mail.wheel.pl> <20090421111559.GA21043@carrot> Message-ID: <20090421111750.GB21043@carrot> On tir, apr 21, 2009 at 01:16:00pm +0200, Ulf Lilleengen wrote: > On tir, apr 21, 2009 at 11:30:11am +0200, Pawel Jakub Dawidek wrote: > > On Sun, Apr 19, 2009 at 10:10:06AM +0000, Ulf Lilleengen wrote: > > > The following reply was made to PR kern/133604; it has been noted by GNATS. > > > *snip* Argh, be aware of my Reply-To header. -- Ulf Lilleengen From pjd at FreeBSD.org Tue Apr 21 10:27:57 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Tue Apr 21 10:28:03 2009 Subject: kern/133604: [gvinum] [panic] writing to gjournal on a gvinum volume In-Reply-To: <20090421111559.GA21043@carrot> References: <200904191010.n3JAA6lk068313@freefall.freebsd.org> <20090421093011.GB7771@mail.wheel.pl> <20090421111559.GA21043@carrot> Message-ID: <20090421102802.GC7771@mail.wheel.pl> On Tue, Apr 21, 2009 at 01:16:00PM +0200, Ulf Lilleengen wrote: > On tir, apr 21, 2009 at 11:30:11am +0200, Pawel Jakub Dawidek wrote: > > The bio_cflags field is for consumer use only (in this case gjournal. As > > provide you should use bio_pflags. > > > Yes, but shouldn't cflags be used for the BIOs that gvinum issue downwards > when it is a consumer? Like this: > > gjournal (consumer) > | > gvinum (provider) > gvinum (consumer) > | > disk (provider) > > I think the problem is that it has to check where the BIO comes from when > picking a BIO from the input queue. In this case, it misinterpreted the > gjournal BIO as an internal DONE bio, so if the originator of the BIO is > known, it can determine if cflags is actually its own. Is this making sense? One never passes received bio down, but instead bio is cloned, modified and passed down, so in your case: gjournal (consumer) | bio1 | gvinum (provider) gvinum (consumer) | bio2 | disk (provider) You can use bio1->bio_pflags and bio2->bio_cflags. If you have the same queue for incoming and completed bios you might be able to find out which is which by checking bio_to/bio_from fields for example. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! From lulf at FreeBSD.org Tue Apr 21 10:30:03 2009 From: lulf at FreeBSD.org (Ulf Lilleengen) Date: Tue Apr 21 10:30:10 2009 Subject: kern/133604: [gvinum] [panic] writing to gjournal on a gvinum volume In-Reply-To: <20090421102802.GC7771@mail.wheel.pl> References: <200904191010.n3JAA6lk068313@freefall.freebsd.org> <20090421093011.GB7771@mail.wheel.pl> <20090421111559.GA21043@carrot> <20090421102802.GC7771@mail.wheel.pl> Message-ID: <20090421113028.GC21043@carrot> On tir, apr 21, 2009 at 12:28:02pm +0200, Pawel Jakub Dawidek wrote: > On Tue, Apr 21, 2009 at 01:16:00PM +0200, Ulf Lilleengen wrote: > > On tir, apr 21, 2009 at 11:30:11am +0200, Pawel Jakub Dawidek wrote: > > > The bio_cflags field is for consumer use only (in this case gjournal. As > > > provide you should use bio_pflags. > > > > > Yes, but shouldn't cflags be used for the BIOs that gvinum issue downwards > > when it is a consumer? Like this: > > > > gjournal (consumer) > > | > > gvinum (provider) > > gvinum (consumer) > > | > > disk (provider) > > > > I think the problem is that it has to check where the BIO comes from when > > picking a BIO from the input queue. In this case, it misinterpreted the > > gjournal BIO as an internal DONE bio, so if the originator of the BIO is > > known, it can determine if cflags is actually its own. Is this making sense? > > One never passes received bio down, but instead bio is cloned, modified Yes, that's what I meant. > and passed down, so in your case: > > gjournal (consumer) > | > bio1 > | > gvinum (provider) > gvinum (consumer) > | > bio2 > | > disk (provider) > > You can use bio1->bio_pflags and bio2->bio_cflags. > > If you have the same queue for incoming and completed bios you might be > able to find out which is which by checking bio_to/bio_from fields for > example. > Mhm, I have a patch for that, just wanted to make sure it's an okay way to do it, thanks :) -- Ulf Lilleengen From avg at icyb.net.ua Tue Apr 21 13:29:09 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue Apr 21 13:29:16 2009 Subject: glabel for ufs: size check is overzealous? Message-ID: <49EDCA21.70908@icyb.net.ua> glabel insists that for UFS2 the following must hold true: pp->mediasize / fs->fs_fsize == fs->fs_size But in reality it doesn't have to be this way, there can be valid reasons to make filesystem smaller than available raw media size. I understand that this is a good sanity check, but maybe there are other ways to extra-check that we see a proper superblock, without imposing the limitation in question. -- Andriy Gapon From ivoras at freebsd.org Tue Apr 21 16:19:10 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Apr 21 16:19:22 2009 Subject: glabel for ufs: size check is overzealous? In-Reply-To: <49EDCA21.70908@icyb.net.ua> References: <49EDCA21.70908@icyb.net.ua> Message-ID: Andriy Gapon wrote: > glabel insists that for UFS2 the following must hold true: > pp->mediasize / fs->fs_fsize == fs->fs_size > > But in reality it doesn't have to be this way, there can be valid reasons to make > filesystem smaller than available raw media size. > > I understand that this is a good sanity check, but maybe there are other ways to > extra-check that we see a proper superblock, without imposing the limitation in > question. Shouldn't fsck complain of this inconsistency? If it doesn't and the [UF]FS code doesn't, I don't see why glabel should continue to check it. Struct fs has a tonne of int32 fields, some of which are only used for information whose length is a couple of bits - if checking magic isn't enough (and it probably is), there are other fields that can be validated. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090421/e35512df/signature.pgp From avg at icyb.net.ua Tue Apr 21 16:45:09 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Tue Apr 21 16:45:17 2009 Subject: glabel for ufs: size check is overzealous? In-Reply-To: References: <49EDCA21.70908@icyb.net.ua> Message-ID: <49EDF80F.3070105@icyb.net.ua> on 21/04/2009 19:18 Ivan Voras said the following: > Andriy Gapon wrote: >> glabel insists that for UFS2 the following must hold true: >> pp->mediasize / fs->fs_fsize == fs->fs_size >> >> But in reality it doesn't have to be this way, there can be valid reasons to make >> filesystem smaller than available raw media size. >> >> I understand that this is a good sanity check, but maybe there are other ways to >> extra-check that we see a proper superblock, without imposing the limitation in >> question. > > Shouldn't fsck complain of this inconsistency? I don't see why it should and - no, it actually does not. fsck checks only filesystem's internal consistency, it doesn't check media size, etc. > If it doesn't and the [UF]FS code doesn't, I don't see why glabel should > continue to check it. Struct fs has a tonne of int32 fields, some of > which are only used for information whose length is a couple of bits - > if checking magic isn't enough (and it probably is), there are other > fields that can be validated. Maybe this is a check against disk space being re-used for some other fs and super-block staying sufficiently intact. But, OTOH, fs_fsize and fs_size could still match the raw media in this case too. If some extra sanity checks are needed in addition to magic then fs_bmask/fs_fmask/fs_bshift/fs_fshift and/or any other derived fields could be used. -- Andriy Gapon From avg at freebsd.org Tue Apr 21 16:51:41 2009 From: avg at freebsd.org (Andriy Gapon) Date: Tue Apr 21 16:51:47 2009 Subject: glabel for ufs: size check is overzealous? In-Reply-To: <49EDF80F.3070105@icyb.net.ua> References: <49EDCA21.70908@icyb.net.ua> <49EDF80F.3070105@icyb.net.ua> Message-ID: <49EDF995.2050508@freebsd.org> on 21/04/2009 19:45 Andriy Gapon said the following: > Maybe this is a check against disk space being re-used for some other fs and > super-block staying sufficiently intact. But, OTOH, fs_fsize and fs_size could > still match the raw media in this case too. > If some extra sanity checks are needed in addition to magic then > fs_bmask/fs_fmask/fs_bshift/fs_fshift and/or any other derived fields could be used. > BTW, right now I put this in my local tree: diff --git a/sys/geom/label/g_label_ufs.c b/sys/geom/label/g_label_ufs.c index 8510fc0..0cffb8d 100644 --- a/sys/geom/label/g_label_ufs.c +++ b/sys/geom/label/g_label_ufs.c @@ -83,10 +83,10 @@ g_label_ufs_taste_common(struct g_consumer *cp, char *label, size_t size, int wh continue; /* Check for magic and make sure things are the right size */ if (fs->fs_magic == FS_UFS1_MAGIC && fs->fs_fsize > 0 && - pp->mediasize / fs->fs_fsize == fs->fs_old_size) { + pp->mediasize / fs->fs_fsize >= fs->fs_old_size) { /* Valid UFS1. */ } else if (fs->fs_magic == FS_UFS2_MAGIC && fs->fs_fsize > 0 && - pp->mediasize / fs->fs_fsize == fs->fs_size) { + pp->mediasize / fs->fs_fsize >= fs->fs_size) { /* Valid UFS2. */ } else { g_free(fs); -- Andriy Gapon From ivoras at freebsd.org Tue Apr 21 18:43:30 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Apr 21 18:43:37 2009 Subject: glabel for ufs: size check is overzealous? In-Reply-To: <49EDF80F.3070105@icyb.net.ua> References: <49EDCA21.70908@icyb.net.ua> <49EDF80F.3070105@icyb.net.ua> Message-ID: Andriy Gapon wrote: > on 21/04/2009 19:18 Ivan Voras said the following: >> Andriy Gapon wrote: >>> glabel insists that for UFS2 the following must hold true: >>> pp->mediasize / fs->fs_fsize == fs->fs_size >>> >>> But in reality it doesn't have to be this way, there can be valid reasons to make >>> filesystem smaller than available raw media size. >>> >>> I understand that this is a good sanity check, but maybe there are other ways to >>> extra-check that we see a proper superblock, without imposing the limitation in >>> question. >> Shouldn't fsck complain of this inconsistency? > > I don't see why it should and - no, it actually does not. > fsck checks only filesystem's internal consistency, it doesn't check media size, etc. Well yes, if the number of blocks is really incorrect it should be visible from the arrangement of the metadata but still - that makes the field almost useless doesn't it? > pp->mediasize / fs->fs_fsize >= fs->fs_size) { Looks like it cannot harm anything. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 258 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090421/d9f321b4/signature.pgp From avg at icyb.net.ua Wed Apr 22 07:07:13 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Apr 22 07:07:24 2009 Subject: glabel for ufs: size check is overzealous? In-Reply-To: <49EDF995.2050508@freebsd.org> References: <49EDCA21.70908@icyb.net.ua> <49EDF80F.3070105@icyb.net.ua> <49EDF995.2050508@freebsd.org> Message-ID: <49EEC21C.7020106@icyb.net.ua> Thinking more about it - maybe that check is useful for finding out what geom provider a filesystem actually belongs too. But I am not sure. E.g. what should happen in the following case? I create partitions ad4s1a and ad4s2a. I create gmirror rootgm using these partitions. I create a filesystem on rootgm with label rootfs. Right now, with my local patch, during boot glabel seems to do "tasting" before gmirror is activated and so it thinks that rootfs is label of filesystem on ad4s1a. I think that this wouldn't have happened without my patch. But, OTOH, I think that this is not the problem of the patch, this is a problem of glabel starting before gmirror. But this is insolvable in principle - what of gmirror is started later manually. So after all the current code makes the most sense for most common usage pattern. And thus I shall shut up :-) -- Andriy Gapon From pjd at FreeBSD.org Wed Apr 22 07:59:52 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Wed Apr 22 08:00:15 2009 Subject: glabel for ufs: size check is overzealous? In-Reply-To: <49EDCA21.70908@icyb.net.ua> References: <49EDCA21.70908@icyb.net.ua> Message-ID: <20090422075957.GB1663@garage.freebsd.pl> On Tue, Apr 21, 2009 at 04:29:05PM +0300, Andriy Gapon wrote: > > glabel insists that for UFS2 the following must hold true: > pp->mediasize / fs->fs_fsize == fs->fs_size > > But in reality it doesn't have to be this way, there can be valid reasons to make > filesystem smaller than available raw media size. > > I understand that this is a good sanity check, but maybe there are other ways to > extra-check that we see a proper superblock, without imposing the limitation in > question. This check is there is case you have few GEOM providers that start at the same disk offset, but have different sizes. For example ad0s1, ad0s1a, mirror/foo, mirror/foo.journal all might start exactly at the same offset and glabel would have hard time to figure out on top of which to place glabel provider. Having file system smaller than provider size is perfectly valid, but this is about choosing lesser evil, that's all. It is just much more common to have file system using entire provider size. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090422/e17736b9/attachment.pgp From avg at icyb.net.ua Wed Apr 22 13:06:16 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Apr 22 13:06:23 2009 Subject: glabel for ufs: size check is overzealous? In-Reply-To: References: <49EDCA21.70908@icyb.net.ua> <49EDF80F.3070105@icyb.net.ua> Message-ID: <49EF1645.70704@icyb.net.ua> on 21/04/2009 21:43 Ivan Voras said the following: > Andriy Gapon wrote: >> I don't see why it should and - no, it actually does not. >> fsck checks only filesystem's internal consistency, it doesn't check media size, etc. > > Well yes, if the number of blocks is really incorrect it should be > visible from the arrangement of the metadata but still - that makes the > field almost useless doesn't it? How do you mean? The field tells the filesystem size, how it can be useless? -- Andriy Gapon From ivoras at freebsd.org Wed Apr 22 13:08:49 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Apr 22 13:08:56 2009 Subject: glabel for ufs: size check is overzealous? In-Reply-To: <49EF1645.70704@icyb.net.ua> References: <49EDCA21.70908@icyb.net.ua> <49EDF80F.3070105@icyb.net.ua> <49EF1645.70704@icyb.net.ua> Message-ID: <9bbcef730904220608y73cbf2d2s6921b05c1978a121@mail.gmail.com> 2009/4/22 Andriy Gapon : > on 21/04/2009 21:43 Ivan Voras said the following: >> Andriy Gapon wrote: >>> I don't see why it should and - no, it actually does not. >>> fsck checks only filesystem's internal consistency, it doesn't check media size, etc. >> >> Well yes, if the number of blocks is really incorrect it should be >> visible from the arrangement of the metadata but still - that makes the >> field almost useless doesn't it? > > How do you mean? > The field tells the filesystem size, how it can be useless? If nothing checks it and everything works, I'd say it's usefulness is a bit limited... From avg at icyb.net.ua Wed Apr 22 13:11:06 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Apr 22 13:11:17 2009 Subject: glabel for ufs: size check is overzealous? In-Reply-To: <9bbcef730904220608y73cbf2d2s6921b05c1978a121@mail.gmail.com> References: <49EDCA21.70908@icyb.net.ua> <49EDF80F.3070105@icyb.net.ua> <49EF1645.70704@icyb.net.ua> <9bbcef730904220608y73cbf2d2s6921b05c1978a121@mail.gmail.com> Message-ID: <49EF1766.7030401@icyb.net.ua> on 22/04/2009 16:08 Ivan Voras said the following: > 2009/4/22 Andriy Gapon : >> on 21/04/2009 21:43 Ivan Voras said the following: >>> Andriy Gapon wrote: >>>> I don't see why it should and - no, it actually does not. >>>> fsck checks only filesystem's internal consistency, it doesn't check media size, etc. >>> Well yes, if the number of blocks is really incorrect it should be >>> visible from the arrangement of the metadata but still - that makes the >>> field almost useless doesn't it? >> How do you mean? >> The field tells the filesystem size, how it can be useless? > > If nothing checks it and everything works, I'd say it's usefulness is > a bit limited... ufs driver doesn't check it, the driver *uses* it, so... :-) -- Andriy Gapon From ivoras at freebsd.org Wed Apr 22 13:12:40 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Wed Apr 22 13:12:46 2009 Subject: glabel for ufs: size check is overzealous? In-Reply-To: <49EF1766.7030401@icyb.net.ua> References: <49EDCA21.70908@icyb.net.ua> <49EDF80F.3070105@icyb.net.ua> <49EF1645.70704@icyb.net.ua> <9bbcef730904220608y73cbf2d2s6921b05c1978a121@mail.gmail.com> <49EF1766.7030401@icyb.net.ua> Message-ID: <9bbcef730904220612s3ff4308fpc1d18e216a5c7773@mail.gmail.com> 2009/4/22 Andriy Gapon : > on 22/04/2009 16:08 Ivan Voras said the following: >> 2009/4/22 Andriy Gapon : >>> on 21/04/2009 21:43 Ivan Voras said the following: >>>> Andriy Gapon wrote: >>>>> I don't see why it should and - no, it actually does not. >>>>> fsck checks only filesystem's internal consistency, it doesn't check media size, etc. >>>> Well yes, if the number of blocks is really incorrect it should be >>>> visible from the arrangement of the metadata but still - that makes the >>>> field almost useless doesn't it? >>> How do you mean? >>> The field tells the filesystem size, how it can be useless? >> >> If nothing checks it and everything works, I'd say it's usefulness is >> a bit limited... > > ufs driver doesn't check it, the driver *uses* it, so... :-) But as you said, fsck will not fix an invalid value? From avg at icyb.net.ua Wed Apr 22 13:36:36 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Apr 22 13:36:47 2009 Subject: glabel for ufs: size check is overzealous? In-Reply-To: <9bbcef730904220612s3ff4308fpc1d18e216a5c7773@mail.gmail.com> References: <49EDCA21.70908@icyb.net.ua> <49EDF80F.3070105@icyb.net.ua> <49EF1645.70704@icyb.net.ua> <9bbcef730904220608y73cbf2d2s6921b05c1978a121@mail.gmail.com> <49EF1766.7030401@icyb.net.ua> <9bbcef730904220612s3ff4308fpc1d18e216a5c7773@mail.gmail.com> Message-ID: <49EF1D5F.7050907@icyb.net.ua> on 22/04/2009 16:12 Ivan Voras said the following: > 2009/4/22 Andriy Gapon : >> on 22/04/2009 16:08 Ivan Voras said the following: >>> 2009/4/22 Andriy Gapon : >>>> on 21/04/2009 21:43 Ivan Voras said the following: >>>>> Andriy Gapon wrote: >>>>>> I don't see why it should and - no, it actually does not. >>>>>> fsck checks only filesystem's internal consistency, it doesn't check media size, etc. >>>>> Well yes, if the number of blocks is really incorrect it should be >>>>> visible from the arrangement of the metadata but still - that makes the >>>>> field almost useless doesn't it? >>>> How do you mean? >>>> The field tells the filesystem size, how it can be useless? >>> If nothing checks it and everything works, I'd say it's usefulness is >>> a bit limited... >> ufs driver doesn't check it, the driver *uses* it, so... :-) > > But as you said, fsck will not fix an invalid value? It won't, because it can not know the correct value and it is probably not able to safely derive it from anything. Filesystem size is supposed to always stay immutable (modulo growfs), so if this type of corruption happens to superblock, then one has quite a big problem and possibly some fun time with disk editor. -- Andriy Gapon From gavin at FreeBSD.org Thu Apr 23 09:02:52 2009 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Thu Apr 23 09:03:04 2009 Subject: kern/133931: [geli] [request] intentionally wrong password to destroy data Message-ID: <200904230902.n3N92pSc031359@freefall.freebsd.org> Old Synopsis: GELI intentionally wrong password to destroy data New Synopsis: [geli] [request] intentionally wrong password to destroy data Responsible-Changed-From-To: freebsd-bugs->freebsd-geom Responsible-Changed-By: gavin Responsible-Changed-When: Thu Apr 23 09:02:12 UTC 2009 Responsible-Changed-Why: Feature request. Over to maintainer(s) http://www.freebsd.org/cgi/query-pr.cgi?pr=133931 From ivoras at freebsd.org Thu Apr 23 11:52:26 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Apr 23 11:52:32 2009 Subject: geom_label verbosity patch Message-ID: Hi, I want to ask for a community review of these patches: http://people.freebsd.org/~ivoras/diffs/geom_label_errlevel.txt http://people.freebsd.org/~ivoras/diffs/glabel.8_errlevel.txt The intent is to make glabel less chatty on detection of new providers, etc. Since most of these messages were displayed as "priority 0", I needed to renumber priorities to make them go away at the default level (level 0). The DEBUG levels are changed in this way: - 0 becomes "silent" - no messages at this level - the default level - 1 contains previous messages at level 0 - 10 contains most of previous messages at level 1 - 20 contains messages of previous level 2 and of level 1 that are the result of tasting / validating / checksumming instead of specifically glabel operations The jump to decadic numbers is for future compatibility, in case more verbosity levels need to be introduced just like now, to avoid code churn. This should go in very fast if it's going to get into 7.2 (OTOH, it's fairly low priority). The patches were ready some time ago but there were some blocking delays. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090423/f4f4061b/signature.pgp From pjd at FreeBSD.org Thu Apr 23 12:00:29 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Thu Apr 23 12:00:35 2009 Subject: geom_label verbosity patch In-Reply-To: References: Message-ID: <20090423120035.GA1798@mail.wheel.pl> On Thu, Apr 23, 2009 at 01:52:01PM +0200, Ivan Voras wrote: > Hi, > > I want to ask for a community review of these patches: > > http://people.freebsd.org/~ivoras/diffs/geom_label_errlevel.txt > http://people.freebsd.org/~ivoras/diffs/glabel.8_errlevel.txt > > The intent is to make glabel less chatty on detection of new providers, > etc. [...] This is on purpose, so don't change that. One can always set it to -1. Instead, we should implement possibility to turn on/off selected labels. For example things like ufsid should be turned off by default. This way we not only make it less chatty again, but also not to pollute /dev/. -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! From ivoras at freebsd.org Thu Apr 23 12:15:23 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Apr 23 12:15:28 2009 Subject: geom_label verbosity patch In-Reply-To: <20090423120035.GA1798@mail.wheel.pl> References: <20090423120035.GA1798@mail.wheel.pl> Message-ID: Pawel Jakub Dawidek wrote: > On Thu, Apr 23, 2009 at 01:52:01PM +0200, Ivan Voras wrote: >> Hi, >> >> I want to ask for a community review of these patches: >> >> http://people.freebsd.org/~ivoras/diffs/geom_label_errlevel.txt >> http://people.freebsd.org/~ivoras/diffs/glabel.8_errlevel.txt >> >> The intent is to make glabel less chatty on detection of new providers, >> etc. [...] > > This is on purpose, so don't change that. One can always set it to -1. Possible, but it would make it unique among other GEOM classes. > Instead, we should implement possibility to turn on/off selected labels. > For example things like ufsid should be turned off by default. Anyone else agrees with this? > This way we not only make it less chatty again, but also not to pollute > /dev/. One way to lessen it is to stop creating individual directories for each label class, as discussed before. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090423/71658a45/signature.pgp From pjd at FreeBSD.org Thu Apr 23 12:35:05 2009 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Thu Apr 23 12:35:11 2009 Subject: geom_label verbosity patch In-Reply-To: References: <20090423120035.GA1798@mail.wheel.pl> Message-ID: <20090423123511.GB1798@mail.wheel.pl> On Thu, Apr 23, 2009 at 02:15:14PM +0200, Ivan Voras wrote: > Pawel Jakub Dawidek wrote: > > On Thu, Apr 23, 2009 at 01:52:01PM +0200, Ivan Voras wrote: > >> Hi, > >> > >> I want to ask for a community review of these patches: > >> > >> http://people.freebsd.org/~ivoras/diffs/geom_label_errlevel.txt > >> http://people.freebsd.org/~ivoras/diffs/glabel.8_errlevel.txt > >> > >> The intent is to make glabel less chatty on detection of new providers, > >> etc. [...] > > > > This is on purpose, so don't change that. One can always set it to -1. > > Possible, but it would make it unique among other GEOM classes. Almost every GEOM class informs about creating providers, so what you suggest is inconsistent. > > Instead, we should implement possibility to turn on/off selected labels. > > For example things like ufsid should be turned off by default. > > Anyone else agrees with this? > > > This way we not only make it less chatty again, but also not to pollute > > /dev/. > > One way to lessen it is to stop creating individual directories for each > label class, as discussed before. How is it going to reduce number of providers in /dev/? -- Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! From ivoras at freebsd.org Thu Apr 23 12:52:58 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Apr 23 12:53:04 2009 Subject: geom_label verbosity patch In-Reply-To: <20090423123511.GB1798@mail.wheel.pl> References: <20090423120035.GA1798@mail.wheel.pl> <20090423123511.GB1798@mail.wheel.pl> Message-ID: Pawel Jakub Dawidek wrote: > On Thu, Apr 23, 2009 at 02:15:14PM +0200, Ivan Voras wrote: >> Pawel Jakub Dawidek wrote: >>> On Thu, Apr 23, 2009 at 01:52:01PM +0200, Ivan Voras wrote: >>>> Hi, >>>> >>>> I want to ask for a community review of these patches: >>>> >>>> http://people.freebsd.org/~ivoras/diffs/geom_label_errlevel.txt >>>> http://people.freebsd.org/~ivoras/diffs/glabel.8_errlevel.txt >>>> >>>> The intent is to make glabel less chatty on detection of new providers, >>>> etc. [...] >>> This is on purpose, so don't change that. One can always set it to -1. >> Possible, but it would make it unique among other GEOM classes. > > Almost every GEOM class informs about creating providers, so what you > suggest is inconsistent. I think you feel more strongly about the topic than it warrants it - "almost every" is not "every" and glabel is technically a slicer just like gpart - you wouldn't like gpart to announce as it creates da0s1a, da0s1b, da0s1c, etc.? Besides, the trend is toward reducing the amount of generic (redundant, repeatable) information on boot. :) What could be possibly more useful is to create a framework that would output only "diff" messages - i.e. that shows that I had da0s1a or ufs/mylabel when I booted last time, and I suddenly lost it now. But this is non-trivial for many reasons, including how and where to store the information and what to do with hot-plug devices. Maybe devd could take care of all these announcements? >>> This way we not only make it less chatty again, but also not to pollute >>> /dev/. >> One way to lessen it is to stop creating individual directories for each >> label class, as discussed before. > > How is it going to reduce number of providers in /dev/? I was thinking about the "ls /dev" case. What other thing would be a concern in the number of entries in what's essentially a very light weight memory file system whose content are nodes of several bytes in size (less than 100 bytes if I count them correctly, +vnodes, labels, book-keeping)? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090423/d12839b9/signature.pgp From erleya at gmail.com Fri Apr 24 21:23:53 2009 From: erleya at gmail.com (Alexei Troussov) Date: Fri Apr 24 21:23:59 2009 Subject: gjournal+gstripe+gmirror question Message-ID: Hello All, I decided to build multi-terabyte data storage (file server) using 4 x 1Tb disks. No special raid controller is used, FreeBSD 7.1 is running on another disk, so the disk array is going to be used for file storage only. So, I tried several combinations of gmirror/gstripe and put gjournal on it: 1) two mirrors and stripe on them 2) two stripes and mirror on them Both configurations gave excellent I/O speed (around 100Mb/sec), and I chose the first one as it needs less time to resync disks when one of the mirrors fails. To make picture more complete, I didn't try graid3 because it seems to load CPU more than configs above, which is not good for my barebone :) Now when my top-level gstripe gets "gjournal"-ed, I see relatively poor write speed around 20-30 Mb/sec. As far as I understand from man gjournal and some posts here, performance usually drops about 40-50%, but what I have is much worse... Are there a better way to configure/tune the whole thing? Thanks in advance! PS Here is my current playground config: -------- > gmirror list Geom name: gm0 State: COMPLETE Components: 1 Balance: round-robin Slice: 4096 Flags: NONE GenID: 0 SyncID: 1 ID: 2111539126 Providers: 1. Name: mirror/gm0 Mediasize: 1000204885504 (932G) Sectorsize: 512 Mode: r1w1e2 Consumers: 1. Name: ad10 Mediasize: 1000204886016 (932G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 0 SyncID: 1 ID: 3300348150 2. Name: ad12 Mediasize: 1000204886016 (932G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 0 SyncID: 1 ID: 4291633068 Geom name: gm1 State: COMPLETE Components: 2 Balance: round-robin Slice: 4096 Flags: NONE GenID: 0 SyncID: 1 ID: 835525163 Providers: 1. Name: mirror/gm1 Mediasize: 1000204885504 (932G) Sectorsize: 512 Mode: r1w1e2 Consumers: 1. Name: ad11 Mediasize: 1000204886016 (932G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 0 SyncID: 1 ID: 1770536936 2. Name: ad13 Mediasize: 1000204886016 (932G) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 0 SyncID: 1 ID: 922042393 > gstripe list Geom name: gs0 State: UP Status: Total=2, Online=2 Type: AUTOMATIC Stripesize: 131072 ID: 1106325435 Providers: 1. Name: stripe/gs0 Mediasize: 2000409591808 (1.8T) Sectorsize: 512 Mode: r1w1e1 Consumers: 1. Name: mirror/gm0 Mediasize: 1000204885504 (932G) Sectorsize: 512 Mode: r1w1e2 Number: 0 2. Name: mirror/gm1 Mediasize: 1000204885504 (932G) Sectorsize: 512 Mode: r1w1e2 Number: 1 -------- Have a nice day, Alex From ryan at rbftpnetworks.com Fri Apr 24 22:02:03 2009 From: ryan at rbftpnetworks.com (ryan@rbftpnetworks.com) Date: Fri Apr 24 22:02:09 2009 Subject: Gaming news link Message-ID: Dear Sir / Madam, We are interested in posting our gaming news and information site on your links section. Our site is GamerBeef.com and can be found at http://www.gamerbeef.com Our site includes daily updated gaming news from all genres and consoles, with focus on PC gaming. We also have a new discussion forum, cheats and screenshots section. We would of course offer a link back to your site in return. Let me know your thoughts. Best Regards, Ryan -- Ryan Barclay Managing Director RBFTP Networks Limited. DDI: +44 (0)870 490 1870 WWW: http://www.rbftpnetworks.com RBFTP Networks Limited Registered in England No 05718807 Registered Office: 68 Aldersbrook Road, London, E12 5DL. From bugmaster at FreeBSD.org Mon Apr 27 11:06:55 2009 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Apr 27 11:08:03 2009 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200904271106.n3RB6suZ002288@freefall.freebsd.org> Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/133931 geom [geli] [request] intentionally wrong password to destr o kern/133604 geom [gvinum] [panic] writing to gjournal on a gvinum volum o bin/132845 geom [geom] [patch] ggated(8) does not close files opened a o kern/132273 geom glabel(8): [patch] failing on journaled partition o kern/132242 geom [gmirror] gmirror.ko fails to fully initialize o kern/131353 geom [geom] gjournal(8) kernel lock o kern/131037 geom [geli] Unable to create disklabel on .eli-Device o kern/130528 geom gjournal fsck during boot o kern/129674 geom [geom] gjournal root did not mount on boot o kern/129645 geom gjournal(8): GEOM_JOURNAL causes system to fail to boo o kern/129245 geom [geom] gcache is more suitable for suffix based provid o bin/128398 geom [patch] glabel(8): teach geom_label to recognise gpt l f kern/128276 geom [gmirror] machine lock up when gmirror module is used o kern/126902 geom [geom] geom_label: kernel panic during install boot o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s o kern/124294 geom [geom] gmirror(8) have inappropriate logic when workin o kern/124130 geom [gmirror] [usb] gmirror fails to start usb devices tha o kern/123962 geom [panic] [gjournal] gjournal (455Gb data, 8Gb journal), o kern/123630 geom [patch] [gmirror] gmirror doesnt allow the original dr o kern/123122 geom [geom] GEOM / gjournal kernel lock f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/122067 geom [geom] [panic] Geom crashed during boot o kern/121559 geom [patch] [geom] geom label class allows to create inacc o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/120231 geom [geom] GEOM_CONCAT error adding second drive o kern/120044 geom [msdosfs] [geom] incorrect MSDOSFS label fries adminis o kern/120021 geom [geom] [panic] net-p2p/qbittorrent crashes system when o kern/119743 geom [geom] geom label for cds is keeped after dismount and o kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113419 geom [geom] geom fox multipathing not failing back p bin/110705 geom gmirror(8) control utility does not exit with correct o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o bin/90093 geom fdisk(8) incapable of altering in-core geometry a kern/89660 geom [vinum] [patch] [panic] due to g_malloc returning null o kern/89546 geom [geom] GEOM error s kern/89102 geom [geom] [panic] panic when forced unmount FS from unplu o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo o kern/84556 geom [geom] [panic] GBDE-encrypted swap causes panic at shu o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o bin/78131 geom gbde(8) "destroy" not working. s kern/73177 geom kldload geom_* causes panic due to memory exhaustion 50 problems total. From avg at icyb.net.ua Mon Apr 27 16:33:18 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Mon Apr 27 16:33:27 2009 Subject: fsck, glabel and sudden paralellism Message-ID: <49F5DE4B.2070702@icyb.net.ua> So I recently switched one system to have only (g)labels instead of "raw" device names in fstab and noticed that now initial (preen) fsck is performed in parallel on couple of filesystems where before it used to be sequential. Here is a lengthy quote from fsck(8): > In preen mode, after pass 1 completes, all remaining file systems are > checked, in pass number order running one process per disk drive in par- > allel for each pass number in increasing order. > > In other words: In preen mode all pass 1 partitions are checked sequen- > tially. Next all pass 2 partitions are checked in parallel, one process > per disk drive. Next all pass 3 partitions are checked in parallel, one > process per disk drive. etc. > > The disk drive containing each file system is inferred from the shortest > prefix of the device name that ends in a digit; the remaining characters > are assumed to be the partition and slice designators. I think it is highly desirable that fsck knows which filesystems reside on the same disk regardless of how they are referred to. I think that the simple string matching described above is not sufficient these days. Is there an easy geom way to query this info? -- Andriy Gapon From ivoras at freebsd.org Tue Apr 28 11:35:05 2009 From: ivoras at freebsd.org (Ivan Voras) Date: Tue Apr 28 11:35:11 2009 Subject: fsck, glabel and sudden paralellism In-Reply-To: <49F5DE4B.2070702@icyb.net.ua> References: <49F5DE4B.2070702@icyb.net.ua> Message-ID: Andriy Gapon wrote: > So I recently switched one system to have only (g)labels instead of "raw" device > names in fstab and noticed that now initial (preen) fsck is performed in parallel > on couple of filesystems where before it used to be sequential. > > Here is a lengthy quote from fsck(8): >> In preen mode, after pass 1 completes, all remaining file systems are >> checked, in pass number order running one process per disk drive in par- >> allel for each pass number in increasing order. >> >> In other words: In preen mode all pass 1 partitions are checked sequen- >> tially. Next all pass 2 partitions are checked in parallel, one process >> per disk drive. Next all pass 3 partitions are checked in parallel, one >> process per disk drive. etc. >> >> The disk drive containing each file system is inferred from the shortest >> prefix of the device name that ends in a digit; the remaining characters >> are assumed to be the partition and slice designators. > > I think it is highly desirable that fsck knows which filesystems reside on the > same disk regardless of how they are referred to. > I think that the simple string matching described above is not sufficient these days. > Is there an easy geom way to query this info? Yes, contents of kern.geom.confxml could be used to walk the tree of GEOM devices and find what drive they are physically on. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 260 bytes Desc: OpenPGP digital signature Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20090428/08ad45b4/signature.pgp From avg at icyb.net.ua Wed Apr 29 07:35:03 2009 From: avg at icyb.net.ua (Andriy Gapon) Date: Wed Apr 29 07:35:25 2009 Subject: fsck, glabel and sudden parallelism In-Reply-To: References: <49F5DE4B.2070702@icyb.net.ua> Message-ID: <49F80321.6030305@icyb.net.ua> on 28/04/2009 14:34 Ivan Voras said the following: > Andriy Gapon wrote: >> So I recently switched one system to have only (g)labels instead of "raw" device >> names in fstab and noticed that now initial (preen) fsck is performed in parallel >> on couple of filesystems where before it used to be sequential. >> >> Here is a lengthy quote from fsck(8): [snip] >>> The disk drive containing each file system is inferred from the shortest >>> prefix of the device name that ends in a digit; the remaining characters >>> are assumed to be the partition and slice designators. >> I think it is highly desirable that fsck knows which filesystems reside on the >> same disk regardless of how they are referred to. >> I think that the simple string matching described above is not sufficient these days. >> Is there an easy geom way to query this info? > > Yes, contents of kern.geom.confxml could be used to walk the tree of > GEOM devices and find what drive they are physically on. It seems that the less interesting part is already done - geom_gettree() from libgeom, the more interesting part is some logic for directed graph (geom "mesh") navigation. Marcel, I seem to recall that there was a conversation about making fsck more geom aware (it was in context of inferring fs type from disklabel). Do you have any work in progress in this area? -- Andriy Gapon From terje at elde.net Thu Apr 30 11:26:23 2009 From: terje at elde.net (Terje Elde) Date: Thu Apr 30 11:26:30 2009 Subject: gmirror, geli and gjournal Message-ID: <49F98768.8000907@elde.net> Hi, I'm curious about GEOM combining gmirror geli and gjournal. I'm setting up a rather slow machine (PentiumIII 450Mhz) and didn't want to encrypt once pr. drive, so I configured geli on top of gmirror so I encrypt once for the mirror, rather than once for each disk. Seemed to make sense. I now want to place UFS2 filesystems with journaling (using gmirror offcourse) on top of the encrypted mirror. In the gjournal man page, I was pleased to read: When gjournal is configured on top of gmirror(8) or graid3(8) providers, it also keeps them in a consistent state, thus automatic synchronization on power failure or system crash may be disabled on those providers. But what happens if I have geli sitting between gjournal and gmirror? Will gjournal still take responsibility for keeping the mirror in sync? Or would I have to have geli and gmirror trade place, so gjournal sits directly on top of gmirror, and I encrypt once pr. disk? Also, the way I set things up, I used gmirror and geli on the whole drives, used BSD disklabels for partitioning the encrypted device, and understand I'd use gjournal for each partition. Will things work as desired even though gmirror is for the whole disk, and gjournal with UFS2 is pr. partition? Tried to RTFM, interrogate google, but came up a bit short on these questions, and since it's about data-integrity, I'd rather ask now, than cry later. Hope someone can enlighten me a bit. Terje From cyberleo at cyberleo.net Thu Apr 30 19:38:21 2009 From: cyberleo at cyberleo.net (CyberLeo Kitsana) Date: Thu Apr 30 19:38:27 2009 Subject: gmirror, geli and gjournal In-Reply-To: <49F98768.8000907@elde.net> References: <49F98768.8000907@elde.net> Message-ID: <49F9FA04.3040306@cyberleo.net> Terje Elde wrote: > Hi, > > I'm curious about GEOM combining gmirror geli and gjournal. > > I'm setting up a rather slow machine (PentiumIII 450Mhz) and didn't want > to encrypt once pr. drive, so I configured geli on top of gmirror so I > encrypt once for the mirror, rather than once for each disk. Seemed to > make sense. > > I now want to place UFS2 filesystems with journaling (using gmirror > offcourse) on top of the encrypted mirror. In the gjournal man page, I > was pleased to read: > > When gjournal is configured on top of gmirror(8) or graid3(8) > providers, > it also keeps them in a consistent state, thus automatic > synchronization > on power failure or system crash may be disabled on those providers. > > But what happens if I have geli sitting between gjournal and gmirror? > > Will gjournal still take responsibility for keeping the mirror in sync? This claim has to do with how gjournal does its work. Keeping the mirror in sync is a side effect of the transactive nature of the journal. I.e. an entry in the journal is considered either fully completed or not completed at all. If the system stops running while it's writing to disk, gjournal has a log (the journal) of what it's already done and what it needs to do, and finishes the job when it comes back. Thus, if one half of the mirror has data written and the other does not (a common reason for resyncing mirrors), the fact that gjournal will redo all the things it suspects never finished will make the mirror's members identical once again. The presence of geli would not alter this assumption. Unless it caches information and ignores flush commands, that is. If you have partitions on the mirror which are not journaled whose contents you care about, it's still a good idea to sync those after a crash, though. -- Fuzzy love, -CyberLeo Technical Administrator CyberLeo.Net Webhosting http://www.CyberLeo.Net Furry Peace! - http://wwww.fur.com/peace/