Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown
On 2012-08-28 22:51, Matt Smith wrote: On 2012-08-27 21:35, Warren Block wrote: On Mon, 27 Aug 2012, Matt Smith wrote: Thank you for your help anyway, and your wonkity site, which I also once used for converting my procmail to maildrop. And thanks also to Erich and Stefan for your help. When I get some spare time I'll redo the filesystem and hope that it works. Please post a followup after that. Here is the followup! I have just rebuilt the server from scratch using a 9.1-RC1 amd64 memstick image. Used the GPT labels directly in the fstab and ignored glabel. And guess what? It works fine as you probably expected. So it was definitely user error and the glabel broke it. At least I've learnt a lot more about partitioning and filesystems than I knew before anyway! So once again, thank you for all your help. There is an open PR for this that I raised which is amd64/170646 , I don't think there is any way for me to close this myself is there? If somebody reads this who has the rights to do so then please close it with user is an idiot :) Matt. Hi again. Seems it was not actually that simple after all. Yesterday I had tested rebooting the server after just the base O/S had been installed and it was working fine so I assumed that was it. Today I have reinstalled all my ports and then decided to do one last reboot to make sure everything came up properly. And guess what? The same error happened again! I then tracked it down. It seems to happen when the mail/postgrey port is started. If I comment that out of rc.conf and reboot and let it mark the filesystem clean then I can happily reboot with no issues again. If I remove the comment and start it up then I get the same issue on the next reboot. So there is something strange happening between the mail/postgrey port and 9.1-RC1 amd64. As greylisting isn't completely important I can leave this disabled for now but I would like to still resolve this issue so that I can use it again, unless there is alternative greylisting software that I could use with postfix. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown
On 2012-08-27 21:35, Warren Block wrote: On Mon, 27 Aug 2012, Matt Smith wrote: Thank you for your help anyway, and your wonkity site, which I also once used for converting my procmail to maildrop. And thanks also to Erich and Stefan for your help. When I get some spare time I'll redo the filesystem and hope that it works. Please post a followup after that. Here is the followup! I have just rebuilt the server from scratch using a 9.1-RC1 amd64 memstick image. Used the GPT labels directly in the fstab and ignored glabel. And guess what? It works fine as you probably expected. So it was definitely user error and the glabel broke it. At least I've learnt a lot more about partitioning and filesystems than I knew before anyway! So once again, thank you for all your help. There is an open PR for this that I raised which is amd64/170646 , I don't think there is any way for me to close this myself is there? If somebody reads this who has the rights to do so then please close it with user is an idiot :) Matt. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown
I posted on this mailing list two weeks ago and never received any replies so I decided to raise a PR via the web form. But I think I submitted it under the wrong category and it's marked as low priority as well. But I think this is something that is a potential serious problem if I end up getting a corrupted filesystem so I'm posting here again in the hope somebody can help this time. The PR is amd64/170646. I'm now running the latest RELENG_9 code as of 25th August as I've done a new buildworld/kernel. I still get the same problem. When I reboot it I get WARNING: / was not properly dismounted and it rebuilds from journal. On shutdown I get the messages pasted below. I'm running amd64 with GPT partitioning, UFS2 with softupdates and softupdates journalling enabled. I have a custom kernel but I don't think I took anything important out of it. Syncing disks, vnodes remaining...7 7 2 0 0 done All buffers synced. fsync: giving up on dirty 0xfe0007102780: tag devfs, type VCHR usecount 1, writecount 0, refcount 2292 mountedhere 0xfe00729ca00 flags (VI(0x200)) v_object 0xfe0005101910 ref 0 pages 23509 lock type devfs: EXCL by thread 0xfe00018fe08e0 (pid 1) dev label/root umount of / failed (35) Then when the box comes back up again it detects that / was not unmounted cleanly and recovers from journal before marking it clean once more. My uname: FreeBSD tao.xtaz.co.uk 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0: Sat Aug 25 12:34:52 BST 2012 r...@tao.xtaz.co.uk:/usr/obj/usr/src/sys/TAO amd64 My glabel status: Name Status Components gpt/gptboot N/A ada0p1 gptid/bfe99d62-e00f-11e1-8623-00012e475ffb N/A ada0p1 label/root N/A ada0p2 label/swap N/A ada0p3 My fstab: /dev/label/root / ufs rw 1 1 /dev/label/swap none swap sw 0 0 My gpart: = 34 1250263661 ada0 GPT (596G) 34 1024 1 freebsd-boot (512k) 1058 990 - free - (495k) 2048 1228931072 2 freebsd-ufs (586G) 1228933120 21330575 3 freebsd-swap (10G) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown
Am 27.08.2012 um 11:06 schrieb Matt Smith: I posted on this mailing list two weeks ago and never received any replies so I decided to raise a PR via the web form. But I think I submitted it under the wrong category and it's marked as low priority as well. But I think this is something that is a potential serious problem if I end up getting a corrupted filesystem so I'm posting here again in the hope somebody can help this time. The PR is amd64/170646. I'm now running the latest RELENG_9 code as of 25th August as I've done a new buildworld/kernel. I still get the same problem. When I reboot it I get WARNING: / was not properly dismounted and it rebuilds from journal. On shutdown I get the messages pasted below. I'm running amd64 with GPT partitioning, UFS2 with softupdates and softupdates journalling enabled. I have a custom kernel but I don't think I took anything important out of it. Syncing disks, vnodes remaining...7 7 2 0 0 done All buffers synced. fsync: giving up on dirty 0xfe0007102780: tag devfs, type VCHR usecount 1, writecount 0, refcount 2292 mountedhere 0xfe00729ca00 flags (VI(0x200)) v_object 0xfe0005101910 ref 0 pages 23509 lock type devfs: EXCL by thread 0xfe00018fe08e0 (pid 1) dev label/root umount of / failed (35) Then when the box comes back up again it detects that / was not unmounted cleanly and recovers from journal before marking it clean once more. My fstab: /dev/label/root / ufs rw 1 1 /dev/label/swap none swap sw 0 0 Is there a particular reason you've decided to glabel your partitions instead of using GPT labels? Which device did you do the newfs on, the GPT partition or the glabel device? My hunch is that the label metadata sector at the end of the GPT partition is interfering with the filesystem. I'd try labelling my partitions (gpart modify -i 2 -l root ada0; gpart modify -i 3 -l swap), then change fstab to reference the gpt labels (dev(gpt/root) instead of the glabel ones. Stefan -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown
On 27.08.2012 10:06, Matt Smith wrote: I posted on this mailing list two weeks ago and never received any replies so I decided to raise a PR via the web form. But I think I submitted it under the wrong category and it's marked as low priority as well. But I think this is something that is a potential serious problem if I end up getting a corrupted filesystem so I'm posting here again in the hope somebody can help this time. The PR is amd64/170646. I'm now running the latest RELENG_9 code as of 25th August as I've done a new buildworld/kernel. I still get the same problem. When I reboot it I get WARNING: / was not properly dismounted and it rebuilds from journal. On shutdown I get the messages pasted below. I'm running amd64 with GPT partitioning, UFS2 with softupdates and softupdates journalling enabled. I have a custom kernel but I don't think I took anything important out of it. Syncing disks, vnodes remaining...7 7 2 0 0 done All buffers synced. fsync: giving up on dirty 0xfe0007102780: tag devfs, type VCHR usecount 1, writecount 0, refcount 2292 mountedhere 0xfe00729ca00 flags (VI(0x200)) v_object 0xfe0005101910 ref 0 pages 23509 lock type devfs: EXCL by thread 0xfe00018fe08e0 (pid 1) dev label/root umount of / failed (35) Then when the box comes back up again it detects that / was not unmounted cleanly and recovers from journal before marking it clean once more. My uname: FreeBSD tao.xtaz.co.uk 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0: Sat Aug 25 12:34:52 BST 2012 r...@tao.xtaz.co.uk:/usr/obj/usr/src/sys/TAO amd64 My glabel status: Name Status Components gpt/gptboot N/A ada0p1 gptid/bfe99d62-e00f-11e1-8623-00012e475ffb N/A ada0p1 label/root N/A ada0p2 label/swap N/A ada0p3 My fstab: /dev/label/root / ufs rw 1 1 /dev/label/swap none swap sw 0 0 My gpart: = 34 1250263661 ada0 GPT (596G) 34 1024 1 freebsd-boot (512k) 1058 990 - free - (495k) 2048 1228931072 2 freebsd-ufs (586G) 1228933120 21330575 3 freebsd-swap (10G) Hi Matt I'm far from anything near an expert on file systems but I'd suggest you remove softupdates and leave journaling on. tunefs -n disable There's no need to have both on and although I agree that both SHOULD work together there's no reason to have them on together. It will only slow down writes to the file system. Effectively soft updates was a go-between before journalin was introduced. //Clay ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown
On 2012-08-27 10:28, Stefan Bethke wrote: Is there a particular reason you've decided to glabel your partitions instead of using GPT labels? Which device did you do the newfs on, the GPT partition or the glabel device? My hunch is that the label metadata sector at the end of the GPT partition is interfering with the filesystem. I'd try labelling my partitions (gpart modify -i 2 -l root ada0; gpart modify -i 3 -l swap), then change fstab to reference the gpt labels (dev(gpt/root) instead of the glabel ones. No reason at all really. I had just used it like that on a previous MBR based system and it worked fine. I have just booted it using the USB stick again and removed both labels metadata using glabel stop and clear and changed the fstab to use /dev/gpt/ labels now. Unfortunately the same issue persists. It mounted fine, but when I rebooted it it synced all buffers successfully but then gave the same error saying that it couldn't unmount /. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown
On 2012-08-27 10:25, c...@milos.co.za wrote: I'm far from anything near an expert on file systems but I'd suggest you remove softupdates and leave journaling on. tunefs -n disable There's no need to have both on and although I agree that both SHOULD work together there's no reason to have them on together. It will only slow down writes to the file system. Effectively soft updates was a go-between before journalin was introduced. Really? This is SU+J journalling that I'm using. Not gjournal. Surely SU+J does require softupdates to be on as it's part of the same thing? Output from tunefs -p: tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) enabled tunefs: gjournal: (-J) disabled ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown
Hi, On Mon, 27 Aug 2012 11:12:52 +0100 Matt Smith m...@xtaz.co.uk wrote: On 2012-08-27 10:28, Stefan Bethke wrote: Is there a particular reason you've decided to glabel your partitions instead of using GPT labels? Which device did you do the newfs on, the GPT partition or the glabel device? My hunch is that the label metadata sector at the end of the GPT partition is interfering with the filesystem. I'd try labelling my partitions (gpart modify -i 2 -l root ada0; gpart modify -i 3 -l swap), then change fstab to reference the gpt labels (dev(gpt/root) instead of the glabel ones. No reason at all really. I had just used it like that on a previous MBR based system and it worked fine. I have just booted it using the USB stick again and removed both labels metadata using glabel stop and clear and changed the fstab to use /dev/gpt/ labels now. Unfortunately the same issue persists. It mounted fine, but when I rebooted it it synced all buffers successfully but then gave the same error saying that it couldn't unmount /. I would run plain UFS for / /var and /tmp and see what will happen then. I know what you will answer. But it will help to isolate the problem. Erich ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown
On 2012-08-27 11:26, Erich Dollansky wrote: I would run plain UFS for / /var and /tmp and see what will happen then. I know what you will answer. But it will help to isolate the problem. Did you mean not use the label at all? If so I just tried this. Set /dev/ada0p2 in the fstab. No change. Still get the same issue. This might help investigations as I wrote down what I did to install it. The way I created this filesystem was that I dropped out of the installer to a shell because I wanted to do the 4k alignment. And I ran this: gpart create -s gpt ada0 gpart add -t freebsd-boot -l gptboot -s 512k ada0 gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 ada0 gpart add -t freebsd-ufs -l gptroot -b 1M -s 586G ada0 gpart add -t freebsd-swap -l gptswap ada0 gpart show =34 1250263661 ada0 GPT (596G) 341024 1 freebsd-boot (512k) 1058 990- free - (495k) 2048 1228931072 2 freebsd-ufs (586G) 122893312021330575 3 freebsd-swap (10G) newfs -U -j -L root /dev/gpt/gptroot glabel label root /dev/ada0p2 glabel label swap /dev/ada0p3 mount /dev/gpt/gptroot /mnt vi /tmp/bsdinstall_etc/fstab # DeviceMountpoint FStype Options Dump Pass# /dev/label/root / ufs rw 1 1 /dev/label/swap noneswapsw 0 0 exit ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown
On 27.08.2012 11:15, Matt Smith wrote: On 2012-08-27 10:25, c...@milos.co.za wrote: I'm far from anything near an expert on file systems but I'd suggest you remove softupdates and leave journaling on. tunefs -n disable There's no need to have both on and although I agree that both SHOULD work together there's no reason to have them on together. It will only slow down writes to the file system. Effectively soft updates was a go-between before journalin was introduced. Really? This is SU+J journalling that I'm using. Not gjournal. Surely SU+J does require softupdates to be on as it's part of the same thing? Output from tunefs -p: tunefs: soft updates: (-n) enabled tunefs: soft update journaling: (-j) enabled tunefs: gjournal: (-J) disabled I saw that you had soft updates and soft updates journaling in your original email. What you have is correct. That is how 9.x sets up the FS by default nowadays. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown
On Mon, 27 Aug 2012, Matt Smith wrote: On 2012-08-27 11:26, Erich Dollansky wrote: I would run plain UFS for / /var and /tmp and see what will happen then. I know what you will answer. But it will help to isolate the problem. Did you mean not use the label at all? If so I just tried this. Set /dev/ada0p2 in the fstab. No change. Still get the same issue. This might help investigations as I wrote down what I did to install it. The way I created this filesystem was that I dropped out of the installer to a shell because I wanted to do the 4k alignment. And I ran this: gpart create -s gpt ada0 gpart add -t freebsd-boot -l gptboot -s 512k ada0 gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 ada0 gpart add -t freebsd-ufs -l gptroot -b 1M -s 586G ada0 gpart add -t freebsd-swap -l gptswap ada0 gpart show =34 1250263661 ada0 GPT (596G) 341024 1 freebsd-boot (512k) 1058 990- free - (495k) 2048 1228931072 2 freebsd-ufs (586G) 122893312021330575 3 freebsd-swap (10G) newfs -U -j -L root /dev/gpt/gptroot glabel label root /dev/ada0p2 glabel label swap /dev/ada0p3 mount /dev/gpt/gptroot /mnt vi /tmp/bsdinstall_etc/fstab # DeviceMountpoint FStype Options DumpPass# /dev/label/root / ufs rw 1 1 /dev/label/swap noneswapsw 0 0 Stefan called it. The newfs is done on /dev/gpt/gptroot, no problem there. But when glabel writes to /dev/ada0p2--which is /dev/gpt/gptroot, same thing, it overwrites the last block. And then the filesystem is mounted with the glabel device, which is actually one block smaller than the filesystem expects. Could be either the filesystem or GEOM that's causing the failure at shutdown. Happily, those glabels aren't accomplishing anything useful and can be skipped. Removing the glabels and changing the devices in fstab might be enough. A more cautious approach would be to back up, newfs, skip the glabel step, and then change the devices in fstab. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown
On 2012-08-27 14:56, Warren Block wrote: Stefan called it. The newfs is done on /dev/gpt/gptroot, no problem there. But when glabel writes to /dev/ada0p2--which is /dev/gpt/gptroot, same thing, it overwrites the last block. And then the filesystem is mounted with the glabel device, which is actually one block smaller than the filesystem expects. Could be either the filesystem or GEOM that's causing the failure at shutdown. Happily, those glabels aren't accomplishing anything useful and can be skipped. Removing the glabels and changing the devices in fstab might be enough. A more cautious approach would be to back up, newfs, skip the glabel step, and then change the devices in fstab. As I said on a previous mail I did boot it with a USB stick and cleared the glabel metadata and altered the fstab to point to both the GPT labels and the raw UFS device and I still get the issue. So am I right in thinking then that this has caused irreparable damage and the only way I can fix this now is to newfs the filesystem again, this time just using GPT labels and not using glabel at all? This is the first time I've ever done a manually partitioned installation with GPT and alignment, previously I've only ever used sysinstall with non-aligned MBR installations, so it was a bit of a learning curve. If I do have to newfs it again then I want to be sure that I'm doing the correct things so that I don't find myself with any other issues. So does the rest of what I did look fine? If it is clearly my own fault then the PR can obviously be closed and chalked up to learning! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown
On Mon, 27 Aug 2012, Matt Smith wrote: On 2012-08-27 14:56, Warren Block wrote: Stefan called it. The newfs is done on /dev/gpt/gptroot, no problem there. But when glabel writes to /dev/ada0p2--which is /dev/gpt/gptroot, same thing, it overwrites the last block. And then the filesystem is mounted with the glabel device, which is actually one block smaller than the filesystem expects. Could be either the filesystem or GEOM that's causing the failure at shutdown. Happily, those glabels aren't accomplishing anything useful and can be skipped. Removing the glabels and changing the devices in fstab might be enough. A more cautious approach would be to back up, newfs, skip the glabel step, and then change the devices in fstab. As I said on a previous mail I did boot it with a USB stick and cleared the glabel metadata and altered the fstab to point to both the GPT labels and the raw UFS device and I still get the issue. So am I right in thinking then that this has caused irreparable damage To the filesystem? Probably (weasel word) not. The old instructions for gmirror used the last block out of a filesystem and there have been no notable reports of data loss. One thing to mention is that SU+J might change what the filesystem does with that last block. I'm avoiding SU+J until the dump problem is fixed, so have not experimented with that. and the only way I can fix this now is to newfs the filesystem again, this time just using GPT labels and not using glabel at all? I'll commit to it and say yes, that will work. This is the first time I've ever done a manually partitioned installation with GPT and alignment, previously I've only ever used sysinstall with non-aligned MBR installations, so it was a bit of a learning curve. If I do have to newfs it again then I want to be sure that I'm doing the correct things so that I don't find myself with any other issues. So does the rest of what I did look fine? No obvious problems jumped out at me. Here are my notes: http://www.wonkity.com/~wblock/docs/html/disksetup.html The gpart version is halfway down. I really need to switch that around. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown
On Mon, 27 Aug 2012, Warren Block wrote: No obvious problems jumped out at me. Here are my notes: http://www.wonkity.com/~wblock/docs/html/disksetup.html The gpart version is halfway down. I really need to switch that around. Changed now so that the gpart(8) version is first. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown
On 2012-08-27 19:42, Warren Block wrote: No obvious problems jumped out at me. Here are my notes: http://www.wonkity.com/~wblock/docs/html/disksetup.html The gpart version is halfway down. I really need to switch that around. Oh! You're the owner of that site. As it happens those were the exact instructions that I used to try and figure out how to do it as you are first in google for freebsd gpt newfs! It's just a shame that I then decided to use the same method that I had used before on my old system for the labelling. On my old system I had used MBR partitioning and so needed to use glabel for labelling the swap and I then used the same thing for the UFS partition for consistency in the fstab. It never occurred to me when I was labelling the GPT partitions that I could have used those directly. One thing that is still bugging me though is I'm wondering why I had no problem with this on my old system. That was using a dangerously dedicated disk with MBR where the root partition was just /dev/ada4a. It was also using UFS2 with SU+J enabled and I had used glabel in exactly the same way but on this box it had not done any damage. Shutdown etc worked perfectly fine. Is there something different with the way GPT partitions work? Thank you for your help anyway, and your wonkity site, which I also once used for converting my procmail to maildrop. And thanks also to Erich and Stefan for your help. When I get some spare time I'll redo the filesystem and hope that it works. Matt. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown
On Mon, Aug 27, 2012 at 11:42 AM, Warren Block wbl...@wonkity.com wrote: On Mon, 27 Aug 2012, Matt Smith wrote: On 2012-08-27 14:56, Warren Block wrote: Stefan called it. The newfs is done on /dev/gpt/gptroot, no problem there. But when glabel writes to /dev/ada0p2--which is /dev/gpt/gptroot, same thing, it overwrites the last block. And then the filesystem is mounted with the glabel device, which is actually one block smaller than the filesystem expects. Could be either the filesystem or GEOM that's causing the failure at shutdown. Happily, those glabels aren't accomplishing anything useful and can be skipped. Removing the glabels and changing the devices in fstab might be enough. A more cautious approach would be to back up, newfs, skip the glabel step, and then change the devices in fstab. As I said on a previous mail I did boot it with a USB stick and cleared the glabel metadata and altered the fstab to point to both the GPT labels and the raw UFS device and I still get the issue. So am I right in thinking then that this has caused irreparable damage To the filesystem? Probably (weasel word) not. The old instructions for gmirror used the last block out of a filesystem and there have been no notable reports of data loss. One thing to mention is that SU+J might change what the filesystem does with that last block. I'm avoiding SU+J until the dump problem is fixed, so have not experimented with that. and the only way I can fix this now is to newfs the filesystem again, this time just using GPT labels and not using glabel at all? I'll commit to it and say yes, that will work. This is the first time I've ever done a manually partitioned installation with GPT and alignment, previously I've only ever used sysinstall with non-aligned MBR installations, so it was a bit of a learning curve. If I do have to newfs it again then I want to be sure that I'm doing the correct things so that I don't find myself with any other issues. So does the rest of what I did look fine? No obvious problems jumped out at me. Here are my notes: http://www.wonkity.com/~wblock/docs/html/disksetup.html The gpart version is halfway down. I really need to switch that around. Pretty good page, but I would really suggest that you also do either 4k or 1M alignment on your partitions. If you don't and use a disk with 4K blocks (internally), you will have terrible performance. 1M is recommended by Microsoft and used by Windows, but seems a bit excessive to me. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown
On Mon, 27 Aug 2012, Kevin Oberman wrote: No obvious problems jumped out at me. Here are my notes: http://www.wonkity.com/~wblock/docs/html/disksetup.html The gpart version is halfway down. I really need to switch that around. Pretty good page, but I would really suggest that you also do either 4k or 1M alignment on your partitions. If you don't and use a disk with 4K blocks (internally), you will have terrible performance. You mean add the -a parameter for gpart? All that -a does is round partition starting blocks and sizes to even values. If the numbers given are already even multiples, it does nothing. The reason -a4k is not shown there is because until a few months ago, -a overrode -b. So # gpart add -t freebsd-ufs -l gprootfs -a4k -b 1M -s 2G da0 did not start that partition at 1M, but instead at the next even 4K block after the first 512K partition; block 1064 instead of block 2048, AFAIR. The fix to gpart (thanks to ae@) is in 9-stable and 9.1, but not earlier releases. Mentioned a little farther down in the article is that keeping additional partitions to even multiples of 1M or 1G size will keep them in alignment. 1M is recommended by Microsoft and used by Windows, but seems a bit excessive to me. Also by some Sun RAID controllers and other systems. 1M is a nice even multiple of a lot of common block sizes. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown
On Mon, 27 Aug 2012, Matt Smith wrote: On 2012-08-27 19:42, Warren Block wrote: No obvious problems jumped out at me. Here are my notes: http://www.wonkity.com/~wblock/docs/html/disksetup.html The gpart version is halfway down. I really need to switch that around. Oh! You're the owner of that site. As it happens those were the exact instructions that I used to try and figure out how to do it as you are first in google for freebsd gpt newfs! Hah--I'm famous! It's just a shame that I then decided to use the same method that I had used before on my old system for the labelling. On my old system I had used MBR partitioning and so needed to use glabel for labelling the swap and I then used the same thing for the UFS partition for consistency in the fstab. It never occurred to me when I was labelling the GPT partitions that I could have used those directly. Experience is what you get when you didn't get what you wanted. One thing that is still bugging me though is I'm wondering why I had no problem with this on my old system. That was using a dangerously dedicated disk with MBR where the root partition was just /dev/ada4a. It was also using UFS2 with SU+J enabled and I had used glabel in exactly the same way but on this box it had not done any damage. Shutdown etc worked perfectly fine. Is there something different with the way GPT partitions work? In use, GPT partitioning should work just the same. Without recreating it, hard to define the difference that caused the shutdown problem. Thank you for your help anyway, and your wonkity site, which I also once used for converting my procmail to maildrop. And thanks also to Erich and Stefan for your help. When I get some spare time I'll redo the filesystem and hope that it works. Please post a followup after that. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown
On Mon, Aug 27, 2012 at 1:16 PM, Warren Block wbl...@wonkity.com wrote: On Mon, 27 Aug 2012, Kevin Oberman wrote: No obvious problems jumped out at me. Here are my notes: http://www.wonkity.com/~wblock/docs/html/disksetup.html The gpart version is halfway down. I really need to switch that around. Pretty good page, but I would really suggest that you also do either 4k or 1M alignment on your partitions. If you don't and use a disk with 4K blocks (internally), you will have terrible performance. You mean add the -a parameter for gpart? All that -a does is round partition starting blocks and sizes to even values. If the numbers given are already even multiples, it does nothing. You can force alignment by use of -b. I just managed to miss that you were doing that. '-a' simply does the alignment and I have no reason to forces the location of any partition as all are multiples of 1M and 4K. Use of -a and -b on the same command seems rather useless, but it seems that ignoring -b is still a bug. I'm not sure I get your statement that All that -a does is round partition starting blocks and sizes to even values. -a aligns the start of every partition to the stated size (as your example showed). The reason -a4k is not shown there is because until a few months ago, -a overrode -b. So # gpart add -t freebsd-ufs -l gprootfs -a4k -b 1M -s 2G da0 did not start that partition at 1M, but instead at the next even 4K block after the first 512K partition; block 1064 instead of block 2048, AFAIR. The fix to gpart (thanks to ae@) is in 9-stable and 9.1, but not earlier releases. Mentioned a little farther down in the article is that keeping additional partitions to even multiples of 1M or 1G size will keep them in alignment. 1M is recommended by Microsoft and used by Windows, but seems a bit excessive to me. Also by some Sun RAID controllers and other systems. 1M is a nice even multiple of a lot of common block sizes. True, but so is 4K (8-512 byte blocks). Obviously 1M is also a multiple of all powers of 2 below it as is 4K. Even in this age of cheap disks, 1G alignment seems a bit extreme, but in most cases, it really is insignificant for general purpose systems. It is an argument for single partitions, but I always worry that something screwy will blow up /var with log messages and I would not want this to fill all disk space, so I like to keep that, as well as a read-only root. Just old-fashioned, I guess. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 9.1 RELENG_9 Unable to cleanly dismount root partition on shutdown
On Mon, 27 Aug 2012, Kevin Oberman wrote: On Mon, Aug 27, 2012 at 1:16 PM, Warren Block wbl...@wonkity.com wrote: On Mon, 27 Aug 2012, Kevin Oberman wrote: No obvious problems jumped out at me. Here are my notes: http://www.wonkity.com/~wblock/docs/html/disksetup.html The gpart version is halfway down. I really need to switch that around. Pretty good page, but I would really suggest that you also do either 4k or 1M alignment on your partitions. If you don't and use a disk with 4K blocks (internally), you will have terrible performance. You mean add the -a parameter for gpart? All that -a does is round partition starting blocks and sizes to even values. If the numbers given are already even multiples, it does nothing. You can force alignment by use of -b. I just managed to miss that you were doing that. '-a' simply does the alignment and I have no reason to forces the location of any partition as all are multiples of 1M and 4K. Use of -a and -b on the same command seems rather useless, Might make more sense if -a is seen as a safety check. And yes, -b is an exception, done in this case to get the first partition at a specific spot. but it seems that ignoring -b is still a bug. Works for me in 9-stable. Here's the change in -head: http://svnweb.freebsd.org/base/head/sbin/geom/class/part/geom_part.c?r1=229916r2=235033 It was MFCed to 8-stable and 9-stable on 2012-05-11. I'm not sure I get your statement that All that -a does is round partition starting blocks and sizes to even values. -a aligns the start of every partition to the stated size (as your example showed). Sorry, I should have been more precise with the wording. By even I meant even multiple of the given block value. The reason -a4k is not shown there is because until a few months ago, -a overrode -b. So # gpart add -t freebsd-ufs -l gprootfs -a4k -b 1M -s 2G da0 did not start that partition at 1M, but instead at the next even 4K block after the first 512K partition; block 1064 instead of block 2048, AFAIR. The fix to gpart (thanks to ae@) is in 9-stable and 9.1, but not earlier releases. Mentioned a little farther down in the article is that keeping additional partitions to even multiples of 1M or 1G size will keep them in alignment. 1M is recommended by Microsoft and used by Windows, but seems a bit excessive to me. Also by some Sun RAID controllers and other systems. 1M is a nice even multiple of a lot of common block sizes. True, but so is 4K (8-512 byte blocks). Obviously 1M is also a multiple of all powers of 2 below it as is 4K. Even in this age of cheap disks, 1G alignment seems a bit extreme, but in most cases, it Er, 1M. It leaves a little less than 512K of unused space. Starting at 1G would be a more difficult decision for me, though you're right that it's a trivial amount of space on a lot of computers. really is insignificant for general purpose systems. It is an argument for single partitions, but I always worry that something screwy will blow up /var with log messages and I would not want this to fill all disk space, so I like to keep that, as well as a read-only root. Just old-fashioned, I guess. Understood. Usually separate filesystems for me, although I recently took to using tmpfs for /tmp. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
