Re: Summary: Re: Spin down HDD after disk sync or before power off

2010-10-21 Thread Paul Wootton 

 On 10/21/10 15:20, Dag-Erling Smørgrav wrote:

Bruce Cran  writes:

The Ubuntu issue was what I was thinking of - I got that mixed up with
the aggressive power management of the WD EARS drives.

The entire Green series, actually, which includes models such as the
EADS, AARS etc., but there's more to them than that - the central
feature is their dynamically adjusted rotational speed, which allows
them to conserve power without spinning all the way down.

DES


Actually, the green series does spin all the way down, well at least the 
drive I have does.
Here is the output from one of my drives, that I do not think has long 
left to live.


=== START OF INFORMATION SECTION ===
Model Family: Western Digital Caviar Green family
Device Model: WDC WD5000AADS-00M2B0
Serial Number:WD-WMAV51882791
Firmware Version: 01.00A01
User Capacity:500,107,862,016 bytes
Device is:In smartctl database [for details use: -P show]
ATA Version is:   8
ATA Standard is:  Exact ATA specification draft version not indicated
Local Time is:Thu Oct 21 23:31:35 2010 BST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME  FLAG VALUE WORST THRESH TYPE  
UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate 0x002f   200   200   051Pre-fail  
Always   -   0
  3 Spin_Up_Time0x0027   111   104   021Pre-fail  
Always   -   7425
  4 Start_Stop_Count0x0032   100   100   000Old_age   
Always   -   98
  5 Reallocated_Sector_Ct   0x0033   200   200   140Pre-fail  
Always   -   0
  7 Seek_Error_Rate 0x002e   100   253   000Old_age   
Always   -   0
  9 Power_On_Hours  0x0032   093   093   000Old_age   
Always   -   5295
 10 Spin_Retry_Count0x0032   100   253   000Old_age   
Always   -   0
 11 Calibration_Retry_Count 0x0032   100   253   000Old_age   
Always   -   0
 12 Power_Cycle_Count   0x0032   100   100   000Old_age   
Always   -   96
192 Power-Off_Retract_Count 0x0032   200   200   000Old_age   
Always   -   95
193 Load_Cycle_Count0x0032   001   001   000Old_age   
Always   -   781014
194 Temperature_Celsius 0x0022   120   102   000Old_age   
Always   -   27
196 Reallocated_Event_Count 0x0032   200   200   000Old_age   
Always   -   0
197 Current_Pending_Sector  0x0032   200   200   000Old_age   
Always   -   0
198 Offline_Uncorrectable   0x0030   200   200   000Old_age   
Offline  -   0
199 UDMA_CRC_Error_Count0x0032   200   200   000Old_age   
Always   -   0
200 Multi_Zone_Error_Rate   0x0008   200   200   000Old_age   
Offline  -   0



The datasheet for these drive 
http://www.wdc.com/wdproducts/library/SpecSheet/ENG/2879-701229.pdf 
says

"Reliability/Data Integrity
Load/unload cycles (3) 300,000
Limited Warranty (years) (4)
(3) Controlled unload at ambient condition
(4) The term of the limited warranty my vary by region"

Also 
http://wdc.custhelp.com/cgi-bin/wdc.cfg/php/enduser/std_adp.php?p_faqid=5357

"(drive has been validated to 1 million load/unload cycles without issue)"

Im already at 781014 load cycles, yet the drive is only about 7 months 
old. Doing the math, I am getting a load/unload cycle about every 24.5 
seconds
Another 2 months and I will be knocking on for 1 million load/unload 
cycles


As DES has already said, for most people the extra load/unload cycles 
when rebooting a computer will not be an issue at all and is far more 
desirable than an emergency park when powering down



Paul
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Deterministic builds?

2010-10-21 Thread Erik Cederstrand 

Den 21/10/2010 kl. 19.57 skrev Ulrich Spörlein:

> On Mon, 11.10.2010 at 11:35:42 +0200, Erik Cederstrand wrote:
>> 
>> I'm beginning to think that it should at least be optional. Removing e.g. 
>> build times, mtimes and path to OBJDIR or SRCDIR might not make everyone 
>> happy.
> 
> The problem with making it optional is, that we already have enough
> flags and knobs. No need in adding more.
> 
> Besides, why would people want to know the date of the build? Far more
> important is the date and state of the source for the time of build. So
> you might want to replace ${BUILDATE} with ${SRCDATE} somehow (time of
> last commit?).
> 
> Otherwise, please go for it. It would be nice if two people compiling
> GENERIC for the same source-base would get identical binaries.


It goes without saying that I agree with you on this. But it seems the feature 
will require fairly invasive changes to a standard FreeBSD, e.g. changing 
standard ar behavior, and building kernels and some other tools without 
debugging symbols. I'm not experienced enough to determine if this is fine with 
the majority of users, but hiding the changes under a knob would at least let 
the feature prove itself and put off bikeshedding for a while. If the project 
works out, we can discuss changing the default.

I'm still not sure what to do with debugging symbols. Currently absolute paths 
to source files are used. I would like to change that to absolute paths , i.e. 
usr.bin/ar/ar.c. That might even be beneficial if someone is debugging the 
binary on a system that doesn't have the source tree located in 
/some/obscure/directory/src. It's my understanding that gdb uses the path to 
look up source code related to stack traces etc. It seems gdb can handle 
relative paths, but I have no idea if it actually works, or if it's a nuisance 
to use compared to absolute paths. Any hints?

Thanks,
Erik

Re: kmod if_alc in 8-CURRENT

2010-10-21 Thread Paul B Mahol 
On 10/21/10, Matthias Apitz  wrote:
> El dia Thursday, October 21, 2010 a las 08:35:09PM +0200, Paul B Mahol
> escribio:
>
>> > # cd /usr/src
>> > # make buildkernel KERNCONF=GENERIC
>> >
>> > does not build the module if_alc.ko
>> >
>> > What I'm missing? Or what is the correct way to get this module for my
>> > kernel level?
>>
>> /sys/modules/alc
>
> Yes, thanks. I realized this some hours ago and CVS up this too, but
> the module does not get build.

Because you did not have Makefiles of higher directories.

Anyway:

# cd /sys/modules/alc && make install clean

Should do it.
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: kmod if_alc in 8-CURRENT

2010-10-21 Thread Matthias Apitz 
El día Thursday, October 21, 2010 a las 08:35:09PM +0200, Paul B Mahol escribió:

> > # cd /usr/src
> > # make buildkernel KERNCONF=GENERIC
> >
> > does not build the module if_alc.ko
> >
> > What I'm missing? Or what is the correct way to get this module for my
> > kernel level?
> 
> /sys/modules/alc

Yes, thanks. I realized this some hours ago and CVS up this too, but
the module does not get build.

matthias

-- 
Matthias Apitz
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e  - w http://www.unixarea.de/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: kmod if_alc in 8-CURRENT

2010-10-21 Thread Paul B Mahol 
On 10/21/10, Matthias Apitz  wrote:
>
> Hello,
>
> I have on my laptop a kernel based on CVS from May 2009, i.e. 8-CURRENT
> at this time.
>
> I now need support for Atheros AR813x/AR815x PCIe
> Ethernet, the kmod if_alc.ko. That's why I did:
>
> # cd /usr/src/sys/dev
> # cvs update -d -r RELENG_8_0_0_RELEASE alc
>
> and have now:
>
> # ls -l alc
> total 142
> drwxr-xr-x  2 root  wheel 512 21 oct 15:30 CVS
> -rw-r--r--  1 root  wheel  103832 21 oct 15:30 if_alc.c
> -rw-r--r--  1 root  wheel   29084 21 oct 15:30 if_alcreg.h
> -rw-r--r--  1 root  wheel8119 21 oct 15:30 if_alcvar.h
>
> but a
>
> # cd /usr/src
> # make buildkernel KERNCONF=GENERIC
>
> does not build the module if_alc.ko
>
> What I'm missing? Or what is the correct way to get this module for my
> kernel level?

/sys/modules/alc
>
> Thanks
>
>   matthias
>
> --
> Matthias Apitz
> t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
> e  - w http://www.unixarea.de/
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
>
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: a few minor kldstat fixes

2010-10-21 Thread Alexander Best 
On Thu Oct 21 10, Garrett Cooper wrote:
> On Thu, Oct 21, 2010 at 10:46 AM, Alexander Best  wrote:
> > this patch fixes the following issues:
> >
> > - unbreak 'kldstat -i 999 -v' output
> > - remove an unnecessary set of "{" and "}"
> > - change printfile() to blend into the overall style used in kldstat.c
> > - add a kldstat(8) entry to document the relationship between the "-i" and 
> > "-n" flags
> 
> Might be better to say that the -i and -n options are mutually
> exclusive in the manpage, and have the args parser parse out those two
> cases and bail if both of them are set.

i don't think the current behavior should be changed. some people might have
something like 'kldstat -i X -n Y' in their scripts expect "-n Y" to override
"-i X", instead of having kldstat fail.

> Thanks!
> -Garrett

-- 
a13x
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

kmod if_alc in 8-CURRENT

2010-10-21 Thread Matthias Apitz 

Hello,

I have on my laptop a kernel based on CVS from May 2009, i.e. 8-CURRENT
at this time. 

I now need support for Atheros AR813x/AR815x PCIe
Ethernet, the kmod if_alc.ko. That's why I did:

# cd /usr/src/sys/dev
# cvs update -d -r RELENG_8_0_0_RELEASE alc

and have now:

# ls -l alc
total 142
drwxr-xr-x  2 root  wheel 512 21 oct 15:30 CVS
-rw-r--r--  1 root  wheel  103832 21 oct 15:30 if_alc.c
-rw-r--r--  1 root  wheel   29084 21 oct 15:30 if_alcreg.h
-rw-r--r--  1 root  wheel8119 21 oct 15:30 if_alcvar.h

but a 

# cd /usr/src
# make buildkernel KERNCONF=GENERIC

does not build the module if_alc.ko

What I'm missing? Or what is the correct way to get this module for my
kernel level?

Thanks

matthias

-- 
Matthias Apitz
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e  - w http://www.unixarea.de/
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: negative permission scanner for periodic/security

2010-10-21 Thread Ulrich Spörlein 
On Thu, 14.10.2010 at 15:23:23 -0500, Brooks Davis wrote:
> One of the side effects of increasing NGROUPS_MAX is that it's possible
> for a process to be in more groups that can be transmitted over NFS
> (<4).  When that happens users are mostly denied access to things they
> should have access to.  However, permission evaluation order in unix
> means that groups can be denied access to files the world can read using
> so called negative permissions.  I've written a scanner (derived from
> 100.chksetuid) for the periodic security script to flag such files as
> they post a security risk (and nearly all the time are errors).  I've
> not bothered looking for negative user permissions as that isn't broken
> over NFS and assuming the file is not on a read-only FS the user can
> just give theselves permissions again.
> 
> One minor note: Before enabling this by default, ~6 files in the ports
> repo need fixing as they have world execute bits without user or group
> execute bits.
> 
> Should this be enabled by default?  It think so, but welcome discussion.

I'm with you, but a couple of points to note:

- Many admins won't be familiar with this problem and might not go as
far as reading the periodic manpage for an explanation. Perhaps another
paragraph could be emitted -- iff we have a hit -- that explains why
periodic is checking the permissions.

- ufs,zfs is hardcoded, can't we get this list from somewhere else? We
support NFS exports of ext2fs filesystems, right?

- Not a problem for sane setups, but somewhere out there is a machine
where the resulting list might be several MB large. We currently don't
restrict the periodic mail to a certain size, perhaps we should start
doing this to avoid mailbox/mail system overflow?

Regards,
Uli
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: a few minor kldstat fixes

2010-10-21 Thread Garrett Cooper 
On Thu, Oct 21, 2010 at 10:46 AM, Alexander Best  wrote:
> this patch fixes the following issues:
>
> - unbreak 'kldstat -i 999 -v' output
> - remove an unnecessary set of "{" and "}"
> - change printfile() to blend into the overall style used in kldstat.c
> - add a kldstat(8) entry to document the relationship between the "-i" and 
> "-n" flags

Might be better to say that the -i and -n options are mutually
exclusive in the manpage, and have the args parser parse out those two
cases and bail if both of them are set.
Thanks!
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Deterministic builds?

2010-10-21 Thread Ulrich Spörlein 
On Mon, 11.10.2010 at 11:35:42 +0200, Erik Cederstrand wrote:
> 
> Den 11/10/2010 kl. 10.47 skrev Kostik Belousov:
> >
> > My personal opinion that the feature is nice to have. Unless the changes to
> > get this working are too large, and, more importantly, unless the 
> > maintenance
> > cost of having this in good shape is too high, sure we would better have
> > deterministic build results.
> > 
> > Also, the deterministic builds require somebody who would monitor the
> > feature, either manually, or by setting some bot that automatically
> > checks it. Otherwise, I suspect, it will degrade.
> 
> I might want to adopt the task of monitoring the feature.
> 
> I'm beginning to think that it should at least be optional. Removing e.g. 
> build times, mtimes and path to OBJDIR or SRCDIR might not make everyone 
> happy.

The problem with making it optional is, that we already have enough
flags and knobs. No need in adding more.

Besides, why would people want to know the date of the build? Far more
important is the date and state of the source for the time of build. So
you might want to replace ${BUILDATE} with ${SRCDATE} somehow (time of
last commit?).

Otherwise, please go for it. It would be nice if two people compiling
GENERIC for the same source-base would get identical binaries.

Uli
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

a few minor kldstat fixes

2010-10-21 Thread Alexander Best 
this patch fixes the following issues:

- unbreak 'kldstat -i 999 -v' output
- remove an unnecessary set of "{" and "}"
- change printfile() to blend into the overall style used in kldstat.c
- add a kldstat(8) entry to document the relationship between the "-i" and "-n" 
flags

cheers.
alex

-- 
a13x
diff --git a/sbin/kldstat/kldstat.8 b/sbin/kldstat/kldstat.8
index 6f040e2..313a5c6 100644
--- a/sbin/kldstat/kldstat.8
+++ b/sbin/kldstat/kldstat.8
@@ -25,7 +25,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd September 23, 2005
+.Dd October 21, 2010
 .Dt KLDSTAT 8
 .Os
 .Sh NAME
@@ -52,7 +52,10 @@ Be more verbose.
 .It Fl i Ar id
 Display the status of only the file with this ID.
 .It Fl n Ar filename
-Display the status of only the file with this filename.
+Display the status of only the file with this filename. This will overwrite any
+previous
+.Fl i
+option.
 .It Fl q
 Only check if module is loaded or compiled into the kernel.
 .It Fl m Ar modname
diff --git a/sbin/kldstat/kldstat.c b/sbin/kldstat/kldstat.c
index 78182b9..f671c60 100644
--- a/sbin/kldstat/kldstat.c
+++ b/sbin/kldstat/kldstat.c
@@ -50,14 +50,15 @@ printmod(int modid)
printf("\t\t%2d %s\n", stat.id, stat.name);
 }
 
-static void printfile(int fileid, int verbose)
+static void
+printfile(int fileid, int verbose)
 {
 struct kld_file_stat stat;
 int modid;
 
 stat.version = sizeof(struct kld_file_stat);
 if (kldstat(fileid, &stat) < 0)
-   warn("can't stat file id %d", fileid);
+   err(1, "can't stat file id %d", fileid);
 else
printf("%2d %4d %p %-8zx %s",
   stat.id, stat.refs, stat.address, stat.size, 
@@ -144,10 +145,9 @@ main(int argc, char** argv)
return 0;
 }
 
-if (filename != NULL) {
+if (filename != NULL)
if ((fileid = kldfind(filename)) < 0)
err(1, "can't find file %s", filename);
-}
 
 printf("Id Refs Address%*c Size Name\n", POINTER_WIDTH - 7, ' ');
 if (fileid != 0)
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Summary: Re: Spin down HDD after disk sync or before power off

2010-10-21 Thread Erik Trulsson 
On Thu, Oct 21, 2010 at 05:20:54PM +0200, Dag-Erling Smørgrav wrote:
> Bruce Cran  writes:
> > The Ubuntu issue was what I was thinking of - I got that mixed up with
> > the aggressive power management of the WD EARS drives.
> 
> The entire Green series, actually, which includes models such as the
> EADS, AARS etc., but there's more to them than that - the central
> feature is their dynamically adjusted rotational speed, which allows
> them to conserve power without spinning all the way down.

They do not have any dynamically adjusted rotational speed, despite
what Western Digitals marketing department would like you to believe.

Tests by various reliable review sites have shown that all the Green
models examined so far spin at 5400RPM with no variations.
(See e.g. http://www.silentpcreview.com/article786-page2.html
or  http://www.storagereview.com/1000.sr?page=0,0  )

There could be differences in rotational speed between different models
(but no such difference has been reported yet), but they all have a
fixed RPM.



-- 

Erik Trulsson
ertr1...@student.uu.se
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Summary: Re: Spin down HDD after disk sync or before power off

2010-10-21 Thread Dag-Erling Smørgrav 
Bruce Cran  writes:
> The Ubuntu issue was what I was thinking of - I got that mixed up with
> the aggressive power management of the WD EARS drives.

The entire Green series, actually, which includes models such as the
EADS, AARS etc., but there's more to them than that - the central
feature is their dynamically adjusted rotational speed, which allows
them to conserve power without spinning all the way down.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Summary: Re: Spin down HDD after disk sync or before power off

2010-10-21 Thread Bruce Cran 
On Thu, 21 Oct 2010 16:35:06 +0200
Dag-Erling Smørgrav  wrote:

> Really?  That would make the system close to unusable, and the disk's
> life expectancy would be reduced to a few months; a disk that performs
> two load / unload cycles per minute on average will need replacing
> after three to six months.  Remember, there was a huge flap a couple
> of years when Ubuntu shipped with a default timeout of 90 seconds,
> which is more than ten times more than what you suggest.

The Ubuntu issue was what I was thinking of - I got that mixed up with
the aggressive power management of the WD EARS drives.

-- 
Bruce Cran
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Summary: Re: Spin down HDD after disk sync or before power off

2010-10-21 Thread Dag-Erling Smørgrav 
RW  writes:
> Alexander Best  wrote:
> > this seems to indicate that spinning down a disk has quite an impact.
> That's mostly likely a hang-over from older disk technologies when the
> heads touched the surface on spinning down.  

They still do, although these days the "landing zone" has a special
surface designed to minimize friction on the head and prevent it from
sticking to the surface.  In addition, in an emergency unload (when
power is lost while the disk is still spinning) the heads retract in a
violent and uncontrolled manner, which can lead to mechanical damage to
the arms.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Summary: Re: Spin down HDD after disk sync or before power off

2010-10-21 Thread Dag-Erling Smørgrav 
Alexander Best  writes:
> no need to get upset. you asked where i found the information regarding the
> wear impact of spinning down disks and i gave you the answer.

I am upset by your claim that "doing spin downs upon reboot might be
even worse than not doing spindowns upon shutdown", because you should
know better, and following your advice could damage people's hardware.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Summary: Re: Spin down HDD after disk sync or before power off

2010-10-21 Thread Dag-Erling Smørgrav 
Bruce Cran  writes:
> Do we think our users are silly enough to set a short timeout of just a
> few minutes?  I'd think most would use a setting of 20-30 minutes at
> a minimum. I never did understand why there were so many warnings;
> after all, some laptops even come with a default APM scheme in their
> HDDs that powers the disk down after 7 seconds!

Really?  That would make the system close to unusable, and the disk's
life expectancy would be reduced to a few months; a disk that performs
two load / unload cycles per minute on average will need replacing after
three to six months.  Remember, there was a huge flap a couple of years
when Ubuntu shipped with a default timeout of 90 seconds, which is more
than ten times more than what you suggest.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Summary: Re: Spin down HDD after disk sync or before power off

2010-10-21 Thread RW 
On Thu, 21 Oct 2010 12:21:10 +
Alexander Best  wrote:

 
> atacontrol(8) says that:
> 
> "You should not set a spindown timeout on a disk with / or syslog
> logging on it as the disk will be worn out spinning down and up all
> the time."
> 
> this seems to indicate that spinning down a disk has quite an impact.

That's mostly likely a hang-over from older disk technologies when the
heads touched the surface on spinning down.  
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Summary: Re: Spin down HDD after disk sync or before power off

2010-10-21 Thread Bruce Cran 
On Thu, 21 Oct 2010 13:41:14 +
Alexander Best  wrote:

> personally i still think something like the attached patch would be
> nice to have. there's a chance users might type the following:
> 
> 'atacontrol spindown device 10'
> 
> thinking the timeout value is measured in minutes. 

I agree - users coming from ataidle(8) will expect the timeout to be in
minutes too.

-- 
Bruce Cran
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Summary: Re: Spin down HDD after disk sync or before power off

2010-10-21 Thread Alexander Best 
On Thu Oct 21 10, Bruce Cran wrote:
> On Thu, 21 Oct 2010 14:33:49 +0200
> Dag-Erling Smørgrav  wrote:
> 
> > The problem with setting a short idle timeout is that, on a typical
> > laptop or desktop system, you end up spinning the disk down and back
> > up several hundred times a day, which increases power consumption, I/O
> > latency and wear.
> 
> Do we think our users are silly enough to set a short timeout of just a
> few minutes?  I'd think most would use a setting of 20-30 minutes at
> a minimum. I never did understand why there were so many warnings;
> after all, some laptops even come with a default APM scheme in their
> HDDs that powers the disk down after 7 seconds!

personally i still think something like the attached patch would be nice to
have. there's a chance users might type the following:

'atacontrol spindown device 10'

thinking the timeout value is measured in minutes. although this gets mentioned
in atacontrol(4) it might still be worth reminding the user that he/she is
performing actions which could damage the hardware.

cheers.
alex

> 
> -- 
> Bruce Cran

-- 
a13x
diff --git a/sbin/atacontrol/atacontrol.c b/sbin/atacontrol/atacontrol.c
index 4354ddf..75a131a 100644
--- a/sbin/atacontrol/atacontrol.c
+++ b/sbin/atacontrol/atacontrol.c
@@ -317,6 +317,10 @@ ata_spindown(int fd, const char *dev, const char *arg)
 
if (arg != NULL) {
tmo = strtoul(arg, NULL, 0);
+   if (tmo < 600)
+   warnx("setting spindown timeout below 10 minutes is \
+ not recommended (see EXAMPLES section of \
+ atacontrol(8))\n");
if (ioctl(fd, IOCATASSPINDOWN, &tmo) < 0)
err(1, "ioctl(IOCATASSPINDOWN)");
} else {
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Summary: Re: Spin down HDD after disk sync or before power off

2010-10-21 Thread Alexander Best 
On Thu Oct 21 10, Dag-Erling Smørgrav wrote:
> Alexander Best  writes:
> > Dag-Erling Smørgrav  writes:
> > > No.  Where did you get that idea?  To repeat what I've said before -
> > > several times - in this thread, a modern disk drive can handle hundreds
> > > of thousands of controlled unloads but only a few hundred emergency
> > > unloads. Given the choice between "never spin down" and "always spin
> > > down", the safe alternative is "always spin down".
> > atacontrol(8) says that:
> >
> > "You should not set a spindown timeout on a disk with / or syslog 
> > logging
> >  on it as the disk will be worn out spinning down and up all the time."
> >
> > this seems to indicate that spinning down a disk has quite an impact.
> 
> The problem with setting a short idle timeout is that, on a typical
> laptop or desktop system, you end up spinning the disk down and back up
> several hundred times a day, which increases power consumption, I/O
> latency and wear.
> 
> However, a single emergency unload (what happens when the disk loses
> power without first unloading the head) shortens the disk's life
> expectancy as much as hundreds or thousands of controlled unloads.
> 
> Unless you think our users commonly reboot their computers hundreds or
> thousands of times between each time they cycle the power, the safe
> alternative is to *always* spin down during shutdown.
> 
> I truly hope this is the *last* time I have to repeat this.  It's really
> not that hard to understand.

no need to get upset. you asked where i found the information regarding the
wear impact of spinning down disks and i gave you the answer.

i totally agree with you on this issue. yet again: is it worth changing this
for the ata(4) sub system which will probably become obsolete in one or two
years? the ata(4) subsytem exists since FreeBSD 4.0. why introduce this change
now that it's going to die soon?

also as i pointed out in my earlier post, spinning down disks already caused
problems with the aac controller. since not a lot of testing went into the spin
down code one can expect more controller related issues to arise.

cheers.
alex

> 
> DES
> -- 
> Dag-Erling Smørgrav - d...@des.no

-- 
a13x
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Summary: Re: Spin down HDD after disk sync or before power off

2010-10-21 Thread Bruce Cran 
On Thu, 21 Oct 2010 14:33:49 +0200
Dag-Erling Smørgrav  wrote:

> The problem with setting a short idle timeout is that, on a typical
> laptop or desktop system, you end up spinning the disk down and back
> up several hundred times a day, which increases power consumption, I/O
> latency and wear.

Do we think our users are silly enough to set a short timeout of just a
few minutes?  I'd think most would use a setting of 20-30 minutes at
a minimum. I never did understand why there were so many warnings;
after all, some laptops even come with a default APM scheme in their
HDDs that powers the disk down after 7 seconds!

-- 
Bruce Cran
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Summary: Re: Spin down HDD after disk sync or before power off

2010-10-21 Thread Dag-Erling Smørgrav 
Alexander Best  writes:
> Dag-Erling Smørgrav  writes:
> > No.  Where did you get that idea?  To repeat what I've said before -
> > several times - in this thread, a modern disk drive can handle hundreds
> > of thousands of controlled unloads but only a few hundred emergency
> > unloads. Given the choice between "never spin down" and "always spin
> > down", the safe alternative is "always spin down".
> atacontrol(8) says that:
>
> "You should not set a spindown timeout on a disk with / or syslog logging
>  on it as the disk will be worn out spinning down and up all the time."
>
> this seems to indicate that spinning down a disk has quite an impact.

The problem with setting a short idle timeout is that, on a typical
laptop or desktop system, you end up spinning the disk down and back up
several hundred times a day, which increases power consumption, I/O
latency and wear.

However, a single emergency unload (what happens when the disk loses
power without first unloading the head) shortens the disk's life
expectancy as much as hundreds or thousands of controlled unloads.

Unless you think our users commonly reboot their computers hundreds or
thousands of times between each time they cycle the power, the safe
alternative is to *always* spin down during shutdown.

I truly hope this is the *last* time I have to repeat this.  It's really
not that hard to understand.

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Summary: Re: Spin down HDD after disk sync or before power off

2010-10-21 Thread Alexander Best 
On Thu Oct 21 10, Dag-Erling Smørgrav wrote:
> Alexander Best  writes:
> > since there seems no way to distinguish between these two states in ATA(4) 
> > it's
> > probably better to leave it as it is, since doing spin downs upon reboot 
> > might
> > be even worse than not doing spindowns upon shutdown.
> 
> No.  Where did you get that idea?  To repeat what I've said before -
> several times - in this thread, a modern disk drive can handle hundreds
> of thousands of controlled unloads but only a few hundred emergency
> unloads. Given the choice between "never spin down" and "always spin
> down", the safe alternative is "always spin down".

atacontrol(8) says that:

"You should not set a spindown timeout on a disk with / or syslog logging
 on it as the disk will be worn out spinning down and up all the time."

this seems to indicate that spinning down a disk has quite an impact.

while chatting with bruce cran regarding this matter we discovered that mav@
already implemented this feature back in february, but disabled it by default
due to issues with the aac controller.

the current implementation (kern.cam.power_down) uses a singe "sleep"
operation, whereas the patch by oliver uses "flush" and "standby immediate".

unfortunately almost nobody was aware of mav's work at the time of the
discussion. would have been nice to have a note in cam(4) explaining the
purpose of kern.cam.power_down. that way a lot of double work could have been
avoided.

is the ATA(4) subsystem still being actively worked on or will it die out after
officially switching to ATA_CAM? the question is, if it is worth implementing
hdd spin down for ATA(4)?

cheers.
alex

> 
> DES
> -- 
> Dag-Erling Smørgrav - d...@des.no

-- 
a13x
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: Summary: Re: Spin down HDD after disk sync or before power off

2010-10-21 Thread Dag-Erling Smørgrav 
Alexander Best  writes:
> since there seems no way to distinguish between these two states in ATA(4) 
> it's
> probably better to leave it as it is, since doing spin downs upon reboot might
> be even worse than not doing spindowns upon shutdown.

No.  Where did you get that idea?  To repeat what I've said before -
several times - in this thread, a modern disk drive can handle hundreds
of thousands of controlled unloads but only a few hundred emergency
unloads. Given the choice between "never spin down" and "always spin
down", the safe alternative is "always spin down".

DES
-- 
Dag-Erling Smørgrav - d...@des.no
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Re: addition of sysctl nodes after compile time

2010-10-21 Thread Robert Watson 


On Tue, 19 Oct 2010, Alexander Best wrote:


does this limitation still exist?


Sysctls can be added dynamically using the sysctl_add_oid(9) KPI, which has 
existed (as far as I'm aware) at least since FreeBSD 4.x.  It could be that 
this KPI provides the functionality required to do what the comment describes.


Robert
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"