On 4/16/2013 1:36 AM, J David wrote:
loader.conf was empty and there's no 4k gnops, geli, anything like that. This is a 100% normal install.Although, since you mentioned 4k blocks, I did leave a gap between ada0p1 and ada0p2 to start the root partition on a 4k boundary. (It's an SSD that will almost never be written to once installed, so that might be a bit silly, but it's a habit already.) I decided to try this again without the gap, and that seems to have worked. I made it through install and partitioning and OS updating to 9-STABLE and installing new boot blocks and it seems to have worked. I even got it to work with a ZFS root. Here's the partition table I ended up with: => 34 234441581 ada0 GPT (111G) 34 990 1 freebsd-boot (495k) 1024 226051072 2 freebsd-zfs (107G) 226052096 8389519 3 freebsd-swap (4.0G) I'm not sure why this would make a difference, but either it does or doing it cleared out whatever else was wrong. This box will be stress tested and rebooted quite a bit in the next few days, so I will report back if it comes unglued. :) Thanks for the suggestion!
I'd say file a bug report, since subtly hidden parts of the disk can be beneficial in the right circumstances. That, and it should just work.
Does your drive report the blocks as 512 bytes or 4k? If you're using zfs now, run `zdb | grep ashift` and it should list 12 if it's 4k. Otherwise, you can get a performance hit if the drive's 4k native. Two of my drives are 4k native but report as 512b, so I had to trick zfs with gnop.
_______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
