kernel config options for hdd

Beeblebrox

Beeblebrox

1. I have built my custom kernel which is running now, but I would like to slim it down some more. I would like to remove the unnecessary disk layout options (I can kldload them if I need to). I have made several tries but the resulting kernel failed to mount root because it could not identify any zfs or gpt partitions ("?" at boot loader listed nothing). My file sys is ZFS on a GPT disk.

2. My current kernel identifies the hdd as ada0 instead of ad4, which must be due to something I took out and I currently have to load ahci from loader.conf. What do I have to add/remove from the kernel config file:

Code: 
device		ahc
device		ahd
options 	GEOM_PART_GPT

#options 	FFS		# Berkeley Fast Filesystem
#options 	SOFTUPDATES	# Enable FFS soft updates support
#options 	UFS_ACL		# Support for access control lists
#options 	UFS_DIRHASH	# Improve performance on big directories
#options 	UFS_GJOURNAL
nooptions       GEOM_PART_BSD
nooptions       GEOM_PART_EBR
nooptions       GEOM_PART_EBR_COMPAT
nooptions       GEOM_PART_MBR
 
Solution to #1 (resulting kernel failed to mount root because no zfs or gpt partitions):
Since my disk is sata, I had taken out these options. Putting them back in solved the issue.
Code: 
device          ata
device          atadisk         # ATA disk drives
options         ATA_STATIC_ID   # Static device numbering

disk still seen as /dev/ada0 though...
 
Beeblebrox said:
1. I have built my custom kernel which is running now, but I would like to slim it down some more. I would like to remove the unnecessary disk layout options (I can kldload them if I need to).
Click to expand...
Any particular reason? "Because I want to" is a perfectly good reason - one of the great things about open source operating systems is that you can do stuff like this and learn. On the other hand, if you're doing it because you want to save memory, you should consider how small the kernel is in relation to overall memory size. As an example, my 8-STABLE kernel is about 7.5MB on a system with 8GB installed.

For those of us who came from severely memory-limited environments (like 2BSD on a PDP-11), we're accustomed to removing every possible un-needed device to save space. But it isn't really necessary on modern systems, unless you're working in an embedded system like a router or NAS box.

The only reasons I build a custom kernel are because I have some site-specific source patches and I follow STABLE, which doesn't have binaries available. So I trim some devices my systems don't have because I was in there anyway.
2. My current kernel identifies the hdd as ada0 instead of ad4, which must be due to something I took out and I currently have to load ahci from loader.conf.
Click to expand...
ATA_STATIC_ID controls this for ata devices. If defined (the default) drives are numbered based on what controller and port they're attached to. If not defined, drives are numbered starting at 0 in the order they are discovered. Defining this is the default, as otherwise a removed drive will renumber all drives after it, causing problems for things with hard-coded drive names, like /etc/fstab.

I don't see a similar STATIC knob for ahci, so it seems they are always numbered starting at 0.
 
Beeblebrox said:
Solution to #1 (resulting kernel failed to mount root because no zfs or gpt partitions):
Since my disk is sata, I had taken out these options. Putting them back in solved the issue.
Code: 
device          ata
device          atadisk         # ATA disk drives
options         ATA_STATIC_ID   # Static device numbering

disk still seen as /dev/ada0 though...
Click to expand...

Well, duh!. :) SATA is serial ATA, as in, a continuation of the ATA subsystem. Removing the ata driver removes the SATA drivers as well.
 
@ Phoenix: For some reason I thought SATA worked through SCSI. Live & Learn I guess.

@ Terry_Keneddy:
Any particular reason?
Click to expand...
Well, "the reason" is a moot point, since I have my custom kernel nicely compiled and running perfectly, thank-you-very-much. But also, I have 1G memory and I do want to skimp on arbitrary processes/modules. Plus, a monolithic all-inclusive kernel does seem a little too windows-esque to me; specially when you can kldload anything missing later-on.

The ada0 -> ad4 problem was fixed after I removed
Code: 
ahci_load="YES"
from loader.conf. So as you noted, ahci.ko was interfering with the STATIC setting already included into the kernel.
 
There are 3 (well, really only 2.5) ways to access ATA disks on FreeBSD:
  1. The old ata(4) driver for IDE/PATA, ATAPI, and SATA. Devices show up as ad#.
  2. If you add options ATA_CAM to your kernel config and compile a custom kernel, then a thin compat layer is added above ata(4) that allows you to use cam(4) commands (camcontrol, for example) to access your IDE/PATA and ATAPI disks. This is the "temporary migration path", and really shouldn't be used except to get used to all the cam-based management tools. I forget how devices appear, but it may be da# like other cam-based devices.
  3. Then there's the new ahci(4) (and siis(4)) driver that allows you to access SATA devices natively via the cam(4) subsystem. There's no functional difference between ahci(4) and SCSI devices. These devices show up as ada#.

Thus, if your SATA controller supports AHCI-mode, then you can use the ahci(4) driver and access it via SCSI commands, and remove the ata* devices from your kernel.

If your SATA controller does not support AHCI-mode, then you can use the options CAM_ATA and ata* drivers to access your disks via SCSI commands.

Or, you can use the normal ata* devices, and access your disks via IDE/ATAPI commands.

Eventually, down the line, ata(4) will go away, and everything will be unified under the cam(4) system.
 
Points #1 and #3 in the post above this one may explain fstab changes requiring an extra step in the buildworld cycle between v8 and v9; Not at the latter machine right now but that is the device name change(s) I recall. (ad0 > ada0 ) though in this case it was complicated by an intermediate UUID, label etc before v8 > v9 the full particulars of which I do not exactly recall.
 
Beeblebrox said:
The ada0 -> ad4 problem was fixed after I removed
Code: 
ahci_load="YES"
from loader.conf. So as you noted, ahci.ko was interfering with the STATIC setting already included into the kernel.
Click to expand...

Sticking with the old ad(4) device is costing you a little bit of speed. Static device numbering isn't worth it when labels fix the problem more effectively. See FreeBSD Labeled Filesystems and Moving A FreeBSD System To AHCI.
 
OK, thanks to both phoenix & wblock. Litlle bit of a late response because I was researching my board properties and looking into a possible BIOS upgrade, etc. To re-iterate (so that I don't make some stupid mistake) what is advised:

1. If board supports AHCI I can tweak the kernel and leave out ata with:
Code: 
device  ahci
# device    ata
# device    atadisk 
# options   ATA_STATIC_ID
At this moment, my BIOS does not give an AHCI choice (only raid) and this is the reason for errors encountered.

2. Even if board does not support AHCI, go ahead and switch to following option in kernel for a little better speed:
Code: 
device    ata
device    atadisk 
options ATA_CAM
device ahci 
# options   ATA_STATIC_ID
Any mistakes? (using zfs, so labels not needed)
 
You must log in or register to reply here.
Back
Top