On Mon, Jan 08, 2001 at 12:02:49PM +, Stephen C. Tweedie wrote:
> Right. There are two distinct meanings:
>
> 1) Do not write to this medium, ever (physical readonly); and
>
> 2) Do not allow modifications to the filesystem (logical readonly).
>
> The fact is that the kernel confuses the
On Mon, Jan 08, 2001 at 12:02:49PM +, Stephen C. Tweedie wrote:
Right. There are two distinct meanings:
1) Do not write to this medium, ever (physical readonly); and
2) Do not allow modifications to the filesystem (logical readonly).
The fact is that the kernel confuses the two,
In article <[EMAIL PROTECTED]> you wrote:
> Also thing about cases where powerplant fails, or when electricity in
> the house fails. I've seen places where electricity failed 5 times a
> day, because someone put 10A fuse and we were using just about 2kW...
Especially evil is a power failure, and
Hi!
> 1. setup the power switch so it doesn't actually turn things off (it
> issues the shutdown command instead)
Evil. Devices that are powered off should stay powered off, and there
should be big mechanical switch to do that, so that no EMI or power
glitch can make them power up.
Also thing
Hi!
> > > Being able to shut down by hitting the power switch is a little luxury
> > > for which I've been willing to invest more than a year of my life to
> > > attain. Clueless newbies don't know why it should be any other way, and
> > > it's essential for embedded devices.
> >
> > Clueless
Hi,
On Sat, Jan 06, 2001 at 08:57:26PM +0100, Marc Lehmann wrote:
> On Fri, Jan 05, 2001 at 11:58:56AM +, David Woodhouse <[EMAIL PROTECTED]>
>wrote:
> > You mount it read-only, recover as much as possible from it, and bin it.
> >
> > You _don't_ want the fs code to ignore your explicit
Hi,
On Sat, Jan 06, 2001 at 08:57:26PM +0100, Marc Lehmann wrote:
On Fri, Jan 05, 2001 at 11:58:56AM +, David Woodhouse [EMAIL PROTECTED]
wrote:
You mount it read-only, recover as much as possible from it, and bin it.
You _don't_ want the fs code to ignore your explicit instructions
Hi!
Being able to shut down by hitting the power switch is a little luxury
for which I've been willing to invest more than a year of my life to
attain. Clueless newbies don't know why it should be any other way, and
it's essential for embedded devices.
Clueless newbies (and
Hi!
1. setup the power switch so it doesn't actually turn things off (it
issues the shutdown command instead)
Evil. Devices that are powered off should stay powered off, and there
should be big mechanical switch to do that, so that no EMI or power
glitch can make them power up.
Also thing
In article [EMAIL PROTECTED] you wrote:
Also thing about cases where powerplant fails, or when electricity in
the house fails. I've seen places where electricity failed 5 times a
day, because someone put 10A fuse and we were using just about 2kW...
Especially evil is a power failure, and then
On Sat, Jan 06, 2001 at 03:35:02PM -0500, Chris Mason <[EMAIL PROTECTED]> wrote:
> > Nobody with working brain would read it completely into memory.
Instead everybody with a working brain would introduce another hashing
layer for every block access? I don't think the reiserfs code (e.g.) would
On Saturday, January 06, 2001 09:09:51 PM +0100 Stefan Traby
<[EMAIL PROTECTED]> wrote:
> On Sat, Jan 06, 2001 at 08:57:26PM +0100, Marc Lehmann wrote:
>
>> reply. Sure, you can do virtual log replays, but for example the reiserfs
>> log is currently 32mb. Pinning down that much memory for a
On Sat, Jan 06, 2001 at 08:57:26PM +0100, Marc Lehmann wrote:
> reply. Sure, you can do virtual log replays, but for example the reiserfs
> log is currently 32mb. Pinning down that much memory for a virtual log
> reply is not possible on low-memory machines.
Nobody with working brain would read
On Fri, Jan 05, 2001 at 11:58:56AM +, David Woodhouse <[EMAIL PROTECTED]> wrote:
> You mount it read-only, recover as much as possible from it, and bin it.
>
> You _don't_ want the fs code to ignore your explicit instructions not to
> write to the medium, and to destroy whatever data were
On Fri, Jan 05, 2001 at 11:58:56AM +, David Woodhouse [EMAIL PROTECTED] wrote:
You mount it read-only, recover as much as possible from it, and bin it.
You _don't_ want the fs code to ignore your explicit instructions not to
write to the medium, and to destroy whatever data were left.
On Sat, Jan 06, 2001 at 08:57:26PM +0100, Marc Lehmann wrote:
reply. Sure, you can do virtual log replays, but for example the reiserfs
log is currently 32mb. Pinning down that much memory for a virtual log
reply is not possible on low-memory machines.
Nobody with working brain would read it
On Saturday, January 06, 2001 09:09:51 PM +0100 Stefan Traby
[EMAIL PROTECTED] wrote:
On Sat, Jan 06, 2001 at 08:57:26PM +0100, Marc Lehmann wrote:
reply. Sure, you can do virtual log replays, but for example the reiserfs
log is currently 32mb. Pinning down that much memory for a virtual
On Sat, Jan 06, 2001 at 03:35:02PM -0500, Chris Mason [EMAIL PROTECTED] wrote:
Nobody with working brain would read it completely into memory.
Instead everybody with a working brain would introduce another hashing
layer for every block access? I don't think the reiserfs code (e.g.) would
cope
[EMAIL PROTECTED] said:
> Many newer cell phones, even low spec ones, will have a software
> power switch (usually with a hardware override after about 5 seconds
> of continuous press). There are many other concessions that need to
> be made to power efficiency, like the ability to toggle
On Thu, Jan 04, 2001 at 06:11:11PM +, Alan Cox wrote:
> > in an enbedded device you can
> > 1. setup the power switch so it doesn't actually turn things off (it
> > issues the shutdown command instead)
>
> Costs too much money
Many newer cell phones, even low spec ones, will have a software
Hi,
On Fri, Jan 05, 2001 at 12:46:19PM +, Alan Cox wrote:
> > recovery. Because the ext3 journal is just a series of data blocks to
> > be copied into the filesystem (rather than "actions" to be done), it
> > doesn't matter how many times it is done. The recovery flags are not
> > reset
> Unless Stephen says otherwise, my understanding is that a crash during
> journal recovery will just mean the journal is replayed again at the next
> recovery. Because the ext3 journal is just a series of data blocks to
> be copied into the filesystem (rather than "actions" to be done), it
>
Hi,
On Fri, Jan 05, 2001 at 02:01:37AM +0100, Stefan Traby wrote:
>
> Please tell me how to specify "noreplay" for the initial "/" mount
> :)
You don't have to: the filesystem knows when a root mount is
happening, and can do the extra work then to make sure that the mount
isn't failed on a
[EMAIL PROTECTED] said:
> Powering down a VCR whilst recording can damage the tape or even
> worse have the tap get jammed in the video. I have also had a TV die
> because it was unpowered from the mains without being switched off
> first.
> Sure, these things don't always happen -- but they
[EMAIL PROTECTED] said:
> In what way? A root fs readonly mount is usually designed to prevent
^^^
> the filesystem from being stomped on during the initial boot so that
> fsck can run without the filesystem being volatile. That's the only
>
Hi,
On Fri, Jan 05, 2001 at 01:31:12AM +0100, Daniel Phillips wrote:
> "Stephen C. Tweedie" wrote:
> >
> Yes, and so long as your journal is not on another partition/disk things
> will eventually be set right. The combination of a partially updated
> filesystem and its journal is in some sense
Hi,
On Fri, Jan 05, 2001 at 01:31:12AM +0100, Daniel Phillips wrote:
"Stephen C. Tweedie" wrote:
Yes, and so long as your journal is not on another partition/disk things
will eventually be set right. The combination of a partially updated
filesystem and its journal is in some sense a
[EMAIL PROTECTED] said:
In what way? A root fs readonly mount is usually designed to prevent
^^^
the filesystem from being stomped on during the initial boot so that
fsck can run without the filesystem being volatile. That's the only
reason
[EMAIL PROTECTED] said:
Powering down a VCR whilst recording can damage the tape or even
worse have the tap get jammed in the video. I have also had a TV die
because it was unpowered from the mains without being switched off
first.
Sure, these things don't always happen -- but they
Hi,
On Fri, Jan 05, 2001 at 02:01:37AM +0100, Stefan Traby wrote:
Please tell me how to specify "noreplay" for the initial "/" mount
:)
You don't have to: the filesystem knows when a root mount is
happening, and can do the extra work then to make sure that the mount
isn't failed on a
Unless Stephen says otherwise, my understanding is that a crash during
journal recovery will just mean the journal is replayed again at the next
recovery. Because the ext3 journal is just a series of data blocks to
be copied into the filesystem (rather than "actions" to be done), it
doesn't
Hi,
On Fri, Jan 05, 2001 at 12:46:19PM +, Alan Cox wrote:
recovery. Because the ext3 journal is just a series of data blocks to
be copied into the filesystem (rather than "actions" to be done), it
doesn't matter how many times it is done. The recovery flags are not
reset until
[EMAIL PROTECTED] said:
Many newer cell phones, even low spec ones, will have a software
power switch (usually with a hardware override after about 5 seconds
of continuous press). There are many other concessions that need to
be made to power efficiency, like the ability to toggle power to
Stefan, you write:
> [Re: read-only filesystem vs. read-only device]
> Anyway, it is "especially" critical on the root filesystem because the
> authors of filesystems can't support two ro states on boot.
>
> Reiserfs allowed -oro,noreplay.
>
> Please tell me how to specify "noreplay" for the
Daniel writes:
> Yes, and so long as your journal is not on another partition/disk things
> will eventually be set right. The combination of a partially updated
> filesystem and its journal is in some sense a complete, consistent
> filesystem.
>
> I'm curious - how does ext3 handle the
> I have an old IBM Aptiva 486 SX that actually DOES something like this; what
> it does is, it suspends to disk when you hit the power button (you have to
> turn that option on though).
> Point being, if it was possible back then (6 years ago), why on earth would
> it be too expensive now?
I'd
On Thu, 4 Jan 2001, Alan Cox wrote:
> From: Alan Cox <[EMAIL PROTECTED]>
> Subject: Re: Journaling: Surviving or allowing unclean shutdown?
>
> > in an enbedded device you can
> > 1. setup the power switch so it doesn't actually turn things off (it
> > is
On Thu, Jan 04, 2001 at 10:49:46PM +, Stephen C. Tweedie wrote:
> > I think any other action (only replaying on rw mount and presenting
> > a broken filesystem on ro) is quite fatal, at least if I think of
> > a replay on -remount,rw :)
>
> Correct.
>
> > Also, an unconditional hidden
"Stephen C. Tweedie" wrote:
>
> On Wed, Jan 03, 2001 at 05:27:25PM +0100, Daniel Phillips wrote:
> >
> > Tux2 is explicitly designed to legitimize pulling the plug as a valid
> > way of shutting down. Metadata-only journalling filesystems are not
> > designed to be used this way, and even with
Hi,
On Thu, Jan 04, 2001 at 10:08:21PM +0100, Stefan Traby wrote:
> On Thu, Jan 04, 2001 at 07:21:04PM +, Stephen C. Tweedie wrote:
>
> > ext3 does the recovery automatically during mount(8), so user space
> > will never see an unrecovered filesystem. (There are filesystem flags
> > set by
On Thu, Jan 04, 2001 at 03:59:40PM -0500, Richard B. Johnson wrote:
> Well they do! It's just not allowed for us (the users) to know that they
> __didn't__ run completely out of power! If the thing is so dead
> that it won't recharge, it still has 'power' (enough to keep static RAM
> alive).
> > Being able to shut down by hitting the power switch is a little luxury
> > for which I've been willing to invest more than a year of my life to
> > attain. Clueless newbies don't know why it should be any other way, and
> > it's essential for embedded devices.
Just some food for thought -
On Thu, Jan 04, 2001 at 07:21:04PM +, Stephen C. Tweedie wrote:
> ext3 does the recovery automatically during mount(8), so user space
> will never see an unrecovered filesystem. (There are filesystem flags
> set by the journal code to make sure that an unrecovered filesystem
> never gets
On 4 Jan, Richard B. Johnson wrote:
> Well they do! It's just not allowed for us (the users) to know that
> they
> __didn't__ run completely out of power! If the thing is so dead
> that it won't recharge, it still has 'power' (enough to keep static
> RAM alive). Just remove the battery, wait
Well. How does tivo handle this situation? Certainly, there are instances
when your power will fail in your home and your Tivo will be without
juice. When it powers back on what does it do to check the fs? Does it
need to check the fs?
Brett G. Person
415-358-2656
[EMAIL PROTECTED]
Penguin
On Thu, 4 Jan 2001 [EMAIL PROTECTED] wrote:
> On 4 Jan, Richard B. Johnson wrote:
>
> > A mobile-phone that runs out of battery power will also lose all the
> > phone numbers you have stored, etc. The same is true for most all
> > embedded systems that save data.
>
> In your world maybe. I
On 4 Jan, Richard B. Johnson wrote:
> A mobile-phone that runs out of battery power will also lose all the
> phone numbers you have stored, etc. The same is true for most all
> embedded systems that save data.
In your world maybe. I would be quite pissed if my mobile phones lost
the stored
On Thu, 4 Jan 2001, Mo McKinlay wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Today, David Lang ([EMAIL PROTECTED]) wrote:
>
> > On Thu, 4 Jan 2001, Mo McKinlay wrote:
> >
> > > > The off button need not and _does not_ remove power instantly (if at
> > > > all) on
Hi,
On Wed, Jan 03, 2001 at 05:27:25PM +0100, Daniel Phillips wrote:
>
> Tux2 is explicitly designed to legitimize pulling the plug as a valid
> way of shutting down. Metadata-only journalling filesystems are not
> designed to be used this way, and even with full-data journalling you
> should
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Today, David Lang ([EMAIL PROTECTED]) wrote:
> On Thu, 4 Jan 2001, Mo McKinlay wrote:
>
> > > The off button need not and _does not_ remove power instantly (if at
> > > all) on many appliances.
> >
> > Indeed - but unplugging your
On Thu, 4 Jan 2001, Alan Cox wrote:
> > for crying out loud, even windows tells the users they need to shutdown
> > first and gripes at them if they pull the plug. what users are you trying
> > to protect, ones to clueless to even run windows?
>
> Clueless ? Hardly. Every other appliance in the
On Thu, 4 Jan 2001, Mo McKinlay wrote:
> > The off button need not and _does not_ remove power instantly (if at
> > all) on many appliances.
>
> Indeed - but unplugging your VCR from the wall won't harm it. Everyone
> knows the power button on a TV/VCR/etc doesn't actually kill the power,
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> The off button need not and _does not_ remove power instantly (if at
> all) on many appliances.
Indeed - but unplugging your VCR from the wall won't harm it. Everyone
knows the power button on a TV/VCR/etc doesn't actually kill the power,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> for crying out loud, even windows tells the users they need to shutdown
> first and gripes at them if they pull the plug. what users are you trying
> to protect, ones to clueless to even run windows?
>
> David Lang
> > > > > it's
> in an enbedded device you can
> 1. setup the power switch so it doesn't actually turn things off (it
> issues the shutdown command instead)
Costs too much money
> 2. run from read-only media almost exclusivly so that power event's don't
> bother you much
Depends on the device
> 3. you can
ECTED]>, [EMAIL PROTECTED]
> Subject: Re: Journaling: Surviving or allowing unclean shutdown?
>
>
> [EMAIL PROTECTED] said:
> > for crying out loud, even windows tells the users they need to
> > shutdown first and gripes at them if they pull the plug. what users
>
> for crying out loud, even windows tells the users they need to shutdown
> first and gripes at them if they pull the plug. what users are you trying
> to protect, ones to clueless to even run windows?
Clueless ? Hardly. Every other appliance in the home you turn it off and it
goes off. You
[EMAIL PROTECTED] said:
> for crying out loud, even windows tells the users they need to
> shutdown first and gripes at them if they pull the plug. what users
> are you trying to protect, ones to clueless to even run windows?
Precisely. Users of embedded devices don't expect to have to treat
100
> From: Daniel Phillips <[EMAIL PROTECTED]>
> To: Helge Hafting <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> Subject: Re: Journaling: Surviving or allowing unclean shutdown?
>
> Helge Hafting wrote:
> >
> > [...]
> > > > Being able to sh
On Thu, 4 Jan 2001, Daniel Phillips wrote:
> > A lot of applications always rely on their file i/o being done in some
> > manner that has atomic (from the application's point of view) operations
> > other than system calls -- heck, even make(1) does that.
>
> Nobody is forcing you to hit the
On Thu, 4 Jan 2001, Daniel Phillips wrote:
> > Nothing wrong with a filesystem (or apps) that can handle being
> > powered down. But I prefer to handle this kind of users with a
> > power switch that merely acts as a "shutdown button" instead of
> > actually killing power. The os will then run
Helge Hafting wrote:
>
> [...]
> > > Being able to shut down by hitting the power switch is a little luxury
> > > for which I've been willing to invest more than a year of my life to
> > > attain. Clueless newbies don't know why it should be any other way, and
> > > it's essential for embedded
[...]
> > Being able to shut down by hitting the power switch is a little luxury
> > for which I've been willing to invest more than a year of my life to
> > attain. Clueless newbies don't know why it should be any other way, and
> > it's essential for embedded devices.
>
> Clueless newbies
[...]
Being able to shut down by hitting the power switch is a little luxury
for which I've been willing to invest more than a year of my life to
attain. Clueless newbies don't know why it should be any other way, and
it's essential for embedded devices.
Clueless newbies (and slightly
Helge Hafting wrote:
[...]
Being able to shut down by hitting the power switch is a little luxury
for which I've been willing to invest more than a year of my life to
attain. Clueless newbies don't know why it should be any other way, and
it's essential for embedded devices.
On Thu, 4 Jan 2001, Daniel Phillips wrote:
Nothing wrong with a filesystem (or apps) that can handle being
powered down. But I prefer to handle this kind of users with a
power switch that merely acts as a "shutdown button" instead of
actually killing power. The os will then run the
On Thu, 4 Jan 2001, Daniel Phillips wrote:
A lot of applications always rely on their file i/o being done in some
manner that has atomic (from the application's point of view) operations
other than system calls -- heck, even make(1) does that.
Nobody is forcing you to hit the power
From: Daniel Phillips [EMAIL PROTECTED]
To: Helge Hafting [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: Journaling: Surviving or allowing unclean shutdown?
Helge Hafting wrote:
[...]
Being able to shut down by hitting the power switch is a little luxury
for which I've been willing
[EMAIL PROTECTED] said:
for crying out loud, even windows tells the users they need to
shutdown first and gripes at them if they pull the plug. what users
are you trying to protect, ones to clueless to even run windows?
Precisely. Users of embedded devices don't expect to have to treat them
for crying out loud, even windows tells the users they need to shutdown
first and gripes at them if they pull the plug. what users are you trying
to protect, ones to clueless to even run windows?
Clueless ? Hardly. Every other appliance in the home you turn it off and it
goes off. You turn
: Surviving or allowing unclean shutdown?
[EMAIL PROTECTED] said:
for crying out loud, even windows tells the users they need to
shutdown first and gripes at them if they pull the plug. what users
are you trying to protect, ones to clueless to even run windows?
Precisely. Users
in an enbedded device you can
1. setup the power switch so it doesn't actually turn things off (it
issues the shutdown command instead)
Costs too much money
2. run from read-only media almost exclusivly so that power event's don't
bother you much
Depends on the device
3. you can add
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
for crying out loud, even windows tells the users they need to shutdown
first and gripes at them if they pull the plug. what users are you trying
to protect, ones to clueless to even run windows?
David Lang
it's essential for
On Thu, 4 Jan 2001, Mo McKinlay wrote:
The off button need not and _does not_ remove power instantly (if at
all) on many appliances.
Indeed - but unplugging your VCR from the wall won't harm it. Everyone
knows the power button on a TV/VCR/etc doesn't actually kill the power,
just
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The off button need not and _does not_ remove power instantly (if at
all) on many appliances.
Indeed - but unplugging your VCR from the wall won't harm it. Everyone
knows the power button on a TV/VCR/etc doesn't actually kill the power,
just
On Thu, 4 Jan 2001, Alan Cox wrote:
for crying out loud, even windows tells the users they need to shutdown
first and gripes at them if they pull the plug. what users are you trying
to protect, ones to clueless to even run windows?
Clueless ? Hardly. Every other appliance in the home
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Today, David Lang ([EMAIL PROTECTED]) wrote:
On Thu, 4 Jan 2001, Mo McKinlay wrote:
The off button need not and _does not_ remove power instantly (if at
all) on many appliances.
Indeed - but unplugging your VCR from the
Hi,
On Wed, Jan 03, 2001 at 05:27:25PM +0100, Daniel Phillips wrote:
Tux2 is explicitly designed to legitimize pulling the plug as a valid
way of shutting down. Metadata-only journalling filesystems are not
designed to be used this way, and even with full-data journalling you
should bear
On Thu, 4 Jan 2001, Mo McKinlay wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Today, David Lang ([EMAIL PROTECTED]) wrote:
On Thu, 4 Jan 2001, Mo McKinlay wrote:
The off button need not and _does not_ remove power instantly (if at
all) on many appliances.
On 4 Jan, Richard B. Johnson wrote:
A mobile-phone that runs out of battery power will also lose all the
phone numbers you have stored, etc. The same is true for most all
embedded systems that save data.
In your world maybe. I would be quite pissed if my mobile phones lost
the stored
On Thu, 4 Jan 2001 [EMAIL PROTECTED] wrote:
On 4 Jan, Richard B. Johnson wrote:
A mobile-phone that runs out of battery power will also lose all the
phone numbers you have stored, etc. The same is true for most all
embedded systems that save data.
In your world maybe. I would be
Well. How does tivo handle this situation? Certainly, there are instances
when your power will fail in your home and your Tivo will be without
juice. When it powers back on what does it do to check the fs? Does it
need to check the fs?
Brett G. Person
415-358-2656
[EMAIL PROTECTED]
Penguin
On 4 Jan, Richard B. Johnson wrote:
Well they do! It's just not allowed for us (the users) to know that
they
__didn't__ run completely out of power! If the thing is so dead
that it won't recharge, it still has 'power' (enough to keep static
RAM alive). Just remove the battery, wait about
On Thu, Jan 04, 2001 at 07:21:04PM +, Stephen C. Tweedie wrote:
ext3 does the recovery automatically during mount(8), so user space
will never see an unrecovered filesystem. (There are filesystem flags
set by the journal code to make sure that an unrecovered filesystem
never gets
Being able to shut down by hitting the power switch is a little luxury
for which I've been willing to invest more than a year of my life to
attain. Clueless newbies don't know why it should be any other way, and
it's essential for embedded devices.
Just some food for thought - hitting
On Thu, Jan 04, 2001 at 03:59:40PM -0500, Richard B. Johnson wrote:
Well they do! It's just not allowed for us (the users) to know that they
__didn't__ run completely out of power! If the thing is so dead
that it won't recharge, it still has 'power' (enough to keep static RAM
alive). Just
Hi,
On Thu, Jan 04, 2001 at 10:08:21PM +0100, Stefan Traby wrote:
On Thu, Jan 04, 2001 at 07:21:04PM +, Stephen C. Tweedie wrote:
ext3 does the recovery automatically during mount(8), so user space
will never see an unrecovered filesystem. (There are filesystem flags
set by the
"Stephen C. Tweedie" wrote:
On Wed, Jan 03, 2001 at 05:27:25PM +0100, Daniel Phillips wrote:
Tux2 is explicitly designed to legitimize pulling the plug as a valid
way of shutting down. Metadata-only journalling filesystems are not
designed to be used this way, and even with full-data
On Thu, Jan 04, 2001 at 10:49:46PM +, Stephen C. Tweedie wrote:
I think any other action (only replaying on rw mount and presenting
a broken filesystem on ro) is quite fatal, at least if I think of
a replay on -remount,rw :)
Correct.
Also, an unconditional hidden replay even if
On Thu, 4 Jan 2001, Alan Cox wrote:
From: Alan Cox [EMAIL PROTECTED]
Subject: Re: Journaling: Surviving or allowing unclean shutdown?
in an enbedded device you can
1. setup the power switch so it doesn't actually turn things off (it
issues the shutdown command instead)
Costs too
I have an old IBM Aptiva 486 SX that actually DOES something like this; what
it does is, it suspends to disk when you hit the power button (you have to
turn that option on though).
Point being, if it was possible back then (6 years ago), why on earth would
it be too expensive now?
I'd guess
Daniel writes:
Yes, and so long as your journal is not on another partition/disk things
will eventually be set right. The combination of a partially updated
filesystem and its journal is in some sense a complete, consistent
filesystem.
I'm curious - how does ext3 handle the possibility of
Stefan, you write:
[Re: read-only filesystem vs. read-only device]
Anyway, it is "especially" critical on the root filesystem because the
authors of filesystems can't support two ro states on boot.
Reiserfs allowed -oro,noreplay.
Please tell me how to specify "noreplay" for the initial
Alex Belits wrote:
>
> On Wed, 3 Jan 2001, Daniel Phillips wrote:
>
> > I don't doubt that if the 'power switch' method of shutdown becomes
> > popular we will discover some applications that have windows where they
> > can be hurt by sudden shutdown, even will full filesystem data state
> >
On Wed, 3 Jan 2001, Daniel Phillips wrote:
> Tux2 is explicitly designed to legitimize pulling the plug as a valid
> way of shutting down.
Hmm - that IMHO is a good thing; I'll have to look at Tux2.
> Metadata-only journalling filesystems are not
> designed to be used this way, and even with
On Wed, 3 Jan 2001, Daniel Phillips wrote:
> I don't doubt that if the 'power switch' method of shutdown becomes
> popular we will discover some applications that have windows where they
> can be hurt by sudden shutdown, even will full filesystem data state
> being preserved. Such applications
Rik van Riel wrote:
>
> On Wed, 3 Jan 2001, Dr. David Gilbert wrote:
>
> > I got wondering as to whether the various journaling file
> > system activities were designed to survive the occasional
> > unclean shutdown or were designed to allow the user to just pull
> > the plug as a regular
On Wed, Jan 03, 2001 at 01:26:18PM -0200, Rik van Riel wrote:
> On Wed, 3 Jan 2001, Dr. David Gilbert wrote:
>
> > I got wondering as to whether the various journaling file
> > system activities were designed to survive the occasional
> > unclean shutdown or were designed to allow the user to
> On Wed, 3 Jan 2001, Dr. David Gilbert wrote:
>
> > I got wondering as to whether the various journaling file
> > system activities were designed to survive the occasional
> > unclean shutdown or were designed to allow the user to just pull
> > the plug as a regular means of shutting down.
>
On Wed, 3 Jan 2001, Dr. David Gilbert wrote:
> I got wondering as to whether the various journaling file
> system activities were designed to survive the occasional
> unclean shutdown or were designed to allow the user to just pull
> the plug as a regular means of shutting down.
> Thoughts?
1 - 100 of 108 matches
Mail list logo
