| View previous topic :: View next topic |
| Author |
Message |
tld
Veteran
Joined: 09 Dec 2003
Posts: 1850
|
 Posted: Tue May 26, 2009 5:06 pm Post subject: Switch to all libata: hdparm and lvm2 questions |
 |
|
I'm looking into going with all libata drivers when I upgrade to 2.6.28. As I understand it, all IDE drive devices that were names hd* become sd*, and cdroms that were hd* become sr*.
I understand most things I'd have to address: a) possible changes to /etc/udev/rules.d/70-persistent-cd.rules if I want a /dev/dvd link etc, b) changing /etc/fstab device names where needed, c) changing paths in grub.conf from (for example) root=/dev/hda3 to root=/dev/sda3.
Two things are confusing me however.
First of all, the comments in /etc/conf.d/hdparm:
| Code: | # You can either set hdparm arguments for each drive using hdX_args,
# discX_args, cdromX_args and genericX_args, e.g.
#
# hda_args="-d1 -X66"
# disc1_args="-d1"
# cdrom0_args="-d1"
|
...aren't clear as to exactly what they're expecting. Will that work with "sda_args=..." or "sr0_args=..."? Currently, my MythTV frontend is already using SATA drives, but the DVD is using IDE at /dev/hda. On that machine all I want is to add -c1 to the DVD drive, and I'm not clear how to do it when it becomes /dev/sr0.
Second of all, my MythTV backend is using IDE drives, currently /dev/hda and /dev/hdb, with /boot at /dev/hda1, swap on /dev/hda2, / on /dev/hda3, and an lvm2 volumes spanning /dev/hda4 and /dev/hdb1 (the entire hdb drive). The non-lvm partitions of course, simply need to be corrected in /etc/fstab.
Will the logical volumes listed in my /etc/fstab (/dev/vg/whatever) simply be found my lvm2 and mounted?
Thanks in advance.
Tom |
|
| Back to top |
|
 |
tld
Veteran
Joined: 09 Dec 2003
Posts: 1850
|
| Posted: Tue May 26, 2009 5:41 pm Post subject: |
|
|
I decided to test the libata cdrom functionality one of my machines using my existing kernel. One thing I discovered was that "-c1" (32 bit IO) isn't supported with libata in 2.6.27. Is this supported in 2.6.28? I can't seem to find an answer to that anywhere.
In any case, I simply can't find any way of setting /etc/conf.d/hdparm to even attempt do anything with /dev/sr0. What am I missing there?
Tom |
|
| Back to top |
|
|
energyman76b
Advocate
Joined: 26 Mar 2003
Posts: 2048
Location: Germany
|
| Posted: Wed May 27, 2009 6:11 am Post subject: |
|
|
you don't.
There is no need to pass anything with hdparm (and haven't been for a long time).
32bit support never really was that important (ever since isa days) and wasn't implemented in libata. It probably never will and there is no loss.
So nothing to set there.
DMA is in the highest supported mode anyway whenever you are using the chipset driver (and not generic) so nothing to set either.
The only thing you might want to play with is -m and even that is usually set to the optimum value anyway or -M if you want to play around with that. 32bit can not be set, dma is the fastest mode possible. You can pretty much leave that file empty.
_________________
Study finds stunning lack of racial, gender, and economic diversity among middle-class white males
I identify as a dirty penismensch. |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1850
|
| Posted: Wed May 27, 2009 10:47 am Post subject: |
|
|
Thanks for the reply. Yea, that's what I've been hearing...that clears a lot up.
Is there even any reason to have the hdparm service active? I'd assume that all the settings are just made by the kernel.
Tom |
|
| Back to top |
|
|
energyman76b
Advocate
Joined: 26 Mar 2003
Posts: 2048
Location: Germany
|
| Posted: Wed May 27, 2009 11:00 am Post subject: |
|
|
if you don't need to set M or m there is no need for hdparm with libata.
_________________
Study finds stunning lack of racial, gender, and economic diversity among middle-class white males
I identify as a dirty penismensch. |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1850
|
| Posted: Sun May 31, 2009 5:21 pm Post subject: |
|
|
I've made the switch with one of my machines (IDE only Dell 8250). It looks like -m isn't supported, at least not in 2.6.28-gentoo-r5:
| Code: | hdparm -m 16 /dev/sdb
/dev/sdb:
setting multcount to 16
HDIO_SET_MULTCOUNT failed: Inappropriate ioctl for device
HDIO_GET_MULTCOUNT failed: Inappropriate ioctl for device
|
The hdparm query doesn't show this field, so I can only assume that the kernel is setting it optimally(??):
| Code: | hdparm -v /dev/sdb
/dev/sdb:
IO_support = 0 (default)
readonly = 0 (off)
readahead = 256 (on)
geometry = 14593/255/63, sectors = 234441648, start = 0 |
Tom |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1850
|
| Posted: Sun May 31, 2009 8:49 pm Post subject: |
|
|
I just tried 'hdparm -I' on the drives and appears the multiple sector transfer has been set to 8 by the kernel.
All in all, things on this machine using libata seem to be running just great.
Tom |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1850
|
| Posted: Tue Jun 02, 2009 4:19 pm Post subject: |
|
|
Just thought I'd add this: I made the switch on my MythTV backend machine, which was the one I was most concerned about due to all the disk IO. I was a little concerned that the old IDE driver defaulted the "multiple sector I/O" to 16 out the max of 16, while libata defaulted to 8 and doesn't support changing that via hdparm -m.
I just torture tested it and there's no question in my mind that it's way more dependable with the new libata drivers at the default settings chosen by the kernel. I tried recording three HD shows while watching a fourth previously recorded HD show, and when that worked great, I added two commercial flagging jobs to the backend...it hummed along flawlessly. With the 2.6.27 kernel and the old IDE drivers, adding those commercial flagging jobs would have been enough to cause occasional IOBOUND errors in mythbackend and even occasional corruption in recordings.
Gotta love when the old "if it ain't broke don't fix it" argument gets debunked like that  .
Tom |
|
| Back to top |
|
|
|
Kernel & Hardware
