From bugmaster at FreeBSD.org Mon Aug 4 11:06:55 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 4 11:07:42 2008 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200808041106.m74B6sql082060@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/73177 geom kldload geom_* causes panic due to memory exhaustion o kern/84556 geom [geom] GBDE-encrypted swap causes panic at shutdown o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo s kern/89102 geom [geom] [panic] panic when forced unmount FS from unplu o kern/89546 geom [geom] GEOM error a kern/89660 geom [vinum] [patch] [panic] due to g_malloc returning null o bin/90093 geom fdisk(8) incapable of altering in-core geometry o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/113419 geom [geom] geom fox multipathing not failing back o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/120021 geom net-p2p/qbittorrent crashes system when it works thoug o kern/120231 geom [geom] GEOM_CONCAT error adding second drive o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/122067 geom [panic]: Geom crashed during boot f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/123122 geom [geom] GEOM / gjournal kernel lock o kern/123962 geom [panic] gjournal(8): gjournal (455Gb data, 8Gb journal o kern/124130 geom [gmirror][usb] gmirror fails to start usb devices that o kern/124294 geom [geom] gmirror(8) have inappropriate logic when workin o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s 22 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/78131 geom gbde(8) "destroy" not working. o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to p bin/110705 geom gmirror(8) control utility does not exit with correct o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113885 geom [gmirror] [patch] improved gmirror balance algorithm o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile f kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/119743 geom [geom] geom label for cds is keeped after dismount and o kern/120044 geom [msdosfs] [geom] incorrect MSDOSFS label fries adminis o kern/121559 geom [patch] [geom] geom label class allows to create inacc o kern/123630 geom [patch] [gmirror] gmirror doesnt allow the original dr o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con 15 problems total. From bugmaster at FreeBSD.org Mon Aug 11 11:06:57 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 11 11:07:41 2008 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200808111106.m7BB6vGo047187@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/73177 geom kldload geom_* causes panic due to memory exhaustion o kern/84556 geom [geom] GBDE-encrypted swap causes panic at shutdown o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo s kern/89102 geom [geom] [panic] panic when forced unmount FS from unplu o kern/89546 geom [geom] GEOM error a kern/89660 geom [vinum] [patch] [panic] due to g_malloc returning null o bin/90093 geom fdisk(8) incapable of altering in-core geometry o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/113419 geom [geom] geom fox multipathing not failing back o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/120021 geom net-p2p/qbittorrent crashes system when it works thoug o kern/120231 geom [geom] GEOM_CONCAT error adding second drive o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/122067 geom [panic]: Geom crashed during boot f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/123122 geom [geom] GEOM / gjournal kernel lock o kern/123962 geom [panic] gjournal(8): gjournal (455Gb data, 8Gb journal o kern/124130 geom [gmirror][usb] gmirror fails to start usb devices that o kern/124294 geom [geom] gmirror(8) have inappropriate logic when workin o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s 22 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/78131 geom gbde(8) "destroy" not working. o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to p bin/110705 geom gmirror(8) control utility does not exit with correct o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113885 geom [gmirror] [patch] improved gmirror balance algorithm o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile f kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/119743 geom [geom] geom label for cds is keeped after dismount and o kern/120044 geom [msdosfs] [geom] incorrect MSDOSFS label fries adminis o kern/121559 geom [patch] [geom] geom label class allows to create inacc o kern/123630 geom [patch] [gmirror] gmirror doesnt allow the original dr o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con 15 problems total. From misterniceguy0 at gmail.com Wed Aug 13 10:43:53 2008 From: misterniceguy0 at gmail.com (Mister Nice Guy) Date: Wed Aug 13 10:43:59 2008 Subject: Storesonline, Drawing Customers With An Enticing Ecommerce Storefront Message-ID: <3b9f447d0808130329x23984a59vc0d665deb36c9074@mail.gmail.com> *Storesonline, **Drawing Customers With An Enticing Ecommerce Storefront* Take a quick walk down the corridor of your closest mall and you will find out that the appearance of a storefront is a very important aspect of their business. Most stores use mannequins and highlight their latest outfits in the store window. The idea of highlighting what the store offers in the window fronts is to draw people into the store. If a potential customer walks through the mall and sees an outfit or a new gadget they may want to purchase, it increases the likelihood that that individual will wander into the store to shop around. The same can be said for online stores offered by *Storesonline.* The appearance of an ecommerce storefront can mean the difference between having customers and not having customers enter, shop and purchase products from your site. Whether a business owner is just starting out or looking to revamp their online store, a store?s appearance can make a big difference and *Storesonline *has the answer. The first step in building a business is to make sure that the online store appearance fits with what is being sold at the store. You do not want to mislead customers on your site by having an ecommerce storefront that does not match with what is offered at your particular store. *Storesonline* has the experience to help you make that decision.It is important to showcase items that you have and that are in high demand by customers. If you sell something that is unique and it is your specialty, then by all means put that on the front page of your website somewhere to show case it. It will draw people to your site and entice them to continue to shop throughout the store. From valerio.daelli at gmail.com Wed Aug 13 14:17:08 2008 From: valerio.daelli at gmail.com (Valerio Daelli) Date: Wed Aug 13 14:17:15 2008 Subject: Status of gjournal Message-ID: <27dbfc8c0808130652y3349df80v9c2f96efbb6d6147@mail.gmail.com> Hi we would like to use a gjournaled filesystem on FreeBSD 7.0. We plan to use a ciss or mpt controller. Is there any plan to implement the BIO_FLUSH request in these drivers? Is it safe to create a gjournal on those controllers as is? Thanks Valerio Daelli From bugmaster at FreeBSD.org Mon Aug 18 11:06:50 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 18 11:07:40 2008 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200808181106.m7IB6nmi079801@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/73177 geom kldload geom_* causes panic due to memory exhaustion o kern/84556 geom [geom] GBDE-encrypted swap causes panic at shutdown o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo s kern/89102 geom [geom] [panic] panic when forced unmount FS from unplu o kern/89546 geom [geom] GEOM error a kern/89660 geom [vinum] [patch] [panic] due to g_malloc returning null o bin/90093 geom fdisk(8) incapable of altering in-core geometry o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/113419 geom [geom] geom fox multipathing not failing back o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/120021 geom net-p2p/qbittorrent crashes system when it works thoug o kern/120231 geom [geom] GEOM_CONCAT error adding second drive o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/122067 geom [panic]: Geom crashed during boot f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/123122 geom [geom] GEOM / gjournal kernel lock o kern/123962 geom [panic] gjournal(8): gjournal (455Gb data, 8Gb journal o kern/124130 geom [gmirror][usb] gmirror fails to start usb devices that o kern/124294 geom [geom] gmirror(8) have inappropriate logic when workin o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s 22 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/78131 geom gbde(8) "destroy" not working. o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to p bin/110705 geom gmirror(8) control utility does not exit with correct o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113885 geom [gmirror] [patch] improved gmirror balance algorithm o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile f kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/119743 geom [geom] geom label for cds is keeped after dismount and o kern/120044 geom [msdosfs] [geom] incorrect MSDOSFS label fries adminis o kern/121559 geom [patch] [geom] geom label class allows to create inacc o kern/123630 geom [patch] [gmirror] gmirror doesnt allow the original dr o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con 15 problems total. From bugmaster at FreeBSD.org Mon Aug 25 11:06:50 2008 From: bugmaster at FreeBSD.org (FreeBSD bugmaster) Date: Mon Aug 25 11:07:47 2008 Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org Message-ID: <200808251106.m7PB6o8Y027751@freefall.freebsd.org> Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/73177 geom kldload geom_* causes panic due to memory exhaustion o kern/84556 geom [geom] GBDE-encrypted swap causes panic at shutdown o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo s kern/89102 geom [geom] [panic] panic when forced unmount FS from unplu o kern/89546 geom [geom] GEOM error a kern/89660 geom [vinum] [patch] [panic] due to g_malloc returning null o bin/90093 geom fdisk(8) incapable of altering in-core geometry o kern/90582 geom [geom] [panic] Restore cause panic string (ffs_blkfree o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/113419 geom [geom] geom fox multipathing not failing back o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/120021 geom net-p2p/qbittorrent crashes system when it works thoug o kern/120231 geom [geom] GEOM_CONCAT error adding second drive o kern/121364 geom [gmirror] Removing all providers create a "zombie" mir o kern/122067 geom [panic]: Geom crashed during boot f kern/122415 geom [geom] UFS labels are being constantly created and rem o kern/123122 geom [geom] GEOM / gjournal kernel lock o kern/123962 geom [panic] gjournal(8): gjournal (455Gb data, 8Gb journal o kern/124130 geom [gmirror][usb] gmirror fails to start usb devices that o kern/124294 geom [geom] gmirror(8) have inappropriate logic when workin o kern/124969 geom gvinum(8): gvinum raid5 plex does not detect missing s 22 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/78131 geom gbde(8) "destroy" not working. o kern/79035 geom [vinum] gvinum unable to create a striped set of mirro o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/94632 geom [geom] Kernel output resets input while GELI asks for o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to p bin/110705 geom gmirror(8) control utility does not exit with correct o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113885 geom [gmirror] [patch] improved gmirror balance algorithm o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile f kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/119743 geom [geom] geom label for cds is keeped after dismount and o kern/120044 geom [msdosfs] [geom] incorrect MSDOSFS label fries adminis o kern/121559 geom [patch] [geom] geom label class allows to create inacc o kern/123630 geom [patch] [gmirror] gmirror doesnt allow the original dr o kern/124973 geom [gjournal] [patch] boot order affects geom_journal con 15 problems total. From bjmccann at gmail.com Thu Aug 28 14:27:08 2008 From: bjmccann at gmail.com (Brian McCann) Date: Thu Aug 28 14:27:15 2008 Subject: gjournal & fsck Message-ID: <2b5f066d0808280705y3454c188v768efe46b388864b@mail.gmail.com> Hi all. I'm having some problems with several servers I've built recently (7.0-RELEASE) that are using gjournal. I had two reboot a few days ago (un-related to FreeBSD problems I think)...but when they came back up, the file systems wouldn't mount since they were not clean. Now, I understand that UFS knows nothing about the fact that it's journaled, and the journaling knows nothing about UFS...but it's my understanding that by using gjournal, you should really never need to fsck a file system. However, the only way to get them to mount is by doing the fsck. Is there something else I should be doing instead of fsck? And since I know it will probably come up, I built the file systems using the instructions and notes at http://www.freebsd.org/cgi/man.cgi?query=gjournal&apropos=0&sektion=0&manpath=FreeBSD+7.0-RELEASE&format=html. Any help would be greatly appreciated! Thanks! --Brian -- _-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_-=-_ Brian McCann "I don't have to take this abuse from you -- I've got hundreds of people waiting to abuse me." -- Bill Murray, "Ghostbusters" From bjmccann at gmail.com Thu Aug 28 14:43:59 2008 From: bjmccann at gmail.com (Brian McCann) Date: Thu Aug 28 14:44:22 2008 Subject: gjournal & fsck In-Reply-To: References: <2b5f066d0808280705y3454c188v768efe46b388864b@mail.gmail.com> Message-ID: <2b5f066d0808280743g69c32d1rd30aee0ca276125@mail.gmail.com> On Thu, Aug 28, 2008 at 10:34 AM, Ivan Voras wrote: > Brian McCann wrote: >> Hi all. I'm having some problems with several servers I've built >> recently (7.0-RELEASE) that are using gjournal. I had two reboot a >> few days ago (un-related to FreeBSD problems I think)...but when they >> came back up, the file systems wouldn't mount since they were not >> clean. Now, I understand that UFS knows nothing about the fact that >> it's journaled, and the journaling knows nothing about UFS...but it's > > Actually UFS needs to know about gjournal for just this purpose. There's > a special option to newfs that tells the file system to be aware of > gjournal and it should request fscks. > >> my understanding that by using gjournal, you should really never need >> to fsck a file system. However, the only way to get them to mount is >> by doing the fsck. Is there something else I should be doing instead >> of fsck? > > man 8 tunefs > Yes...I apologize...I did that when I built the file system with "newfs -J". Here's the tunefs -p output for one of the file systems: # tunefs -p /dev/da2.journal tunefs: ACLs: (-a) disabled tunefs: MAC multilabel: (-l) disabled tunefs: soft updates: (-n) disabled tunefs: gjournal: (-J) enabled tunefs: maximum blocks per file in a cylinder group: (-e) 2048 tunefs: average file size: (-f) 16384 tunefs: average number of files in a directory: (-s) 64 tunefs: minimum percentage of free space: (-m) 8% tunefs: optimization preference: (-o) time tunefs: volume label: (-L) I'm concerned about this because the ones I've had problems with recently are 1.1TB arrays...I've got 2 8.6TB arrays that are journaled as well...and if I ever have to fsck them...that could take 1/2 the day... Any other thoughts? Thanks for the help so far Ivan! --Brian From bjmccann at gmail.com Thu Aug 28 14:57:24 2008 From: bjmccann at gmail.com (Brian McCann) Date: Thu Aug 28 14:57:30 2008 Subject: gjournal & fsck In-Reply-To: <48B6B9D0.8060302@gmail.com> References: <2b5f066d0808280705y3454c188v768efe46b388864b@mail.gmail.com> <48B6B9D0.8060302@gmail.com> Message-ID: <2b5f066d0808280757h6caeffa8h13d45dd668434156@mail.gmail.com> > > You may wish to have a look at this article: > > http://www.freebsd.org/doc/en_US.ISO8859-1/articles/gjournal-desktop Great article...thanks. Bookmarked for future use too! > In particular, you should make sure you use tunefs to enable Journaling and > disable soft update on the journaled filesystems, i.e.: > > tunefs -J enable -n disable /dev/ad0s1f.journal I was mistaken...I did this when I made the file system...I just posted a message to the thread showing the output of tunefs -p, but soft-updates are off, and journaling does show as on. > > Mount them using the async option: > > /dev/ad0s1f.journal /usr ufs rw,async 2 2 Here's my fstab line: /dev/da1.journal /files6/array2 ufs rw,async,nosuid,noatime 2 2 > > Note that the pass # still indicates the filesystem should be checked. While > I was writing the article, I was trying several scenarios were I had the > pass # set to 0, thinking that a gjournaled filesystem would not need fsck > at all. I would then press the reset button. In most cases, the system would > refuse to mount them. However with the pass # set, the fsck would finish > almost immediately, since the actual consistency check takes place when the > gjournal module is loaded (you will get a "journal consistent" after a bad > reboot) and before fstab is even parsed. All fsck does in this case is > simply confirm to the system it is a clean volume. > > In short, leaving the pass # to something that would cause an fsck is the > safe way to go. The fsck will be almost instant anyway. > > The file system is about 1.1TB, and I've got 2 of them that are journaled on this particular server. One is currently empty, and fsck's in about 10-15 mins, while the other is 31% used, and takes about 45 mins. Thanks for your help thus far! --Brian From bjmccann at gmail.com Thu Aug 28 15:03:50 2008 From: bjmccann at gmail.com (Brian McCann) Date: Thu Aug 28 15:03:57 2008 Subject: gjournal & fsck In-Reply-To: References: <2b5f066d0808280705y3454c188v768efe46b388864b@mail.gmail.com> <2b5f066d0808280743g69c32d1rd30aee0ca276125@mail.gmail.com> Message-ID: <2b5f066d0808280803ibca3f61xbb167bce384f228@mail.gmail.com> On Thu, Aug 28, 2008 at 10:51 AM, Ivan Voras wrote: > > Does gjournal complain about your drive, for example that it doesn't > support BIOFLUSH? Actually yes...I meant to post them in my last message, but hit send too early...here's my output from boot (from dmesg.boot) GEOM_JOURNAL: Journal 478661671: da1 contains data. GEOM_JOURNAL: Journal 478661671: da1 contains journal. GEOM_JOURNAL: Journal da1 clean. (da1:mly0:4:1:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 (da1:mly0:4:1:0): CAM Status: SCSI Status Error (da1:mly0:4:1:0): SCSI Status: Check Condition (da1:mly0:4:1:0): ILLEGAL REQUEST asc:24,0 (da1:mly0:4:1:0): Invalid field in CDB (da1:mly0:4:1:0): Unretryable error GEOM_JOURNAL: BIO_FLUSH not supported by da1. GEOM_JOURNAL: Journal 3065355517: da2 contains data. GEOM_JOURNAL: Journal 3065355517: da2 contains journal. GEOM_JOURNAL: Journal da2 clean. (da2:mly1:4:0:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 (da2:mly1:4:0:0): CAM Status: SCSI Status Error (da2:mly1:4:0:0): SCSI Status: Check Condition (da2:mly1:4:0:0): ILLEGAL REQUEST asc:24,0 (da2:mly1:4:0:0): Invalid field in CDB (da2:mly1:4:0:0): Unretryable error GEOM_JOURNAL: BIO_FLUSH not supported by da2. > > Also, did fsck actually do something when it was started (did it find > anything corrupted)? > No...it didn't find anything wrong / anything to fix. (and one of the file systems was being written to at the time...so at least journaling appears to be working) Something else I noticed...Manolis' article says it should say "journal xxxx consistent"...whereas mine says "Journal xxxx clean". I don't know what the differences mean, or what the BIO_FLUSH means...but I'm hoping you can tell me. :) Thanks again! --Brian From bjmccann at gmail.com Thu Aug 28 15:06:00 2008 From: bjmccann at gmail.com (Brian McCann) Date: Thu Aug 28 15:06:11 2008 Subject: gjournal & fsck In-Reply-To: <2b5f066d0808280803ibca3f61xbb167bce384f228@mail.gmail.com> References: <2b5f066d0808280705y3454c188v768efe46b388864b@mail.gmail.com> <2b5f066d0808280743g69c32d1rd30aee0ca276125@mail.gmail.com> <2b5f066d0808280803ibca3f61xbb167bce384f228@mail.gmail.com> Message-ID: <2b5f066d0808280805t4c5f7051i60d02c7396c5f06d@mail.gmail.com> On Thu, Aug 28, 2008 at 11:03 AM, Brian McCann wrote: > On Thu, Aug 28, 2008 at 10:51 AM, Ivan Voras wrote: >> >> Does gjournal complain about your drive, for example that it doesn't >> support BIOFLUSH? > > Actually yes...I meant to post them in my last message, but hit send > too early...here's my output from boot (from dmesg.boot) > > GEOM_JOURNAL: Journal 478661671: da1 contains data. > GEOM_JOURNAL: Journal 478661671: da1 contains journal. > GEOM_JOURNAL: Journal da1 clean. > (da1:mly0:4:1:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 > (da1:mly0:4:1:0): CAM Status: SCSI Status Error > (da1:mly0:4:1:0): SCSI Status: Check Condition > (da1:mly0:4:1:0): ILLEGAL REQUEST asc:24,0 > (da1:mly0:4:1:0): Invalid field in CDB > (da1:mly0:4:1:0): Unretryable error > GEOM_JOURNAL: BIO_FLUSH not supported by da1. > GEOM_JOURNAL: Journal 3065355517: da2 contains data. > GEOM_JOURNAL: Journal 3065355517: da2 contains journal. > GEOM_JOURNAL: Journal da2 clean. > (da2:mly1:4:0:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 > (da2:mly1:4:0:0): CAM Status: SCSI Status Error > (da2:mly1:4:0:0): SCSI Status: Check Condition > (da2:mly1:4:0:0): ILLEGAL REQUEST asc:24,0 > (da2:mly1:4:0:0): Invalid field in CDB > (da2:mly1:4:0:0): Unretryable error > GEOM_JOURNAL: BIO_FLUSH not supported by da2. > >> >> Also, did fsck actually do something when it was started (did it find >> anything corrupted)? >> > No...it didn't find anything wrong / anything to fix. (and one of the > file systems was being written to at the time...so at least journaling > appears to be working) Something else I noticed...Manolis' article > says it should say "journal xxxx consistent"...whereas mine says > "Journal xxxx clean". I don't know what the differences mean, or what > the BIO_FLUSH means...but I'm hoping you can tell me. :) > > Thanks again! > --Brian > I should probably also mention that this is on a Mylex 2000 RAID controller...with a RAID-5 array and using write-caching. Thanks --Brian From sonic2000gr at gmail.com Thu Aug 28 15:17:03 2008 From: sonic2000gr at gmail.com (Manolis Kiagias) Date: Thu Aug 28 15:17:10 2008 Subject: gjournal & fsck In-Reply-To: <2b5f066d0808280705y3454c188v768efe46b388864b@mail.gmail.com> References: <2b5f066d0808280705y3454c188v768efe46b388864b@mail.gmail.com> Message-ID: <48B6B9D0.8060302@gmail.com> Brian McCann wrote: > Hi all. I'm having some problems with several servers I've built > recently (7.0-RELEASE) that are using gjournal. I had two reboot a > few days ago (un-related to FreeBSD problems I think)...but when they > came back up, the file systems wouldn't mount since they were not > clean. Now, I understand that UFS knows nothing about the fact that > it's journaled, and the journaling knows nothing about UFS...but it's > my understanding that by using gjournal, you should really never need > to fsck a file system. However, the only way to get them to mount is > by doing the fsck. Is there something else I should be doing instead > of fsck? > > And since I know it will probably come up, I built the file systems > using the instructions and notes at > http://www.freebsd.org/cgi/man.cgi?query=gjournal&apropos=0&sektion=0&manpath=FreeBSD+7.0-RELEASE&format=html. > > Any help would be greatly appreciated! > Thanks! > --Brian > > You may wish to have a look at this article: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/gjournal-desktop In particular, you should make sure you use tunefs to enable Journaling and disable soft update on the journaled filesystems, i.e.: tunefs -J enable -n disable /dev/ad0s1f.journal Mount them using the async option: /dev/ad0s1f.journal /usr ufs rw,async 2 2 Note that the pass # still indicates the filesystem should be checked. While I was writing the article, I was trying several scenarios were I had the pass # set to 0, thinking that a gjournaled filesystem would not need fsck at all. I would then press the reset button. In most cases, the system would refuse to mount them. However with the pass # set, the fsck would finish almost immediately, since the actual consistency check takes place when the gjournal module is loaded (you will get a "journal consistent" after a bad reboot) and before fstab is even parsed. All fsck does in this case is simply confirm to the system it is a clean volume. In short, leaving the pass # to something that would cause an fsck is the safe way to go. The fsck will be almost instant anyway. From sonic2000gr at gmail.com Thu Aug 28 15:25:40 2008 From: sonic2000gr at gmail.com (Manolis Kiagias) Date: Thu Aug 28 15:25:50 2008 Subject: gjournal & fsck In-Reply-To: <2b5f066d0808280805t4c5f7051i60d02c7396c5f06d@mail.gmail.com> References: <2b5f066d0808280705y3454c188v768efe46b388864b@mail.gmail.com> <2b5f066d0808280743g69c32d1rd30aee0ca276125@mail.gmail.com> <2b5f066d0808280803ibca3f61xbb167bce384f228@mail.gmail.com> <2b5f066d0808280805t4c5f7051i60d02c7396c5f06d@mail.gmail.com> Message-ID: <48B6C36E.4040502@gmail.com> Brian McCann wrote: > On Thu, Aug 28, 2008 at 11:03 AM, Brian McCann wrote: > >> On Thu, Aug 28, 2008 at 10:51 AM, Ivan Voras wrote: >> >>> Does gjournal complain about your drive, for example that it doesn't >>> support BIOFLUSH? >>> >> Actually yes...I meant to post them in my last message, but hit send >> too early...here's my output from boot (from dmesg.boot) >> >> GEOM_JOURNAL: Journal 478661671: da1 contains data. >> GEOM_JOURNAL: Journal 478661671: da1 contains journal. >> GEOM_JOURNAL: Journal da1 clean. >> (da1:mly0:4:1:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 >> (da1:mly0:4:1:0): CAM Status: SCSI Status Error >> (da1:mly0:4:1:0): SCSI Status: Check Condition >> (da1:mly0:4:1:0): ILLEGAL REQUEST asc:24,0 >> (da1:mly0:4:1:0): Invalid field in CDB >> (da1:mly0:4:1:0): Unretryable error >> GEOM_JOURNAL: BIO_FLUSH not supported by da1. >> GEOM_JOURNAL: Journal 3065355517: da2 contains data. >> GEOM_JOURNAL: Journal 3065355517: da2 contains journal. >> GEOM_JOURNAL: Journal da2 clean. >> (da2:mly1:4:0:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 >> (da2:mly1:4:0:0): CAM Status: SCSI Status Error >> (da2:mly1:4:0:0): SCSI Status: Check Condition >> (da2:mly1:4:0:0): ILLEGAL REQUEST asc:24,0 >> (da2:mly1:4:0:0): Invalid field in CDB >> (da2:mly1:4:0:0): Unretryable error >> GEOM_JOURNAL: BIO_FLUSH not supported by da2. >> >> >>> Also, did fsck actually do something when it was started (did it find >>> anything corrupted)? >>> >>> >> No...it didn't find anything wrong / anything to fix. (and one of the >> file systems was being written to at the time...so at least journaling >> appears to be working) Something else I noticed...Manolis' article >> says it should say "journal xxxx consistent"...whereas mine says >> "Journal xxxx clean". I don't know what the differences mean, or what >> the BIO_FLUSH means...but I'm hoping you can tell me. :) >> >> Thanks again! >> --Brian >> >> > > I should probably also mention that this is on a Mylex 2000 RAID > controller...with a RAID-5 array and using write-caching. > > Thanks > --Brian > I don't have any "exotic" hardware myself - the article was written with standard SATA disks as examples. As I understand, the "consistent" message comes up when the journal is actually used to return the filesystem to a consistent state (what would happen after a power failure, when the filesystem is "dirty") and the "clean" message means there was no inconsistency between the filesystem and journal (a normat shutdown of the filesystem). If it comes up as "clean", I wonder why fsck kicks in at all... From bjmccann at gmail.com Thu Aug 28 15:58:42 2008 From: bjmccann at gmail.com (Brian McCann) Date: Thu Aug 28 15:58:54 2008 Subject: gjournal & fsck In-Reply-To: <48B6C36E.4040502@gmail.com> References: <2b5f066d0808280705y3454c188v768efe46b388864b@mail.gmail.com> <2b5f066d0808280743g69c32d1rd30aee0ca276125@mail.gmail.com> <2b5f066d0808280803ibca3f61xbb167bce384f228@mail.gmail.com> <2b5f066d0808280805t4c5f7051i60d02c7396c5f06d@mail.gmail.com> <48B6C36E.4040502@gmail.com> Message-ID: <2b5f066d0808280858k74118385rbf49c4da292958af@mail.gmail.com> On Thu, Aug 28, 2008 at 11:25 AM, Manolis Kiagias wrote: >> > > I don't have any "exotic" hardware myself - the article was written with > standard SATA disks as examples. > As I understand, the "consistent" message comes up when the journal is > actually used to return the filesystem to a consistent state (what would > happen after a power failure, when the filesystem is "dirty") and the > "clean" message means there was no inconsistency between the filesystem and > journal (a normat shutdown of the filesystem). If it comes up as "clean", I > wonder why fsck kicks in at all... > The only thing I can think of is the "dirty bit" is still set on the file system, so it insists on fsck'ing it...but I'm obviously fuzzy on the whole thing. Interestingly enough...I checked dmesg.boot on one of the 8.6TB machines (which is running a completely different controller...a 3Ware 9550)...and I didn't get those BIO_FLUSH errors... Again, thanks for your help! If you think of anything, please let me know...this is getting old fast since the box has hung twice this week now. --Brian From gavin at FreeBSD.org Thu Aug 28 16:04:05 2008 From: gavin at FreeBSD.org (gavin@FreeBSD.org) Date: Thu Aug 28 16:04:12 2008 Subject: kern/126902: [geom] [geom_label] Kernel panic during install boot Message-ID: <200808281604.m7SG43iq006142@freefall.freebsd.org> Old Synopsis: [geom] Kernel panic during install boot New Synopsis: [geom] [geom_label] Kernel panic during install boot State-Changed-From-To: feedback->open State-Changed-By: gavin State-Changed-When: Thu Aug 28 16:02:47 UTC 2008 State-Changed-Why: Feedback was recceived Responsible-Changed-From-To: gavin->freebsd-geom Responsible-Changed-By: gavin Responsible-Changed-When: Thu Aug 28 16:02:47 UTC 2008 Responsible-Changed-Why: This looks to be a GEOM problem, possibly with geom_label. Over to maintainers. http://www.freebsd.org/cgi/query-pr.cgi?pr=126902 From ivoras at freebsd.org Thu Aug 28 17:05:03 2008 From: ivoras at freebsd.org (Ivan Voras) Date: Thu Aug 28 17:05:48 2008 Subject: gjournal & fsck In-Reply-To: <2b5f066d0808280803ibca3f61xbb167bce384f228@mail.gmail.com> References: <2b5f066d0808280705y3454c188v768efe46b388864b@mail.gmail.com> <2b5f066d0808280743g69c32d1rd30aee0ca276125@mail.gmail.com> <2b5f066d0808280803ibca3f61xbb167bce384f228@mail.gmail.com> Message-ID: Brian McCann wrote: > On Thu, Aug 28, 2008 at 10:51 AM, Ivan Voras wrote: >> Does gjournal complain about your drive, for example that it doesn't >> support BIOFLUSH? > > Actually yes...I meant to post them in my last message, but hit send > too early...here's my output from boot (from dmesg.boot) > > GEOM_JOURNAL: Journal 478661671: da1 contains data. > GEOM_JOURNAL: Journal 478661671: da1 contains journal. > GEOM_JOURNAL: Journal da1 clean. > (da1:mly0:4:1:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 > (da1:mly0:4:1:0): CAM Status: SCSI Status Error > (da1:mly0:4:1:0): SCSI Status: Check Condition > (da1:mly0:4:1:0): ILLEGAL REQUEST asc:24,0 > (da1:mly0:4:1:0): Invalid field in CDB > (da1:mly0:4:1:0): Unretryable error > GEOM_JOURNAL: BIO_FLUSH not supported by da1. > GEOM_JOURNAL: Journal 3065355517: da2 contains data. > GEOM_JOURNAL: Journal 3065355517: da2 contains journal. > GEOM_JOURNAL: Journal da2 clean. > (da2:mly1:4:0:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 > (da2:mly1:4:0:0): CAM Status: SCSI Status Error > (da2:mly1:4:0:0): SCSI Status: Check Condition > (da2:mly1:4:0:0): ILLEGAL REQUEST asc:24,0 > (da2:mly1:4:0:0): Invalid field in CDB > (da2:mly1:4:0:0): Unretryable error > GEOM_JOURNAL: BIO_FLUSH not supported by da2. >> Also, did fsck actually do something when it was started (did it find >> anything corrupted)? >> > No...it didn't find anything wrong / anything to fix. (and one of the > file systems was being written to at the time...so at least journaling > appears to be working) Something else I noticed...Manolis' article > says it should say "journal xxxx consistent"...whereas mine says > "Journal xxxx clean". I don't know what the differences mean, or what > the BIO_FLUSH means...but I'm hoping you can tell me. :) Ok, this is most probably the cause of your fsck. BIO_FLUSH is a catch-all name for operations that synchronize (commit) the drive and controller caches. It is used to synchronize the file system state after it's been committed from the journal - if BIO_FLUSH succeeds the data is guaranteed (or should be guaranteed) by hardware that it's safely written. Since your controller doesn't support it you have a problem here. Your best bet is to ask the author of the driver for your controller (according to the "mly" man page this is Michael Smith ) if he knows anything that can help you here (maybe the driver simply needs to implement it or fix it). Other than that, you might disable write caching on your controller. This should significantly reduce the cases where fsck would need to be called on reboot, but probably not eliminate them completely. It will also slow down the commit operation (from the journal to the active file system) but if the server doesn't constantly write to the file system it won't be a big problem. -------------- 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/20080828/9e306e88/signature.pgp From pjd at FreeBSD.org Thu Aug 28 19:26:29 2008 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Thu Aug 28 19:26:42 2008 Subject: gjournal & fsck In-Reply-To: <2b5f066d0808280803ibca3f61xbb167bce384f228@mail.gmail.com> References: <2b5f066d0808280705y3454c188v768efe46b388864b@mail.gmail.com> <2b5f066d0808280743g69c32d1rd30aee0ca276125@mail.gmail.com> <2b5f066d0808280803ibca3f61xbb167bce384f228@mail.gmail.com> Message-ID: <20080828190429.GB2292@garage.freebsd.pl> On Thu, Aug 28, 2008 at 11:03:49AM -0400, Brian McCann wrote: > On Thu, Aug 28, 2008 at 10:51 AM, Ivan Voras wrote: > > > > Does gjournal complain about your drive, for example that it doesn't > > support BIOFLUSH? > > Actually yes...I meant to post them in my last message, but hit send > too early...here's my output from boot (from dmesg.boot) > > GEOM_JOURNAL: Journal 478661671: da1 contains data. > GEOM_JOURNAL: Journal 478661671: da1 contains journal. > GEOM_JOURNAL: Journal da1 clean. > (da1:mly0:4:1:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 > (da1:mly0:4:1:0): CAM Status: SCSI Status Error > (da1:mly0:4:1:0): SCSI Status: Check Condition > (da1:mly0:4:1:0): ILLEGAL REQUEST asc:24,0 > (da1:mly0:4:1:0): Invalid field in CDB > (da1:mly0:4:1:0): Unretryable error > GEOM_JOURNAL: BIO_FLUSH not supported by da1. > GEOM_JOURNAL: Journal 3065355517: da2 contains data. > GEOM_JOURNAL: Journal 3065355517: da2 contains journal. > GEOM_JOURNAL: Journal da2 clean. > (da2:mly1:4:0:0): SYNCHRONIZE CACHE. CDB: 35 0 0 0 0 0 0 0 0 0 > (da2:mly1:4:0:0): CAM Status: SCSI Status Error > (da2:mly1:4:0:0): SCSI Status: Check Condition > (da2:mly1:4:0:0): ILLEGAL REQUEST asc:24,0 > (da2:mly1:4:0:0): Invalid field in CDB > (da2:mly1:4:0:0): Unretryable error > GEOM_JOURNAL: BIO_FLUSH not supported by da2. > > > > > Also, did fsck actually do something when it was started (did it find > > anything corrupted)? > > > No...it didn't find anything wrong / anything to fix. (and one of the > file systems was being written to at the time...so at least journaling > appears to be working) Something else I noticed...Manolis' article > says it should say "journal xxxx consistent"...whereas mine says > "Journal xxxx clean". I don't know what the differences mean, or what > the BIO_FLUSH means...but I'm hoping you can tell me. :) Don't worry about those if you have memory-backed RAID card. BIO_FLUSH is there to tell the disk to flush its write caches, but if it is memory-backed, there is low risk on losing unwritted data. This is not the cause of your problem. BTW. "journal ... clean" means that there was clean shutdown and there was no need to replay journal, while "journal ... consistent" means that there was unclean shutdown and journal replay was successful. -- 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/20080828/3cf047f9/attachment.pgp From pjd at FreeBSD.org Thu Aug 28 19:26:29 2008 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Thu Aug 28 19:26:59 2008 Subject: gjournal & fsck In-Reply-To: <48B6B9D0.8060302@gmail.com> References: <2b5f066d0808280705y3454c188v768efe46b388864b@mail.gmail.com> <48B6B9D0.8060302@gmail.com> Message-ID: <20080828185916.GA2292@garage.freebsd.pl> On Thu, Aug 28, 2008 at 05:44:32PM +0300, Manolis Kiagias wrote: > Brian McCann wrote: > >Hi all. I'm having some problems with several servers I've built > >recently (7.0-RELEASE) that are using gjournal. I had two reboot a > >few days ago (un-related to FreeBSD problems I think)...but when they > >came back up, the file systems wouldn't mount since they were not > >clean. Now, I understand that UFS knows nothing about the fact that > >it's journaled, and the journaling knows nothing about UFS...but it's > >my understanding that by using gjournal, you should really never need > >to fsck a file system. However, the only way to get them to mount is > >by doing the fsck. Is there something else I should be doing instead > >of fsck? > > > >And since I know it will probably come up, I built the file systems > >using the instructions and notes at > >http://www.freebsd.org/cgi/man.cgi?query=gjournal&apropos=0&sektion=0&manpath=FreeBSD+7.0-RELEASE&format=html. > > > >Any help would be greatly appreciated! > >Thanks! > >--Brian > > > > > > You may wish to have a look at this article: > > http://www.freebsd.org/doc/en_US.ISO8859-1/articles/gjournal-desktop > > In particular, you should make sure you use tunefs to enable Journaling > and disable soft update on the journaled filesystems, i.e.: > > tunefs -J enable -n disable /dev/ad0s1f.journal > > Mount them using the async option: > > /dev/ad0s1f.journal /usr ufs rw,async 2 2 > > Note that the pass # still indicates the filesystem should be checked. > While I was writing the article, I was trying several scenarios were I > had the pass # set to 0, thinking that a gjournaled filesystem would not > need fsck at all. I would then press the reset button. In most cases, > the system would refuse to mount them. However with the pass # set, the > fsck would finish almost immediately, since the actual consistency check > takes place when the gjournal module is loaded (you will get a "journal > consistent" after a bad reboot) and before fstab is even parsed. All > fsck does in this case is simply confirm to the system it is a clean volume. > > In short, leaving the pass # to something that would cause an fsck is > the safe way to go. The fsck will be almost instant anyway. Not exactly. Gjournal handles all inconsistencies, except one - orphaned files. An orphaned file is a file that some open, deleted, but haven't closed. If you have panic or power failure at this point, there will be unreferenced file. When fsck detects that it operates on gjournaled file system, it will do a very fast lookup of such orphaned files. It is optimized so that total number of such files is kept in superblock - if this counter is 0, we're done. If it is not zero, then fsck scans only cylinder groups headers, there is another counter in each header says how many orphaned files is in this CG. If CG's counter is 0, the whole CG can be skipped. Once we found X dirty CGs (X is stored in superblock) we can also stop earlier. All in all, there are very few such files (if any), so fsck is way, way faster with gjournal (eg. ~1 minute instead of ~8 hours on huge file system). -- 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/20080828/00338729/attachment.pgp From pjd at FreeBSD.org Thu Aug 28 19:26:30 2008 From: pjd at FreeBSD.org (Pawel Jakub Dawidek) Date: Thu Aug 28 19:26:59 2008 Subject: gjournal & fsck In-Reply-To: <2b5f066d0808280743g69c32d1rd30aee0ca276125@mail.gmail.com> References: <2b5f066d0808280705y3454c188v768efe46b388864b@mail.gmail.com> <2b5f066d0808280743g69c32d1rd30aee0ca276125@mail.gmail.com> Message-ID: <20080828190550.GC2292@garage.freebsd.pl> On Thu, Aug 28, 2008 at 10:43:58AM -0400, Brian McCann wrote: > On Thu, Aug 28, 2008 at 10:34 AM, Ivan Voras wrote: > > Brian McCann wrote: > >> Hi all. I'm having some problems with several servers I've built > >> recently (7.0-RELEASE) that are using gjournal. I had two reboot a > >> few days ago (un-related to FreeBSD problems I think)...but when they > >> came back up, the file systems wouldn't mount since they were not > >> clean. Now, I understand that UFS knows nothing about the fact that > >> it's journaled, and the journaling knows nothing about UFS...but it's > > > > Actually UFS needs to know about gjournal for just this purpose. There's > > a special option to newfs that tells the file system to be aware of > > gjournal and it should request fscks. > > > >> my understanding that by using gjournal, you should really never need > >> to fsck a file system. However, the only way to get them to mount is > >> by doing the fsck. Is there something else I should be doing instead > >> of fsck? > > > > man 8 tunefs > > > > > Yes...I apologize...I did that when I built the file system with > "newfs -J". Here's the tunefs -p output for one of the file systems: > > # tunefs -p /dev/da2.journal > tunefs: ACLs: (-a) disabled > tunefs: MAC multilabel: (-l) disabled > tunefs: soft updates: (-n) disabled > tunefs: gjournal: (-J) enabled > tunefs: maximum blocks per file in a cylinder group: (-e) 2048 > tunefs: average file size: (-f) 16384 > tunefs: average number of files in a directory: (-s) 64 > tunefs: minimum percentage of free space: (-m) 8% > tunefs: optimization preference: (-o) time > tunefs: volume label: (-L) > > I'm concerned about this because the ones I've had problems with > recently are 1.1TB arrays...I've got 2 8.6TB arrays that are journaled > as well...and if I ever have to fsck them...that could take 1/2 the > day... > > Any other thoughts? Everything looks good. Do you have 'fsck_y_enable' in your rc.conf by any chance? gjournal mode in fsck is only used for -p option, AFAIR. -- 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/20080828/6223e89e/attachment.pgp