Prev: xdm autologin important for tiny devices
Next: Connecting the droid to a Debian workstation
From: Merciadri Luca on 1 Jun 2010 10:50
Ron Johnson wrote:
> On 06/01/2010 04:38 AM, Merciadri Luca wrote:
> [snip]
>> It will complain, but will it impede its `functioning'? I will probably
>> try with a rescue disk, effectively. What could have caused such errors
>> if I did not mistreat my computer these days?
>>
>
> Bug(s) in the OS or HDD firmware?
>
Well, the related files were actually some files which had nothing
special (i.e. not recent, not old, not often used, but sometimes used
too). Might a (correctly-)downloaded broken file corrupt the FS? I don't
think so (silly question).

--
Merciadri Luca
See http://www.student.montefiore.ulg.ac.be/~merciadri/
I use PGP. If there is an incompatibility problem with your mail
client, please contact me.


Never interrupt your enemy when he is making a mistake. (Napoleon
Bonaparte)

From: Hendrik Boom on 6 Jun 2010 21:00
On Tue, 01 Jun 2010 11:38:28 +0200, Merciadri Luca wrote:

> Andrew M.A. Cater wrote:

>> If you don't unmount it, e2fsck will complain. If need be, boot from a
>> rescue disk to do so - but I'm assuming that it's not the root (/)
>> filesystem, or you wouldn't have got this far.
>>
> It will complain, but will it impede its `functioning'?

It could impede its functioning if anything at all is written to the disk
while it is being checked. I can imagine it resulting in everything from
nothing to minor problems to indescribable chaos.

Don't go there if you value your data.

-- hendrik


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/huhfu0$lm9$1(a)dough.gmane.org
From: Hendrik Boom on 6 Jun 2010 21:20
On Mon, 07 Jun 2010 00:53:20 +0000, Hendrik Boom wrote:

> On Tue, 01 Jun 2010 11:38:28 +0200, Merciadri Luca wrote:
>
>> Andrew M.A. Cater wrote:
>
>>> If you don't unmount it, e2fsck will complain. If need be, boot from a
>>> rescue disk to do so - but I'm assuming that it's not the root (/)
>>> filesystem, or you wouldn't have got this far.
>>>
>> It will complain, but will it impede its `functioning'?
>
> It could impede its functioning if anything at all is written to the
> disk while it is being checked. I can imagine it resulting in
> everything from nothing to minor problems to indescribable chaos.
>
> Don't go there if you value your data.

And, of course, although I risk sounding like a broken record for saying
this yet again, when you've got this fixed, make sure you have a backup
of all your data.

But if you already have a backup, don't overwrite it with anew one until
you've fixed the problem and are sure that what you're backing up is
correct. It might even be worth dong a diff --recursive --brief (or
something similar depending on how your backup works) between your file
system and your backup and checking that the files that have changed are
the ones you expect to have changed...

-- hendrik


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/huhh24$lm9$2(a)dough.gmane.org
From: Andrew M.A. Cater on 7 Jun 2010 02:50
On Mon, Jun 07, 2010 at 01:12:36AM +0000, Hendrik Boom wrote:
> On Mon, 07 Jun 2010 00:53:20 +0000, Hendrik Boom wrote:
>
> > On Tue, 01 Jun 2010 11:38:28 +0200, Merciadri Luca wrote:
> >
> >> Andrew M.A. Cater wrote:
> >
> >>> If you don't unmount it, e2fsck will complain. If need be, boot from a
> >>> rescue disk to do so - but I'm assuming that it's not the root (/)
> >>> filesystem, or you wouldn't have got this far.
> >>>
> >> It will complain, but will it impede its `functioning'?
> >
> > It could impede its functioning if anything at all is written to the
> > disk while it is being checked. I can imagine it resulting in
> > everything from nothing to minor problems to indescribable chaos.
> >
> > Don't go there if you value your data.
>
> And, of course, although I risk sounding like a broken record for saying
> this yet again, when you've got this fixed, make sure you have a backup
> of all your data.
>
> But if you already have a backup, don't overwrite it with anew one until
> you've fixed the problem and are sure that what you're backing up is
> correct. It might even be worth dong a diff --recursive --brief (or
> something similar depending on how your backup works) between your file
> system and your backup and checking that the files that have changed are
> the ones you expect to have changed...

Further to this: a RAID is no infallible substitute for a backup of critical data.
A dying controller can write rubbish to your disks silently for days - even
if you just get a straightforward controller failure, you then have to treat all data
as potentially suspect for corruption.

Andy - who has lost one RAID to a controller failure and another to a failure of one disk
and unacceptable throughput - both in the space of about two weeks - both afer about 18 months
light-ish use.

If you have vital data, back it up into two or three places. If it's small enough, back it up
onto two or three different types of media - DVD-ROM, cheap flash drive _AND_ backup to hard disk
somewhere. If it's a document, save a copy in ASCII and/or print it. Have a good friend / family member
store some for you in their house - cheap "offsite" - on condition you store some for him/her.

Periodically, check you can get data back.

This is the counsel of perfection - no one EVER follows it - but if it saves someone's online life, business
, marriage or whatever, it'll be worth it :)

All best,

AndyC


>
> -- hendrik
>
>
> --
> To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
> Archive: http://lists.debian.org/huhh24$lm9$2(a)dough.gmane.org


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/20100607064158.GA24874(a)galactic.demon.co.uk
From: Erwan David on 7 Jun 2010 03:10
On Mon, Jun 07, 2010 at 08:41:58AM CEST, "Andrew M.A. Cater" <amacater(a)galactic.demon.co.uk> said:
> On Mon, Jun 07, 2010 at 01:12:36AM +0000, Hendrik Boom wrote:
> > On Mon, 07 Jun 2010 00:53:20 +0000, Hendrik Boom wrote:
> >
> > > On Tue, 01 Jun 2010 11:38:28 +0200, Merciadri Luca wrote:
> > >
> > >> Andrew M.A. Cater wrote:
> > >
> > >>> If you don't unmount it, e2fsck will complain. If need be, boot from a
> > >>> rescue disk to do so - but I'm assuming that it's not the root (/)
> > >>> filesystem, or you wouldn't have got this far.
> > >>>
> > >> It will complain, but will it impede its `functioning'?
> > >
> > > It could impede its functioning if anything at all is written to the
> > > disk while it is being checked. I can imagine it resulting in
> > > everything from nothing to minor problems to indescribable chaos.
> > >
> > > Don't go there if you value your data.
> >
> > And, of course, although I risk sounding like a broken record for saying
> > this yet again, when you've got this fixed, make sure you have a backup
> > of all your data.
> >
> > But if you already have a backup, don't overwrite it with anew one until
> > you've fixed the problem and are sure that what you're backing up is
> > correct. It might even be worth dong a diff --recursive --brief (or
> > something similar depending on how your backup works) between your file
> > system and your backup and checking that the files that have changed are
> > the ones you expect to have changed...
>
> Further to this: a RAID is no infallible substitute for a backup of critical data.
> A dying controller can write rubbish to your disks silently for days - even
> if you just get a straightforward controller failure, you then have to treat all data
> as potentially suspect for corruption.

And a RAID will destroy data on all disks if asked to...
In 11 years administering backups, the most common use case for
recovery is "oups I destroyed the wrong file".

--
Erwan


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/20100607070238.GJ11414(a)trusted-logic.com
First  |  Prev  | 
Pages: 1 2
Prev: xdm autologin important for tiny devices
Next: Connecting the droid to a Debian workstation