Hi Keith,
> On Fri, 18 Feb 2011 18:55:27 +, ra...@inputplus.co.uk said:
> > Easier, true, but I wanted more accuracy that /usr/bin/time or
> > bash's time would give. :-)
>
> Bash's 'time' command resolves to thousandths of a second.
This is true. Guess I'm not used to it over the old-sch
On Fri, 18 Feb 2011 18:55:27 +, ra...@inputplus.co.uk said:
> Easier, true, but I wanted more accuracy that /usr/bin/time or bash's
> time would give. :-)
Bash's 'time' command resolves to thousandths of a second. I would imagine
that saccadic suppression would make more accurate measurement
Hi Keith,
> > $ sudo true; foo; sudo fdisk -l /dev/sdb >$N; foo
> > 31.142709016
> > 35.482519853
>
> Next time:
>
> $ time sudo fdisk -l /dev/sdb
>
> Much easier!
Easier, true, but I wanted more accuracy that /usr/bin/time or bash's
time would give. :-)
Cheers,
Ralph.
-
On Fri, 18 Feb 2011 12:39:37 +, ra...@inputplus.co.uk said:
> $ foo() { date +%S.%N; }
> $ sudo true; foo; sudo fdisk -l /dev/sdb >$N; foo
> 31.142709016
> 35.482519853
> $ e 35.482519853 - 31.142709016
> 4.339810837
> $
Next time:
$ time sudo fdisk -l /de
On Friday, February 18, 2011 02:27:43 pm jr wrote:
> On 18 February 2011 14:09, Andrew Reid Paterson
>
> wrote:
> > So, I will now wait & see what haappens.
>
> those settings (probably) won't survive a reboot, you might want to
> add a small script to your system start.
Funny you should say th
On 18 February 2011 14:09, Andrew Reid Paterson
wrote:
>
> So, I will now wait & see what haappens.
those settings (probably) won't survive a reboot, you might want to
add a small script to your system start.
--
regards, jr.
time flies like an arrow, fruit flies like a banana.
--
Next meeting
On Friday, February 18, 2011 12:39:37 pm Ralph Corderoy wrote:
> Hi Andrew,
>
> > What kind of spin-up times do you think are normal for a modern
> > hard-drive then?
>
> Second or two? Purely from very limited experience. Have just timed
> this very old 20GB PATA drive.
>
> $ foo() { date
On Friday, February 18, 2011 12:39:37 pm Ralph Corderoy wrote:
> Hi Andrew,
>
> > What kind of spin-up times do you think are normal for a modern
> > hard-drive then?
>
> Second or two? Purely from very limited experience. Have just timed
> this very old 20GB PATA drive.
>
> $ foo() { date
Hi Andrew,
> What kind of spin-up times do you think are normal for a modern
> hard-drive then?
Second or two? Purely from very limited experience. Have just timed
this very old 20GB PATA drive.
$ foo() { date +%S.%N; }
$ sudo true; foo; sudo fdisk -l /dev/sdb >$N; foo
31.14270901
On Friday, February 18, 2011 08:43:43 am Ralph Corderoy wrote:
> Hi Andrew,
>
> > After spending days(!) fscking and trying to decode all kinds of stuff
> > I stepped back and saw the light - I MUST have a duff disk.
>
> `smartctl -a /dev/sda' can be useful to get the drive's own stats on how
On Friday, February 18, 2011 07:52:30 am Keith Edmunds wrote:
> On Thu, 17 Feb 2011 21:59:22 +, andy.pater...@ntlworld.com said:
> > Then Nokia puts a spoke in the works and effectively indicates that
> > continuing learning QT will be a waste of t!me
>
> I think you're extrapolating considera
Hi Andrew,
> After spending days(!) fscking and trying to decode all kinds of stuff
> I stepped back and saw the light - I MUST have a duff disk.
`smartctl -a /dev/sda' can be useful to get the drive's own stats on how
things are going. (Does fsck(8) still only check a filesystem's
metadata
On Thu, 17 Feb 2011 21:59:22 +, andy.pater...@ntlworld.com said:
> Then Nokia puts a spoke in the works and effectively indicates that
> continuing learning QT will be a waste of t!me
I think you're extrapolating considerably more than was announced. I very
much doubt Qt is going to disappear
On Thursday, February 17, 2011 04:49:24 pm Ralph Corderoy wrote:
> Hi Andrew,
>
> > The kernel log shows (e.g):
> > [ 7551.160178] ata10.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
>
> Is this a bug covering your problem?
>
> https://bugzilla.redhat.com/show_bug.cgi?id=549981
>
> C
Hi Andrew,
> The kernel log shows (e.g):
> [ 7551.160178] ata10.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6
Is this a bug covering your problem?
https://bugzilla.redhat.com/show_bug.cgi?id=549981
Cheers,
Ralph.
--
Next meeting: Blandford Forum, Wednesday 2011-03-02 20:00
Meets,
This looks like a dodgy disk.
run "smartctl" on your disks...
e.g. smartctl -a /dev/sda
will report any errors logged by the disk
you can also run an extended test with "smartctl -t long /dev/sda"
(not so sure how to match up the ata numbers with disk devices)
regards
Phil.
On 11 February 2
Given that you are getting (apparently) some kind of disk corruption, and
given that disk buffers are stored in memory prior to be flushed to disk,
I'd start by running (ideally overnight) Memtest86+ and see if that, er,
flushes out any errors.
Keith
--
Next meeting: Blandford Forum, Wednesday 2
Hi all,
I have a pernennial problem with a raid array (which contains a 400GB
filesystem 72% full.
Since its raid 1 I am bemused that I keep getting file-system errors every 2 or
threee days on reboot (requiring a manual fsck).
The kernel log shows (e.g):
___
18 matches
Mail list logo
