From: Antonio E. L. <ant...@on...> - 2009-12-31 08:24:40
|
When I make a configuration for smartd which employs the -n flag (that means not to query sleeping/standby disks which would cause them to spin up) the sleeping disk is spun up regardless of this setting. It also occurs using smartctl witn n directive. Reproducible: Always ubuntu: smartmontools 5.38 and 5.39. Also reported by others (see http://bugs.gentoo.org/224469 ) ******* Steps ******* Aggressive sda powersave setup (only for testing) sbin/hdparm -B 1 -S 1 -M 128 /dev/sda After five seconds drive is in standby state Partitions with noatime option and only backup data on it (no OS processes running against it) . If smartd is running with smartd_opts="--interval=120" (only for testing), each two minutes (exactly) harddisk spins up and go standby in 5 seconds as expected. If I use the -n standby option only (I mean, without q) daemons log message appears the first attempt (Device is in STANDBY ), but it spins up also. No more messages until I make sbin/hdparm -B 1 -S 60 -M 128 /dev/sda (five minutes until standby mode). Then I see the Device is running, resumed delayed checks (I cannot remember) message. If smartd is not running, the disk is in standby state during hours (only wakes up during short time periods, once a day, for backups). Checked both behaviors during long time periods with a loop script using hdparm -C. cat /etc/smartd.conf /dev/sda -n standby,23,q -o off -S on -H \ -s (S/../../[1-4]/07|L/../../5/07) \ -m my@email \ -M exec /usr/local/bin/smartd.sh \ -W 4,50,55 -a Tested also with cat /etc/smartd.conf /dev/sda -n standby Nice tools btw. I will use a cron script to emulate smartd daemon, using hdparm to check disk state and smartcl for different tasks. |
From: Christian F. <Chr...@t-...> - 2009-12-31 16:58:37
|
Antonio Expósito Lorenzo wrote: > When I make a configuration for smartd which employs the -n flag > (that means not to query sleeping/standby disks which would cause them > to spin up) the sleeping disk is spun up regardless of this setting. It also > occurs using smartctl witn –n directive. > > Reproducible: Always > > ubuntu: smartmontools 5.38 and 5.39. Also reported by others (see > http://bugs.gentoo.org/224469 ) > > Please open a new ticket if possible: https://sourceforge.net/apps/trac/smartmontools/newticket > ******* > Steps > ******* > > Aggressive sda powersave setup (only for testing) > > sbin/hdparm -B 1 -S 1 -M 128 /dev/sda > > After five seconds drive is in standby state > > A five seconds interval may produce misleading test results: smartd rechecks the power state after 5 seconds to detect whether the check itself spins up the disk. > Partitions with noatime option and only backup data on it (no OS processes > running against it) . > > If smartd is running with smartd_opts="--interval=120" (only for testing), > each two minutes (exactly) harddisk spins up and go standby in 5 seconds as > expected. If I use the -n standby option only (I mean, without q) daemons > log message appears the first attempt (Device is in STANDBY…), but it spins > up also. No more messages until I make sbin/hdparm -B 1 -S 60 -M 128 > /dev/sda (five minutes until standby mode). Then I see the “Device is > running, resumed delayed checks (I cannot remember)” message. > > Did smartd log "CHECK POWER STATUS spins up disk" ? > If smartd is not running, the disk is in standby state during hours (only > wakes up during short time periods, once a day, for backups). > > Checked both behaviors during long time periods with a loop script using > hdparm -C. > > smartctl/smartd -n option/directive essentially do the same as hdparm -C: Test the result of ATA CHECK POWER MODE command (0xe5). Additional device type autodetection steps during *first* open may wakeup the device. This can be prevented by specifying the correct device type. Start or reload of smartd will likely wakeup the device due to some capability checks done during initialization. Could you please test the following: # hdparm -y /dev/ice # sleep 20 # hdparm -C /dev/ice # sleep 20 # hdparm -C /dev/ice # sleep 20 # smartctl -n standby -i /dev/ice # hdparm -C /dev/ice # sleep 20 # hdparm -C /dev/ice If smartctl wakes up the device, try to add the device type: '-d sat' for SATA devices on Linux, else '-d ata'. 'smartctl -d test /dev/ice' can be used to print autodetection result. > Nice tools btw. > > Thanks, Christian |
From: Antonio E. L. <ant...@on...> - 2010-01-03 13:09:43
|
Hi Christian, First of all, happy new year (we love informatics, hardware and automatisms, but we are humans, :-) ) I have made a lot of testing, and I can assure you that I am almost completely sure that something is wrong here (perhaps it isn't smartmontools, but something is wrong). Here you have the results of the test that you proposed: user@host:~$ sudo hdparm -y /dev/sda; sleep 20 ; sudo hdparm -C /dev/sda ; sleep 20 ; sudo hdparm -C /dev/sda ; sleep 20 ; sudo smartctl -d sat -n standby -i /dev/sda; sudo hdparm -C /dev/sda ; sleep 20 ; sudo hdparm -C /dev/sda /dev/sda: issuing standby command /dev/sda: drive state is: standby /dev/sda: drive state is: standby smartctl 5.39 2009-12-09 r2995 [i686-pc-linux-gnu] (local build) Copyright (C) 2002-9 by Bruce Allen, http://smartmontools.sourceforge.net Device is in STANDBY mode, exit(2) /dev/sda: drive state is: standby /dev/sda: drive state is: active/idle I have repeated it three times with the same results. I think that smartmontools is awaking the device.... Let me know how to help with more testing or whatever you need, regards, Antonio -----Mensaje original----- De: Christian Franke [mailto:Chr...@t-...] Enviado el: jueves, 31 de diciembre de 2009 17:58 Para: Antonio Expósito Lorenzo CC: sma...@li... Asunto: Re: [smartmontools-support] Smartd/smartctl spin up drive (-n directive versions 5.38 and 5.39) Antonio Expósito Lorenzo wrote: > When I make a configuration for smartd which employs the -n flag > (that means not to query sleeping/standby disks which would cause them > to spin up) the sleeping disk is spun up regardless of this setting. It also > occurs using smartctl witn n directive. > > Reproducible: Always > > ubuntu: smartmontools 5.38 and 5.39. Also reported by others (see > http://bugs.gentoo.org/224469 ) > > Please open a new ticket if possible: https://sourceforge.net/apps/trac/smartmontools/newticket > ******* > Steps > ******* > > Aggressive sda powersave setup (only for testing) > > sbin/hdparm -B 1 -S 1 -M 128 /dev/sda > > After five seconds drive is in standby state > > A five seconds interval may produce misleading test results: smartd rechecks the power state after 5 seconds to detect whether the check itself spins up the disk. > Partitions with noatime option and only backup data on it (no OS processes > running against it) . > > If smartd is running with smartd_opts="--interval=120" (only for testing), > each two minutes (exactly) harddisk spins up and go standby in 5 seconds as > expected. If I use the -n standby option only (I mean, without q) daemons > log message appears the first attempt (Device is in STANDBY ), but it spins > up also. No more messages until I make sbin/hdparm -B 1 -S 60 -M 128 > /dev/sda (five minutes until standby mode). Then I see the Device is > running, resumed delayed checks (I cannot remember) message. > > Did smartd log "CHECK POWER STATUS spins up disk" ? > If smartd is not running, the disk is in standby state during hours (only > wakes up during short time periods, once a day, for backups). > > Checked both behaviors during long time periods with a loop script using > hdparm -C. > > smartctl/smartd -n option/directive essentially do the same as hdparm -C: Test the result of ATA CHECK POWER MODE command (0xe5). Additional device type autodetection steps during *first* open may wakeup the device. This can be prevented by specifying the correct device type. Start or reload of smartd will likely wakeup the device due to some capability checks done during initialization. Could you please test the following: # hdparm -y /dev/ice # sleep 20 # hdparm -C /dev/ice # sleep 20 # hdparm -C /dev/ice # sleep 20 # smartctl -n standby -i /dev/ice # hdparm -C /dev/ice # sleep 20 # hdparm -C /dev/ice If smartctl wakes up the device, try to add the device type: '-d sat' for SATA devices on Linux, else '-d ata'. 'smartctl -d test /dev/ice' can be used to print autodetection result. > Nice tools btw. > > Thanks, Christian |
From: Christian F. <Chr...@t-...> - 2010-01-03 13:52:04
|
Hi Antonio, > First of all, happy new year (we love informatics, hardware and automatisms, > but we are humans, :-) ) > > Of course :-) Happy new year ! > Here you have the results of the test that you proposed: > > user@host:~$ sudo hdparm -y /dev/sda; sleep 20 ; sudo hdparm -C /dev/sda ; > sleep 20 ; sudo hdparm -C /dev/sda ; sleep 20 ; sudo smartctl -d sat -n > standby -i /dev/sda; sudo hdparm -C /dev/sda ; sleep 20 ; sudo hdparm -C > /dev/sda > > /dev/sda: > issuing standby command > > /dev/sda: > drive state is: standby > > /dev/sda: > drive state is: standby > smartctl 5.39 2009-12-09 r2995 [i686-pc-linux-gnu] (local build) > Copyright (C) 2002-9 by Bruce Allen, http://smartmontools.sourceforge.net > > Device is in STANDBY mode, exit(2) > > /dev/sda: > drive state is: standby > > /dev/sda: > drive state is: active/idle > > > I have repeated it three times with the same results. I think that > smartmontools is awaking the device.... > > Yes. Hmm... When '-d TYPE' is specified, there should be no difference between 'hdparm -C' and 'smartctl -n standby'. Debug output may help. Could you please post (as attachment) the result of the following commands: # hdparm -y /dev/sda # sleep 20 # hdparm --verbose -C /dev/sda # smartctl -r ioctl,2 -n standby -i /dev/sda Thanks, Christian |
From: Antonio E. L. <ant...@on...> - 2010-01-03 14:25:33
Attachments:
smarttest.txt
|
Here you have. Thanks, Antonio -----Mensaje original----- De: Christian Franke [mailto:Chr...@t-...] Enviado el: domingo, 03 de enero de 2010 14:52 Para: Antonio Expósito Lorenzo CC: sma...@li... Asunto: Re: [smartmontools-support] Smartd/smartctl spin up drive (-n directive versions 5.38 and 5.39) Hi Antonio, > First of all, happy new year (we love informatics, hardware and automatisms, > but we are humans, :-) ) > > Of course :-) Happy new year ! > Here you have the results of the test that you proposed: > > user@host:~$ sudo hdparm -y /dev/sda; sleep 20 ; sudo hdparm -C /dev/sda ; > sleep 20 ; sudo hdparm -C /dev/sda ; sleep 20 ; sudo smartctl -d sat -n > standby -i /dev/sda; sudo hdparm -C /dev/sda ; sleep 20 ; sudo hdparm -C > /dev/sda > > /dev/sda: > issuing standby command > > /dev/sda: > drive state is: standby > > /dev/sda: > drive state is: standby > smartctl 5.39 2009-12-09 r2995 [i686-pc-linux-gnu] (local build) > Copyright (C) 2002-9 by Bruce Allen, http://smartmontools.sourceforge.net > > Device is in STANDBY mode, exit(2) > > /dev/sda: > drive state is: standby > > /dev/sda: > drive state is: active/idle > > > I have repeated it three times with the same results. I think that > smartmontools is awaking the device.... > > Yes. Hmm... When '-d TYPE' is specified, there should be no difference between 'hdparm -C' and 'smartctl -n standby'. Debug output may help. Could you please post (as attachment) the result of the following commands: # hdparm -y /dev/sda # sleep 20 # hdparm --verbose -C /dev/sda # smartctl -r ioctl,2 -n standby -i /dev/sda Thanks, Christian |
From: Christian F. <Chr...@t-...> - 2010-01-03 14:33:23
|
Antonio Expósito Lorenzo wrote: > Here you have. > > Thanks. Unfortunately I forgot to add the '-d sat' to prevent the ATA IDENTIFY command. Please retry: # hdparm -y /dev/sda # sleep 20 # hdparm --verbose -C /dev/sda # smartctl -r ioctl,2 -d sat -n standby -i /dev/sda and check whether this wakes up the drive. Thanks, Christian |
From: Antonio E. L. <ant...@on...> - 2010-01-03 15:02:14
Attachments:
smarttest.txt
|
It's OK, it was my fault. Second try attached. Antonio |
From: Christian F. <Chr...@t-...> - 2010-01-03 16:02:42
|
Antonio Expósito Lorenzo wrote: > It's OK, it was my fault. Second try attached. > > Thanks. Both hdparm and smartctl only issue one command to the drive. There is a small difference in the SAT ATA PASS-THROUGH(16) command issued: hdparm: 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00 smartctl: 85 06 2c 00 00 00 00 00 00 00 00 00 00 00 e5 00 cdb[2] hdparm: CK_COND=1, T_DIR=0, BYTE_BLOCK=0, T_LENGTH=0 cdb[2] smartctl: CK_COND=1, T_DIR=1, BYTE_BLOCK=1, T_LENGTH=0 T_DIR and BYTE_BLOCK should be ignored if T_LENGTH=0, so this should not matter. cdb[13]: hdparm: device register N/A=1 cdb[13]: smartctl: device register N/A=0 This bit is not used for this ATA command. Doug: Is the T_DIR difference possibly the reason why smartctl wakes up the disk on Linux but hdparm doesn't ? Cheers, Christian |
From: Douglas G. <dgi...@in...> - 2010-01-03 16:31:25
|
Christian Franke wrote: > Antonio Expósito Lorenzo wrote: >> It's OK, it was my fault. Second try attached. >> >> > > Thanks. > > Both hdparm and smartctl only issue one command to the drive. There is a > small difference in the SAT ATA PASS-THROUGH(16) command issued: > > hdparm: 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00 > smartctl: 85 06 2c 00 00 00 00 00 00 00 00 00 00 00 e5 00 > > cdb[2] hdparm: CK_COND=1, T_DIR=0, BYTE_BLOCK=0, T_LENGTH=0 > cdb[2] smartctl: CK_COND=1, T_DIR=1, BYTE_BLOCK=1, T_LENGTH=0 > > T_DIR and BYTE_BLOCK should be ignored if T_LENGTH=0, so this should not > matter. > > > cdb[13]: hdparm: device register N/A=1 > cdb[13]: smartctl: device register N/A=0 > > This bit is not used for this ATA command. > > Doug: Is the T_DIR difference possibly the reason why smartctl wakes up > the disk on Linux but hdparm doesn't ? Christian, Mark Lord is the expert in the ATA command field so I'm happy to copy whatever he does (and he copied the SAT framework from me). Also strange is why bit 6 in the "device field" cdb[13] is set. For the CHECK POWER MODE (non data) ATA command (E5h) that device field bit is defined as "N/A" (ref: d2015r2 from t13.org) . So we should try clearing T_DIR and BYTE_BLOCK in that situation to see if it stops the nuisance wake up. Doug Gilbert |
From: Christian F. <Chr...@t-...> - 2010-01-03 17:10:04
Attachments:
scsiata-t_dir.patch
|
Douglas Gilbert wrote: > Christian Franke wrote: >> >> Both hdparm and smartctl only issue one command to the drive. There >> is a small difference in the SAT ATA PASS-THROUGH(16) command issued: >> >> hdparm: 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00 >> smartctl: 85 06 2c 00 00 00 00 00 00 00 00 00 00 00 e5 00 >> >> cdb[2] hdparm: CK_COND=1, T_DIR=0, BYTE_BLOCK=0, T_LENGTH=0 >> cdb[2] smartctl: CK_COND=1, T_DIR=1, BYTE_BLOCK=1, T_LENGTH=0 >> >> T_DIR and BYTE_BLOCK should be ignored if T_LENGTH=0, so this should >> not matter. >> >> >> cdb[13]: hdparm: device register N/A=1 >> cdb[13]: smartctl: device register N/A=0 >> >> This bit is not used for this ATA command. >> >> Doug: Is the T_DIR difference possibly the reason why smartctl wakes >> up the disk on Linux but hdparm doesn't ? > > Christian, > Mark Lord is the expert in the ATA command field so I'm happy > to copy whatever he does (and he copied the SAT framework > from me). Also strange is why bit 6 in the "device field" > cdb[13] is set. For the CHECK POWER MODE (non data) ATA command > (E5h) that device field bit is defined as "N/A" (ref: d2015r2 > from t13.org) . > In the ATA READ/WRITE commands, this bit is used to select LBA mode. It is unused by most other commands. That's probably why hdparm always sets this bit. > So we should try clearing T_DIR and BYTE_BLOCK in that situation > to see if it stops the nuisance wake up. > Yes. Antonio: Could you please test attached patch. It should also apply to 5.39 tarball. Thanks, Christian |
From: Christian F. <Chr...@t-...> - 2010-01-23 20:00:04
Attachments:
scsiata-t_dir.patch
|
Christian Franke wrote: > Douglas Gilbert wrote: >> Christian Franke wrote: >>> >>> Both hdparm and smartctl only issue one command to the drive. There >>> is a small difference in the SAT ATA PASS-THROUGH(16) command issued: >>> >>> hdparm: 85 06 20 00 00 00 00 00 00 00 00 00 00 40 e5 00 >>> smartctl: 85 06 2c 00 00 00 00 00 00 00 00 00 00 00 e5 00 >>> >>> cdb[2] hdparm: CK_COND=1, T_DIR=0, BYTE_BLOCK=0, T_LENGTH=0 >>> cdb[2] smartctl: CK_COND=1, T_DIR=1, BYTE_BLOCK=1, T_LENGTH=0 >>> > >> So we should try clearing T_DIR and BYTE_BLOCK in that situation >> to see if it stops the nuisance wake up. >> > > Yes. > > Antonio: Could you please test attached patch. It should also apply to > 5.39 tarball. > Any chance to get the patch tested soon ? If it works, we could include it in 5.39.1 bugfix-only release. http://sourceforge.net/apps/trac/smartmontools/ticket/37 Cheers, Christian |
From: Douglas G. <dgi...@in...> - 2010-01-27 04:25:44
|
Christian Franke wrote: > Douglas Gilbert wrote: >> Christian Franke wrote: >>> Hi, >>> >>> thanks to Antonio who tested several of my patches, we found the root >>> of the problem: >>> >>> hdparm opens the device with O_RDONLY >>> smartctl opens the device with O_RDWR I suspect the above conclusion is a co-incidence rather than are the (only) cause. Could you a) try using O_RDONLY for smartctl in the test system and see if it works without a spin-up b) find a code path in the linux kernel to demonstrate why it works without a spin-up I have looked at b) and the sd_open() in drivers/scsi/sd.c (in lk 2.6.32) only has one dependency on a sd device being opened with write permissions: /* * If the device has the write protect tab set, have the open fail * if the user expects to be able to write to the thing. */ retval = -EROFS; if (sdkp->write_prot && (mode & FMODE_WRITE)) goto error_out; That says if the device (i.e. disk) flags itself as read only (possible but rare with SCSI disks) then an attempt to open with write permissions will fail with errno==EROFS . In that case the device must be opened O_RDONLY. So that is not our case. And I see no other cases which depend on FMODE_WRITE and thus no reason why SYNCHRONIZE CACHE would or would not be called depending on the setting of the write permissions on the open. >>> Interestingly the latter wakes up the drive. >>> >>> Does Linux probably send some extra command when an raw device opened >>> for writing is closed ? >>> Is the R/W mode necessary for SCSI pass through ? >> >> Christian, >> What do you mean by "raw device" >> - /dev/sdb, or >> - /dev/sg3 (for example) ? >> > > /dev/sdb > > >> In linux SCSI generic devices need to be opened O_RDWR >> to send commands unless the command is known to be safe >> (and is pretty common), for example, INQUIRY and MODE >> SENSE. A minimum of command filtering is done and all >> uses of the SCSI ATA PASS-THROUGH commands need O_RDWR. >> > > This is apparently not the case for /dev/sdX, at least with ATA_12/16 > commands. Otherwise hdparm would not work. > > I tested 'smartctl -d sat -x /dev/sda' with an older kernel (2.6.20). > There is no difference between O_RDONLY and O_RDWR. > > >> As for the sd driver, it is not clear to me. There is >> definitely code to do a SYNCHRONIZE CACHE command on >> close if it thinks the device has its Write Cache Enabled >> (WCE). Since that is a property of the disk the block >> layer (which receives the open() from the user space) >> could clear WCE if the device was opened O_RDONLY. >> > > SCSI SYNCHRONIZE CACHE is likely mapped to ATA FLUSH CACHE > (http://lxr.linux.no/#linux+v2.6.32/drivers/ata/libata-scsi.c#L2923) > which may wakeup the device. ... but as I pointed out above I can find no mechanism linking write permissions on an open() with the invocation of this command. Doug Gilbert |
From: Christian F. <Chr...@t-...> - 2010-01-27 22:21:48
|
Douglas Gilbert wrote: > Christian Franke wrote: > >> Douglas Gilbert wrote: >> >>> Christian Franke wrote: >>> >>>> Hi, >>>> >>>> thanks to Antonio who tested several of my patches, we found the root >>>> of the problem: >>>> >>>> hdparm opens the device with O_RDONLY >>>> smartctl opens the device with O_RDWR >>>> > I suspect the above conclusion is a co-incidence rather > than are the (only) cause. > > Could you > a) try using O_RDONLY for smartctl in the test system > and see if it works without a spin-up > Test with kernel 2.6.31 and smartmontools 5.39 release version: # hdparm -y /dev/sda ## This does not spin-up the drive # hdparm -C /dev/sda ... ## This does spin-up the drive # smartctl -d sat -n standby -i /dev/sda ... Device is in STANDBY mode, exit(2) I added some test messages: The spin-up definitely occurs when close() was called! With O_RDONLY, the spin-up does not occur. > b) find a code path in the linux kernel to demonstrate > why it works without a spin-up > Nothing found yet, sorry. We should probably fix it now and explain it later :-) If there are no objections, I will commit & merge the fix tomorrow - 5.39.1 is IMO ready for release then. Cheers, Christian |
From: Douglas G. <dgi...@in...> - 2010-01-27 22:55:31
|
Christian Franke wrote: > Douglas Gilbert wrote: >> Christian Franke wrote: >> >>> Douglas Gilbert wrote: >>> >>>> Christian Franke wrote: >>>> >>>>> Hi, >>>>> >>>>> thanks to Antonio who tested several of my patches, we found the root >>>>> of the problem: >>>>> >>>>> hdparm opens the device with O_RDONLY >>>>> smartctl opens the device with O_RDWR >>>>> >> I suspect the above conclusion is a co-incidence rather >> than are the (only) cause. >> >> Could you >> a) try using O_RDONLY for smartctl in the test system >> and see if it works without a spin-up >> > > Test with kernel 2.6.31 and smartmontools 5.39 release version: > > # hdparm -y /dev/sda > > ## This does not spin-up the drive > # hdparm -C /dev/sda > ... > > ## This does spin-up the drive > # smartctl -d sat -n standby -i /dev/sda > ... > Device is in STANDBY mode, exit(2) > > > > I added some test messages: > The spin-up definitely occurs when close() was called! > > With O_RDONLY, the spin-up does not occur. > > >> b) find a code path in the linux kernel to demonstrate >> why it works without a spin-up >> > > Nothing found yet, sorry. > > We should probably fix it now and explain it later :-) > > If there are no objections, I will commit & merge the fix tomorrow - > 5.39.1 is IMO ready for release then. Great. Thanks for testing that. Please go ahead (unless someone objects). Doug Gilbert |
From: Christian F. <Chr...@t-...> - 2010-01-28 22:47:47
|
Douglas Gilbert wrote: > Christian Franke wrote: >> ... >> The spin-up definitely occurs when close() was called! >> >> With O_RDONLY, the spin-up does not occur. >> >> >>> b) find a code path in the linux kernel to demonstrate >>> why it works without a spin-up >> >> Nothing found yet, sorry. >> >> We should probably fix it now and explain it later :-) >> >> If there are no objections, I will commit & merge the fix tomorrow - >> 5.39.1 is IMO ready for release then. > > Great. Thanks for testing that. > Please go ahead (unless someone objects). > Fixed and 5.39.1 released. Another quick test shows that no pass-through call is needed. This also spins up the drive: close( open("/dev/sda", O_RDWR) ); Cheers, Christian |
From: Christian F. <Chr...@t-...> - 2010-01-25 22:42:19
|
Hi, thanks to Antonio who tested several of my patches, we found the root of the problem: hdparm opens the device with O_RDONLY smartctl opens the device with O_RDWR Interestingly the latter wakes up the drive. Does Linux probably send some extra command when an raw device opened for writing is closed ? Is the R/W mode necessary for SCSI pass through ? Cheers, Christian |
From: Douglas G. <dgi...@in...> - 2010-01-26 04:49:54
|
Christian Franke wrote: > Hi, > > thanks to Antonio who tested several of my patches, we found the root of > the problem: > > hdparm opens the device with O_RDONLY > smartctl opens the device with O_RDWR > > Interestingly the latter wakes up the drive. > > Does Linux probably send some extra command when an raw device opened > for writing is closed ? > Is the R/W mode necessary for SCSI pass through ? Christian, What do you mean by "raw device" - /dev/sdb, or - /dev/sg3 (for example) ? In linux SCSI generic devices need to be opened O_RDWR to send commands unless the command is known to be safe (and is pretty common), for example, INQUIRY and MODE SENSE. A minimum of command filtering is done and all uses of the SCSI ATA PASS-THROUGH commands need O_RDWR. As for the sd driver, it is not clear to me. There is definitely code to do a SYNCHRONIZE CACHE command on close if it thinks the device has its Write Cache Enabled (WCE). Since that is a property of the disk the block layer (which receives the open() from the user space) could clear WCE if the device was opened O_RDONLY. So try open("/dev/sd<x>", O_RDONLY) and see what happens. You will soon find out if that is insufficient privilege. Doug Gilbert |
From: Christian F. <Chr...@t-...> - 2010-01-26 06:58:20
|
Douglas Gilbert wrote: > Christian Franke wrote: >> Hi, >> >> thanks to Antonio who tested several of my patches, we found the root >> of the problem: >> >> hdparm opens the device with O_RDONLY >> smartctl opens the device with O_RDWR >> >> Interestingly the latter wakes up the drive. >> >> Does Linux probably send some extra command when an raw device opened >> for writing is closed ? >> Is the R/W mode necessary for SCSI pass through ? > > Christian, > What do you mean by "raw device" > - /dev/sdb, or > - /dev/sg3 (for example) ? > /dev/sdb > In linux SCSI generic devices need to be opened O_RDWR > to send commands unless the command is known to be safe > (and is pretty common), for example, INQUIRY and MODE > SENSE. A minimum of command filtering is done and all > uses of the SCSI ATA PASS-THROUGH commands need O_RDWR. > This is apparently not the case for /dev/sdX, at least with ATA_12/16 commands. Otherwise hdparm would not work. I tested 'smartctl -d sat -x /dev/sda' with an older kernel (2.6.20). There is no difference between O_RDONLY and O_RDWR. > As for the sd driver, it is not clear to me. There is > definitely code to do a SYNCHRONIZE CACHE command on > close if it thinks the device has its Write Cache Enabled > (WCE). Since that is a property of the disk the block > layer (which receives the open() from the user space) > could clear WCE if the device was opened O_RDONLY. > SCSI SYNCHRONIZE CACHE is likely mapped to ATA FLUSH CACHE (http://lxr.linux.no/#linux+v2.6.32/drivers/ata/libata-scsi.c#L2923) which may wakeup the device. Cheers, Christian |