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 t
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 a
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 n
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 ins
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
co
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 v
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 lef
[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
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 unt
> 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
> doe
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 read
[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 so
[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
> reaso
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
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 in
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 possibili
> 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 g
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
> &g
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
"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 f
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). Just
> > 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 - hi
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 mou
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 ab
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 Co
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 w
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 man
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 b
-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
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,
> j
-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,
jus
-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 essen
> 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 a
<[EMAIL PROTECTED]>, [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.
> 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
[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 the
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 shut down by h
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 p
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 t
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 d
[...]
> > 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
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
> > bei
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 f
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 a
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 mean
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 j
> 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?
Hi,
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?
Dave
--
/
55 matches
Mail list logo
