David ( Ford ) , I think you are misunderstanding a bit here.
The problem here is not that a fsck is needed after an unclean umount,
but that users are forced to corrupt ( by unclean umount due to reset or
poweroff ) their perfectly good file system on a "perfectly" working
system, when their
Otto Wyss wrote:
>
> > I had a similar experience:
> > X crashed , hosing the console , so I could not initiate
> > a proper shutdown.
> >
> > Here I must note that the response you got on linux-kernel is
> > shameful.
> >
> Thanks, but I expected it a little bit. All around Linux is centered
>
Gerhard Mack wrote:
>
> This sounds very nice.. can such a thing be done with the reset switch as
> well?
Don't think so.
I'm not sure , but I think that the reset button is directly connected
to the reset pin of most chips and can not be overrided.
Off course this is the first candidate for a
Gerhard Mack wrote:
This sounds very nice.. can such a thing be done with the reset switch as
well?
Don't think so.
I'm not sure , but I think that the reset button is directly connected
to the reset pin of most chips and can not be overrided.
Off course this is the first candidate for a
Otto Wyss wrote:
I had a similar experience:
X crashed , hosing the console , so I could not initiate
a proper shutdown.
Here I must note that the response you got on linux-kernel is
shameful.
Thanks, but I expected it a little bit. All around Linux is centered
around getting
David ( Ford ) , I think you are misunderstanding a bit here.
The problem here is not that a fsck is needed after an unclean umount,
but that users are forced to corrupt ( by unclean umount due to reset or
poweroff ) their perfectly good file system on a "perfectly" working
system, when their
> > You probably haven't tried to use sync or you would have noticed the
> > performace penalty. I think nobody really considers sync an alternative.
> >
> > O. Wyss
>
> You can't have the best of everything. There are tradeoffs. A viable option is > a
>journaled filesystem. Linux boasts a
Otto Wyss wrote:
> > No, the correct answer is if you want a reliable recovery then run your disks
> > in non write buffered mode. I.e. turn on sync in fstab.
> >
> You probably haven't tried to use sync or you would have noticed the
> performace penalty. I think nobody really considers sync an
> No, the correct answer is if you want a reliable recovery then run your disks
> in non write buffered mode. I.e. turn on sync in fstab.
>
You probably haven't tried to use sync or you would have noticed the
performace penalty. I think nobody really considers sync an alternative.
O. Wyss
-
To
No, the correct answer is if you want a reliable recovery then run your disks
in non write buffered mode. I.e. turn on sync in fstab.
You probably haven't tried to use sync or you would have noticed the
performace penalty. I think nobody really considers sync an alternative.
O. Wyss
-
To
Otto Wyss wrote:
No, the correct answer is if you want a reliable recovery then run your disks
in non write buffered mode. I.e. turn on sync in fstab.
You probably haven't tried to use sync or you would have noticed the
performace penalty. I think nobody really considers sync an
You probably haven't tried to use sync or you would have noticed the
performace penalty. I think nobody really considers sync an alternative.
O. Wyss
You can't have the best of everything. There are tradeoffs. A viable option is a
journaled filesystem. Linux boasts a few, two of
Otto Wyss wrote:
> > I had a similar experience:
> > X crashed , hosing the console , so I could not initiate
> > a proper shutdown.
> >
> > Here I must note that the response you got on linux-kernel is
> > shameful.
> >
> Thanks, but I expected it a little bit. All around Linux is centered
>
> I had a similar experience:
> X crashed , hosing the console , so I could not initiate
> a proper shutdown.
>
> Here I must note that the response you got on linux-kernel is
> shameful.
>
Thanks, but I expected it a little bit. All around Linux is centered
around getting the highest
This sounds very nice.. can such a thing be done with the reset switch as
well?
Gerhard
On Fri, 23 Mar 2001, David Balazic wrote:
> I had a similar experience:
> X crashed , hosing the console , so I could not initiate
> a proper shutdown.
>
> Here I must note that the response you
I had a similar experience:
X crashed , hosing the console , so I could not initiate
a proper shutdown.
Here I must note that the response you got on linux-kernel is
shameful.
What I did was to write a kernel/apmd patch , that performed a
proper shutdown when I press the power button ( which
I had a similar experience:
X crashed , hosing the console , so I could not initiate
a proper shutdown.
Here I must note that the response you got on linux-kernel is
shameful.
What I did was to write a kernel/apmd patch , that performed a
proper shutdown when I press the power button ( which
This sounds very nice.. can such a thing be done with the reset switch as
well?
Gerhard
On Fri, 23 Mar 2001, David Balazic wrote:
I had a similar experience:
X crashed , hosing the console , so I could not initiate
a proper shutdown.
Here I must note that the response you got
I had a similar experience:
X crashed , hosing the console , so I could not initiate
a proper shutdown.
Here I must note that the response you got on linux-kernel is
shameful.
Thanks, but I expected it a little bit. All around Linux is centered
around getting the highest performance out
Otto Wyss wrote:
I had a similar experience:
X crashed , hosing the console , so I could not initiate
a proper shutdown.
Here I must note that the response you got on linux-kernel is
shameful.
Thanks, but I expected it a little bit. All around Linux is centered
around getting the
Followup to: <[EMAIL PROTECTED]>
By author:Otto Wyss <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> It was just a simple test machine where it didn't matter what was lost.
> Still that doesn't justify this behaviour.
>
Then use a journalling filesystem. If not, give it a few
Followup to: [EMAIL PROTECTED]
By author:Otto Wyss [EMAIL PROTECTED]
In newsgroup: linux.dev.kernel
It was just a simple test machine where it didn't matter what was lost.
Still that doesn't justify this behaviour.
Then use a journalling filesystem. If not, give it a few minutes of
On Mon, Mar 19, 2001 at 11:35:55PM +0100, Otto Wyss wrote:
> > you can avoid all of these problems. Or use a journaling filesystem ext3/xfs, etc.
>
> So in real live you would propose to put fences and nets everywhere to
> prevent children from possibly falling in abyses?
I think you've got it
> Actually, I think /etc/mtab is not needed at all. Originally, UNIX
> used to put as much onto the disk (and not in "core") as possible.
> so much state information related only to one boot-cycle was
> taken out of kernel and stored on disk. /var/run/utmp, /etc/mtab,
> , rmtab, and many
Richard B. Johnson wrote:
> Unix and other such variants have what's called a Virtual File System
> (VFS).
Correct, but hardly relevant here, except possibly that this enables you
to use a different, perhaps more resilient file system.
> The idea behind this is to keep as much recently-used
(Recipients trimmed, as this is a major change of topic...)
[big cut]
> Actually, I think /etc/mtab is not needed at all.
This is already mostly correct, AFAIK.
My embedded system uses "busybox" for mount and umount, /etc/mtab
does not exist, and the root file system is readonly.
But if
Guy,
I wrote APCUPSD beginning back in 95/96 for this reason.
American Power Conversion is now friendly to Linux.
http://www.linux-ide.org/apcupsd.html
Cheers,
On Mon, 19 Mar 2001, Stephen Satchell wrote:
> At 01:16 PM 3/19/01 -0800, Torrey Hoffman wrote:
> >Yes. Some of this is your
"Stephen Gutknecht (linux-kernel)" wrote:
>
> Otto,
>
[...]
> Have you considered telnet into your box from a second machine? Even a 486
> system would do this fine... network cards are cheap. You could try to
> recover the system or at least do a shutdown.
>
It was just a simple test
Jeremy Jackson wrote:
>
> Brian Gerst wrote:
>
> > "Richard B. Johnson" wrote:
> > >
> > > On Mon, 19 Mar 2001, Otto Wyss wrote:
> > >
> > > > Lately I had an USB failure, leaving me without any access to my system
[..]
> > > Unix and other such variants have what's called a Virtual File System
At 01:16 PM 3/19/01 -0800, Torrey Hoffman wrote:
>Yes. Some of this is your responsibility. You have several options:
>1. Get a UPS. That would not have helped your particular problem,
>but it's a good idea if you care about data integrity.
>2. Use a journaling file system. These are much
"Richard B. Johnson" wrote:
> On Mon, 19 Mar 2001, Brian Gerst wrote:
> [SNIPPED...]
>
> >
> > At the very least the disk should be consistent with memory. If the
> > dirty pages aren't written back to the disk (but not necessarily removed
> > from memory) after a reasonable idle period, then
]]
Sent: Monday, March 19, 2001 11:47 AM
To: [EMAIL PROTECTED]
Subject: Linux should better cope with power failure
Lately I had an USB failure, leaving me without any access to my system
since I only use an USB-keyboard/-mouse. All I could do in that
situation was switching power off and on after
"Richard B. Johnson" wrote:
>
> On Mon, 19 Mar 2001, Brian Gerst wrote:
> [SNIPPED...]
>
> >
> > At the very least the disk should be consistent with memory. If the
> > dirty pages aren't written back to the disk (but not necessarily removed
> > from memory) after a reasonable idle period,
On Mon, 19 Mar 2001, Brian Gerst wrote:
[SNIPPED...]
>
> At the very least the disk should be consistent with memory. If the
> dirty pages aren't written back to the disk (but not necessarily removed
> from memory) after a reasonable idle period, then there is room for
> improvement.
>
Hmmm.
Otto Wyss wrote:
> situation was switching power off and on after a few minutes of
> inactivity. From the impression I got during the following startup, I
You aren't giving a lot of detail here. I assume your startup scripts run
fsck, and you saw a lot of errors. Were any of them
Brian Gerst wrote:
> "Richard B. Johnson" wrote:
> >
> > On Mon, 19 Mar 2001, Otto Wyss wrote:
> >
> > > Lately I had an USB failure, leaving me without any access to my system
> > > since I only use an USB-keyboard/-mouse. All I could do in that
> > > situation was switching power off and on
"Richard B. Johnson" wrote:
>
> On Mon, 19 Mar 2001, Otto Wyss wrote:
>
> > Lately I had an USB failure, leaving me without any access to my system
> > since I only use an USB-keyboard/-mouse. All I could do in that
> > situation was switching power off and on after a few minutes of
> >
On Mon, 19 Mar 2001, Otto Wyss wrote:
> inactivity. From the impression I got during the following startup, I
> assume Linux (2.4.2, EXT2-filesystem) is not very suited to any power
> failiure or manually switching it off. Not even if there wasn't any
> activity going on.
What data, if any, did
On Mon, 19 Mar 2001, Otto Wyss wrote:
> Lately I had an USB failure, leaving me without any access to my system
> since I only use an USB-keyboard/-mouse. All I could do in that
> situation was switching power off and on after a few minutes of
> inactivity. From the impression I got during the
Otto Wyss <[EMAIL PROTECTED]> wrote:
> Lately I had an USB failure, leaving me without any access to my system
> since I only use an USB-keyboard/-mouse. All I could do in that
> situation was switching power off and on after a few minutes of
> inactivity. From the impression I got during the
Lately I had an USB failure, leaving me without any access to my system
since I only use an USB-keyboard/-mouse. All I could do in that
situation was switching power off and on after a few minutes of
inactivity. From the impression I got during the following startup, I
assume Linux (2.4.2,
Lately I had an USB failure, leaving me without any access to my system
since I only use an USB-keyboard/-mouse. All I could do in that
situation was switching power off and on after a few minutes of
inactivity. From the impression I got during the following startup, I
assume Linux (2.4.2,
Otto Wyss [EMAIL PROTECTED] wrote:
Lately I had an USB failure, leaving me without any access to my system
since I only use an USB-keyboard/-mouse. All I could do in that
situation was switching power off and on after a few minutes of
inactivity. From the impression I got during the following
On Mon, 19 Mar 2001, Otto Wyss wrote:
Lately I had an USB failure, leaving me without any access to my system
since I only use an USB-keyboard/-mouse. All I could do in that
situation was switching power off and on after a few minutes of
inactivity. From the impression I got during the
On Mon, 19 Mar 2001, Otto Wyss wrote:
inactivity. From the impression I got during the following startup, I
assume Linux (2.4.2, EXT2-filesystem) is not very suited to any power
failiure or manually switching it off. Not even if there wasn't any
activity going on.
What data, if any, did you
"Richard B. Johnson" wrote:
On Mon, 19 Mar 2001, Otto Wyss wrote:
Lately I had an USB failure, leaving me without any access to my system
since I only use an USB-keyboard/-mouse. All I could do in that
situation was switching power off and on after a few minutes of
inactivity. From
Otto Wyss wrote:
situation was switching power off and on after a few minutes of
inactivity. From the impression I got during the following startup, I
You aren't giving a lot of detail here. I assume your startup scripts run
fsck, and you saw a lot of errors. Were any of them uncorrectable?
Brian Gerst wrote:
"Richard B. Johnson" wrote:
On Mon, 19 Mar 2001, Otto Wyss wrote:
Lately I had an USB failure, leaving me without any access to my system
since I only use an USB-keyboard/-mouse. All I could do in that
situation was switching power off and on after a few
On Mon, 19 Mar 2001, Brian Gerst wrote:
[SNIPPED...]
At the very least the disk should be consistent with memory. If the
dirty pages aren't written back to the disk (but not necessarily removed
from memory) after a reasonable idle period, then there is room for
improvement.
Hmmm. Now
"Richard B. Johnson" wrote:
On Mon, 19 Mar 2001, Brian Gerst wrote:
[SNIPPED...]
At the very least the disk should be consistent with memory. If the
dirty pages aren't written back to the disk (but not necessarily removed
from memory) after a reasonable idle period, then there is
]]
Sent: Monday, March 19, 2001 11:47 AM
To: [EMAIL PROTECTED]
Subject: Linux should better cope with power failure
Lately I had an USB failure, leaving me without any access to my system
since I only use an USB-keyboard/-mouse. All I could do in that
situation was switching power off and on after
"Richard B. Johnson" wrote:
On Mon, 19 Mar 2001, Brian Gerst wrote:
[SNIPPED...]
At the very least the disk should be consistent with memory. If the
dirty pages aren't written back to the disk (but not necessarily removed
from memory) after a reasonable idle period, then there is
At 01:16 PM 3/19/01 -0800, Torrey Hoffman wrote:
Yes. Some of this is your responsibility. You have several options:
1. Get a UPS. That would not have helped your particular problem,
but it's a good idea if you care about data integrity.
2. Use a journaling file system. These are much
Jeremy Jackson wrote:
Brian Gerst wrote:
"Richard B. Johnson" wrote:
On Mon, 19 Mar 2001, Otto Wyss wrote:
Lately I had an USB failure, leaving me without any access to my system
[..]
Unix and other such variants have what's called a Virtual File System
(VFS). The idea
"Stephen Gutknecht (linux-kernel)" wrote:
Otto,
[...]
Have you considered telnet into your box from a second machine? Even a 486
system would do this fine... network cards are cheap. You could try to
recover the system or at least do a shutdown.
It was just a simple test machine where
Guy,
I wrote APCUPSD beginning back in 95/96 for this reason.
American Power Conversion is now friendly to Linux.
http://www.linux-ide.org/apcupsd.html
Cheers,
On Mon, 19 Mar 2001, Stephen Satchell wrote:
At 01:16 PM 3/19/01 -0800, Torrey Hoffman wrote:
Yes. Some of this is your
(Recipients trimmed, as this is a major change of topic...)
[big cut]
Actually, I think /etc/mtab is not needed at all.
This is already mostly correct, AFAIK.
My embedded system uses "busybox" for mount and umount, /etc/mtab
does not exist, and the root file system is readonly.
But if
Richard B. Johnson wrote:
Unix and other such variants have what's called a Virtual File System
(VFS).
Correct, but hardly relevant here, except possibly that this enables you
to use a different, perhaps more resilient file system.
The idea behind this is to keep as much recently-used file
Actually, I think /etc/mtab is not needed at all. Originally, UNIX
used to put as much onto the disk (and not in "core") as possible.
so much state information related only to one boot-cycle was
taken out of kernel and stored on disk. /var/run/utmp, /etc/mtab,
, rmtab, and many others.
59 matches
Mail list logo
