How to kill X?
cr
reason, I could kill it with Alt-Ctrl-Backspace and end up back in the
command line. Very handy, since Linux is ~ 10^6 times more stable than X
;)
However, since I got more sophisticated hardware with an ATX power supply,
Ctrl-Alt-Backspace turns the machine off (or reboots it), with consequent
fscking of the drives, which is a pain.
I just had a sieze in X, and Ctrl-Alt-F? had no effect, Ctrl-Alt-Backspace
was the only key combination that worked. Is there any setting that will
restore its function of 'kill X but don't reboot the machine' or any other
key combination that achieves that?
cr
--
To UNSUBSCRIBE, email to debian-us...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Paul Johnson
Hash: SHA1
On Fri, Oct 03, 2003 at 11:37:19PM +1200, cr wrote:
> I just had a sieze in X, and Ctrl-Alt-F? had no effect, Ctrl-Alt-Backspace
> was the only key combination that worked. Is there any setting that will
> restore its function of 'kill X but don't reboot the machine' or any other
> key combination that achieves that?
Disable rebooting in the bios?
- --
.''`. Paul Johnson <ba...@ursine.ca>
: :' :
`. `'` proud Debian admin and user
`- Debian - when you have better things to do than fix a system
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
iD8DBQE/f+d5UzgNqloQMwcRAhQnAJ40ziuX5OD9cHmth3rhqP9gCrwofQCgk2r/
JqWrVYyEkBLMpN7L3mF7PMw=
=6HYc
-----END PGP SIGNATURE-----
Neo
> Way back in the days of RedHat 5 or thereabouts, whenever X siezed for any
> reason, I could kill it with Alt-Ctrl-Backspace and end up back in the
> command line. Very handy, since Linux is ~ 10^6 times more stable than X
> ;)
>
> However, since I got more sophisticated hardware with an ATX power supply,
> Ctrl-Alt-Backspace turns the machine off (or reboots it), with consequent
> fscking of the drives, which is a pain.
>
> I just had a sieze in X, and Ctrl-Alt-F? had no effect, Ctrl-Alt-Backspace
> was the only key combination that worked. Is there any setting that will
> restore its function of 'kill X but don't reboot the machine' or any other
> key combination that achieves that?
>
> cr
>
Hi,
try loging in remotely and run '/etc/init.d/<gkx>dm stop'.
(Fill in your running favorite display manager)
Sincerely,
Jan.
Kent West
>On Fri, 2003-10-03 at 13:37, cr wrote:
>
>
>>Way back in the days of RedHat 5 or thereabouts, whenever X siezed for any
>>reason, I could kill it with Alt-Ctrl-Backspace and end up back in the
>>command line.
>>
This is Debian's behaviour also.
>>However, since I got more sophisticated hardware with an ATX power supply,
>>Ctrl-Alt-Backspace turns the machine off (or reboots it), with consequent
>>fscking of the drives, which is a pain.
>>
>>
This is odd. I've never heard of such a thing. As someone else
mentioned, perhaps this is a key combination that your BIOS has reserved
for a reset, although I've never heard of such a BIOS.
>>I just had a sieze in X, and Ctrl-Alt-F? had no effect, Ctrl-Alt-Backspace
>>was the only key combination that worked. Is there any setting that will
>>restore its function of 'kill X but don't reboot the machine' or any other
>>key combination that achieves that?
>>
>>cr
>>
I did a google and found several people having the same problem; for example
http://www.cs.helsinki.fi/linux/linux-kernel/2002-48/0643.html
--
Kent
Pigeon
> On Fri, Oct 03, 2003 at 11:37:19PM +1200, cr wrote:
> > I just had a sieze in X, and Ctrl-Alt-F? had no effect, Ctrl-Alt-Backspace
> > was the only key combination that worked. Is there any setting that will
> > restore its function of 'kill X but don't reboot the machine' or any other
> > key combination that achieves that?
>
> Disable rebooting in the bios?
That'll stop the rebooting... however I have an unpleasant suspicion
that if the box is so wedged that Ctrl-Alt-F? doesn't work,
Ctrl-Alt-Backspace won't work either (I don't intend to try and induce
a seizure to verify this :-) ) - ie. the reason Ctrl-Alt-Backspace
'worked' was that the BIOS caught it. It may still be possible to log in
remotely and shut down; if not the best workaround until you can find
what's causing the seizures might be to use a journalling filesystem
like ext3.
--
Pigeon
Be kind to pigeons
Get my GPG key here: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F
cr
> Neo wrote:
> >On Fri, 2003-10-03 at 13:37, cr wrote:
> >>Way back in the days of RedHat 5 or thereabouts, whenever X siezed for
> >> any reason, I could kill it with Alt-Ctrl-Backspace and end up back in
> >> the command line.
>
> This is Debian's behaviour also.
>
> >>However, since I got more sophisticated hardware with an ATX power
> >> supply, Ctrl-Alt-Backspace turns the machine off (or reboots it), with
> >> consequent fscking of the drives, which is a pain.
>
> This is odd. I've never heard of such a thing. As someone else
> mentioned, perhaps this is a key combination that your BIOS has reserved
> for a reset, although I've never heard of such a BIOS.
After I posted my query, and before I read these, it did occur to me that it
might be a BIOS setting (as you suggest), and it was.
It's an Award BIOS, and I changed 'Hot Key Function' from 'Power Off' to
'Disable' (meaning, disable the hot key I presume). Nowhere in the BIOS
setup does it say what the hot key combination is, but I guess
Alt-Ctrl-Backspace is it.
Anyway, *now*, Ctrl-Alt-BS does indeed just kill X and leave me in Linux as
it should. However, whether it'll still work if X 'siezes' I'll only know
if and when I have a sieze.
Thanks
Chris
cr
> On Sun, Oct 05, 2003 at 02:42:17AM -0700, Paul Johnson wrote:
> > On Fri, Oct 03, 2003 at 11:37:19PM +1200, cr wrote:
> > > I just had a sieze in X, and Ctrl-Alt-F? had no effect,
> > > Ctrl-Alt-Backspace was the only key combination that worked. Is
> > > there any setting that will restore its function of 'kill X but don't
> > > reboot the machine' or any other key combination that achieves that?
> >
> > Disable rebooting in the bios?
>
> That'll stop the rebooting... however I have an unpleasant suspicion
> that if the box is so wedged that Ctrl-Alt-F? doesn't work,
> Ctrl-Alt-Backspace won't work either (I don't intend to try and induce
> a seizure to verify this :-) ) - ie. the reason Ctrl-Alt-Backspace
> 'worked' was that the BIOS caught it. It may still be possible to log in
> remotely and shut down; if not the best workaround until you can find
> what's causing the seizures might be to use a journalling filesystem
> like ext3.
Actually, thinking back on it, what I used to get way back then was not so
much a siezure of X as cascading errorboxes from one application... which
eventually, if left to continue, would hang the computer. Ctrl-Alt-BS
worked on that. What I had the other day was more like a sieze, everything
'locked up' (except Ctrl-Alt-BS which cut the power). Whether Ctrl-Alt-BS
will now work to drop me back to the command line, or just have no effect at
all (since I've now disabled the 'Hot Key Function' in the BIOS), I'll only
find out if and when I have another sieze.
I've only had one sieze in recent times, what I've had several of recently is
sudden complete power cut - possibly a power supply fault. Either way, it
has the same effect of discombobulating my hard drive so I have to do a lot
of fscking on startup again. Occasionally this completely munges my X
setup.
I was thinking the best precaution might be to occasionally copy /etc, /root
and maybe /home/cr (are those the appropriate directories?) to a directory
on another drive, which is unlikely to have files open at the time of a
crash, and just copy them back if I need to to restore my settings.
Kent West
>I've only had one sieze in recent times, what I've had several of recently is
>sudden complete power cut - possibly a power supply fault. Either way, it
>has the same effect of discombobulating my hard drive so I have to do a lot
>of fscking on startup again. Occasionally this completely munges my X
>setup.
>
You might consider converting your partitions to ext3. It's quite easy.
# tune2fs -j /
# tune2fs -j /home
# tune2fs -h /other_partitions_you_want_to_convert
Then edit /etc/fstab and change the "ext2" to "ext3" for each partition
on which you enabled a journal and reboot or remount those partitions.
The conversion only takes a few tens of seconds for each partition, and
you can always "back out" by simply changing your /etc/fstab back to
"ext2" and/or remounting as ext2 instead of ext3.
This of course won't completely protect against file system corruption
or the running of fsck, but it helps in my opinion.
--
Kent
Pim Bliek | PingWings.nl
> Then edit /etc/fstab and change the "ext2" to "ext3" for each partition
> on which you enabled a journal and reboot or remount those partitions.
> The conversion only takes a few tens of seconds for each partition, and
> you can always "back out" by simply changing your /etc/fstab back to
> "ext2" and/or remounting as ext2 instead of ext3.
DON'T forget to check that your kernel supports ext3 or that you load the
proper module at boot time. Otherwise your box will NOT boot after
changing fstab!
Pim
Pigeon
>
> I've only had one sieze in recent times, what I've had several of recently is
> sudden complete power cut - possibly a power supply fault. Either way, it
> has the same effect of discombobulating my hard drive so I have to do a lot
> of fscking on startup again. Occasionally this completely munges my X
> setup.
I think you might find ext3 to be a big help, though it's not a
complete solution - if the power dies in the middle of a write, you
can end up with a bad sector being created, which can confuse things a
bit.
> I was thinking the best precaution might be to occasionally copy /etc, /root
> and maybe /home/cr (are those the appropriate directories?) to a directory
> on another drive, which is unlikely to have files open at the time of a
> crash, and just copy them back if I need to to restore my settings.
I'd add /var to the list, and copy them onto a partition which can be
mounted read-only except when you're actually doing the copying.
Hmmm... you could have two such back-up partitions, and have a cron
job that backs up automatically to each one alternately every so
often. Then, even if it crashes during the backup, you've still got
the other copy.
A new PSU is probably a good idea too :-)
Mike Mueller
> On Fri, 2003-10-03 at 13:37, cr wrote:
> > I just had a sieze in X, and Ctrl-Alt-F? had no effect,
> > Ctrl-Alt-Backspace was the only key combination that worked. Is there
> > any setting that will restore its function of 'kill X but don't reboot
> > the machine' or any other key combination that achieves that?
>
> try loging in remotely and run '/etc/init.d/<gkx>dm stop'.
> (Fill in your running favorite display manager)
I had a long run of X siezures where I could remote in sometimes and
sometimes not. Sometimes I had to reset and fsck. No key sequences on the
siezed machine had any effect other than expressing my frustration.
FWIW, I changed my workstation from a machine with a crappy bare-bones video
card (Trident) to a machine with a less crappy bare bones video card (ATI
Rage something or another). That put a stop to the X siezures. Not an
elegant solution admittedly but I was able to run two desktops side by side
and compare stability. I was not able to find any direct evidence that
positively suggested that I should change video cards.
Good luck.
--
Mike Mueller
324881 (08/20/2003)
Make clockwise circles with your right foot.
Now use your right hand to draw the number "6" in the air.
cr
> On Sunday 05 October 2003 06:02, Neo wrote:
> > On Fri, 2003-10-03 at 13:37, cr wrote:
>
> <snip>
>
> > > I just had a sieze in X, and Ctrl-Alt-F? had no effect,
> > > Ctrl-Alt-Backspace was the only key combination that worked. Is
> > > there any setting that will restore its function of 'kill X but don't
> > > reboot the machine' or any other key combination that achieves that?
>
> <snip>
>
> > try loging in remotely and run '/etc/init.d/<gkx>dm stop'.
> > (Fill in your running favorite display manager)
>
> I had a long run of X siezures where I could remote in sometimes and
> sometimes not. Sometimes I had to reset and fsck. No key sequences on the
> siezed machine had any effect other than expressing my frustration.
>
> FWIW, I changed my workstation from a machine with a crappy bare-bones
> video card (Trident) to a machine with a less crappy bare bones video card
> (ATI Rage something or another). That put a stop to the X siezures. Not
> an elegant solution admittedly but I was able to run two desktops side by
> side and compare stability. I was not able to find any direct evidence
> that positively suggested that I should change video cards.
>
> Good luck.
Thanks. I might end up trying that video card solution because currently I
do have some suspicions of the on-board video chip (or whatever it is) on my
motherboard.
cr
cr
> On Tue, Oct 07, 2003 at 05:09:29AM +1300, cr wrote:
> > I've only had one sieze in recent times, what I've had several of
> > recently is sudden complete power cut - possibly a power supply fault.
> > Either way, it has the same effect of discombobulating my hard drive so I
> > have to do a lot of fscking on startup again. Occasionally this
> > completely munges my X setup.
>
> I think you might find ext3 to be a big help, though it's not a
> complete solution - if the power dies in the middle of a write, you
> can end up with a bad sector being created, which can confuse things a
> bit.
Are there any downsides to ext3?
> > I was thinking the best precaution might be to occasionally copy /etc,
> > /root and maybe /home/cr (are those the appropriate directories?) to a
> > directory on another drive, which is unlikely to have files open at the
> > time of a crash, and just copy them back if I need to to restore my
> > settings.
>
> I'd add /var to the list, and copy them onto a partition which can be
> mounted read-only except when you're actually doing the copying.
Thanks, I'll do that.
> Hmmm... you could have two such back-up partitions, and have a cron
> job that backs up automatically to each one alternately every so
> often. Then, even if it crashes during the backup, you've still got
> the other copy.
Well, that's a sort of second-order-of-probability, and a risk I'll take.
If that happens I'll just do the reinstall thing. ;)
> A new PSU is probably a good idea too :-)
The new PSU idea will get tried out next weekend when I can pick one up.
(It's cheaper than the other possibility which is trying out a new
motherboard + CPU :)
cr
Pigeon
> On Tue, 07 Oct 2003 07:04, Pigeon wrote:
> > On Tue, Oct 07, 2003 at 05:09:29AM +1300, cr wrote:
> > > I've only had one sieze in recent times, what I've had several of
> > > recently is sudden complete power cut - possibly a power supply fault.
> > > Either way, it has the same effect of discombobulating my hard drive so I
> > > have to do a lot of fscking on startup again. Occasionally this
> > > completely munges my X setup.
> >
> > I think you might find ext3 to be a big help, though it's not a
> > complete solution - if the power dies in the middle of a write, you
> > can end up with a bad sector being created, which can confuse things a
> > bit.
>
> Are there any downsides to ext3?
If you have a filesystem with a dirty journal you MUST try and replay
the journal, ie, fsck it, before doing anything else with it. If you
forget this you'll probably end up with worse damage than if you made
the same mistake with ext2. ext3 can be mounted as ext2 in emergency,
eg. if your rescue kernel hasn't got ext3 support, but don't be
tempted to mount it read-write.
There's also a slight speed hit. This will be the case with any
journalled filesystem as there is more writing involved. I'm a fan of
SCSI hard drives, and I like to set up ext3 with an external journal,
ie. on a different physical drive, which speeds things up a bit,
though at the cost of making your data twice as vulnerable to hard
drive failures (if the journal drive dies you're likely to end up with
an unfsckable mess on the data drive).
ext3 vs. reiser is a bit like emacs vs. vi. I haven't tried reiser, so
I won't comment on it.
> The new PSU idea will get tried out next weekend when I can pick one up.
> (It's cheaper than the other possibility which is trying out a new
> motherboard + CPU :)
It's worth noting that O(500MHz) PII/III machines are dumpster items
nowadays, but are still capable enough to be useful for trying that
sort of test before committing yourself.
cr
> On Thu, Oct 09, 2003 at 08:11:53PM +1300, cr wrote:
> > On Tue, 07 Oct 2003 07:04, Pigeon wrote:
> > > On Tue, Oct 07, 2003 at 05:09:29AM +1300, cr wrote:
> > > > I've only had one sieze in recent times, what I've had several of
> > > > recently is sudden complete power cut - possibly a power supply
> > > > fault. Either way, it has the same effect of discombobulating my hard
> > > > drive so I have to do a lot of fscking on startup again.
> > > > Occasionally this completely munges my X setup.
> > >
> > > I think you might find ext3 to be a big help, though it's not a
> > > complete solution - if the power dies in the middle of a write, you
> > > can end up with a bad sector being created, which can confuse things a
> > > bit.
> >
> > Are there any downsides to ext3?
>
> If you have a filesystem with a dirty journal you MUST try and replay
> the journal, ie, fsck it, before doing anything else with it. If you
> forget this you'll probably end up with worse damage than if you made
> the same mistake with ext2. ext3 can be mounted as ext2 in emergency,
> eg. if your rescue kernel hasn't got ext3 support, but don't be
> tempted to mount it read-write.
I think, with my capability for pushing the wrong button at critical
moments, I might be safer to stick with ext2 then.
> There's also a slight speed hit. This will be the case with any
> journalled filesystem as there is more writing involved. I'm a fan of
> SCSI hard drives, and I like to set up ext3 with an external journal,
> ie. on a different physical drive, which speeds things up a bit,
> though at the cost of making your data twice as vulnerable to hard
> drive failures (if the journal drive dies you're likely to end up with
> an unfsckable mess on the data drive).
>
> ext3 vs. reiser is a bit like emacs vs. vi. I haven't tried reiser, so
> I won't comment on it.
>
> > The new PSU idea will get tried out next weekend when I can pick one up.
> > (It's cheaper than the other possibility which is trying out a new
> > motherboard + CPU :)
>
> It's worth noting that O(500MHz) PII/III machines are dumpster items
> nowadays, but are still capable enough to be useful for trying that
> sort of test before committing yourself.
8-)
Quite true.
My motherboard is a 350MHz K6. If I have to upgrade it, I won't be too
upset, but the 350's fast enough for what I need so I there's no point fixing
it if it ain't broke. And I guess one big advantage is, I can afford to
risk breaking it ;)
Btw, I initially set up that DOS/Windoze drive I was talking about on my
spare machine - a 75MHz AMD K5. So what, it still works!
Pigeon
> On Thu, 09 Oct 2003 03:49, Pigeon wrote:
> > On Thu, Oct 09, 2003 at 08:11:53PM +1300, cr wrote:
> > > On Tue, 07 Oct 2003 07:04, Pigeon wrote:
> > > > On Tue, Oct 07, 2003 at 05:09:29AM +1300, cr wrote:
> > > > > I've only had one sieze in recent times, what I've had several of
> > > > > recently is sudden complete power cut - possibly a power supply
> > > > > fault. Either way, it has the same effect of discombobulating my hard
> > > > > drive so I have to do a lot of fscking on startup again.
> > > > > Occasionally this completely munges my X setup.
> > > >
> > > > I think you might find ext3 to be a big help, though it's not a
> > > > complete solution - if the power dies in the middle of a write, you
> > > > can end up with a bad sector being created, which can confuse things a
> > > > bit.
> > >
> > > Are there any downsides to ext3?
> >
> > If you have a filesystem with a dirty journal you MUST try and replay
> > the journal, ie, fsck it, before doing anything else with it. If you
> > forget this you'll probably end up with worse damage than if you made
> > the same mistake with ext2. ext3 can be mounted as ext2 in emergency,
> > eg. if your rescue kernel hasn't got ext3 support, but don't be
> > tempted to mount it read-write.
>
> I think, with my capability for pushing the wrong button at critical
> moments, I might be safer to stick with ext2 then.
Well, I admit that I found out about this the hard way. But I think
that was when I was running slink; the woody versions of the tools all
seem to spit out warnings if you try and treat ext3 as ext2.
AIUI running fsck on ext2 will return the filesystem to a logically
consistent state but doesn't guarantee that you won't lose or corrupt
any files - as you've found out. ext3's journalling is a big safeguard
against this. It is unfortunate that power failures are one area where
this safeguard is noticeably incomplete.
Roberto Sanchez
>>I think, with my capability for pushing the wrong button at critical
>>moments, I might be safer to stick with ext2 then.
>
>
> Well, I admit that I found out about this the hard way. But I think
> that was when I was running slink; the woody versions of the tools all
> seem to spit out warnings if you try and treat ext3 as ext2.
>
> AIUI running fsck on ext2 will return the filesystem to a logically
> consistent state but doesn't guarantee that you won't lose or corrupt
> any files - as you've found out. ext3's journalling is a big safeguard
> against this. It is unfortunate that power failures are one area where
> this safeguard is noticeably incomplete.
>
If you have and ext3 that you want to revert to ext2, you can just:
tune2fs -O ^has_journal /dev/hdXX
-Roberto
Monique Y. Herman
> If you have and ext3 that you want to revert to ext2, you can just:
>
> tune2fs -O ^has_journal /dev/hdXX
>
> -Roberto
Out of curiosity, why would one want to do this?
Also, you can always mount an ext3 drive as ext2 just by specifying the
type. In fact, I think mount will autodetect ext3 as ext2 -- you have
to explicitly ask for ext3-mounting.
--
monique
Unless you need to share ultra-sensitive super-spy stuff with me, please
don't email me directly. I will most likely see your post before I read
your mail, anyway.
Roberto Sanchez
> On Thu, 09 Oct 2003 at 22:49 GMT, Roberto Sanchez penned:
>
>>If you have and ext3 that you want to revert to ext2, you can just:
>>
>>tune2fs -O ^has_journal /dev/hdXX
>>
>>-Roberto
>
>
> Out of curiosity, why would one want to do this?
>
> Also, you can always mount an ext3 drive as ext2 just by specifying the
> type. In fact, I think mount will autodetect ext3 as ext2 -- you have
> to explicitly ask for ext3-mounting.
>
Right. But, the OP said something about sticking with ext2 instead of
ext3. I assumed that he already had an ext3 drive that he wanted to
make ext2.
-Roberto
Arnt Karlsen
Roberto Sanchez <rcsan...@yahoo.es> wrote in message
<3F85E5F3...@yahoo.es>:
> Pigeon wrote:
<attribution> On Fri, 10 Oct 2003 20:49:26 +1300,
<was> cr <c...@orcon.net.nz> wrote in message
<lost> <200310090742....@dbmail-mx1.orcon.co.nz>:
> > >
> > > I think, with my capability for pushing the wrong button at
> > > critical moments, I might be safer to stick with ext2 then.
> >
> > Well, I admit that I found out about this the hard way. But I think
> > that was when I was running slink; the woody versions of the tools
> > all seem to spit out warnings if you try and treat ext3 as ext2.
> >
> > AIUI running fsck on ext2 will return the filesystem to a logically
> > consistent state but doesn't guarantee that you won't lose or
> > corrupt any files - as you've found out. ext3's journalling is a big
> > safeguard against this. It is unfortunate that power failures are
> > one area where this safeguard is noticeably incomplete.
..amen! And those includes the wee ones, where the machines
keeps running, and gives the users _no_ useful warning.
In some cases, such as /var/log and var/spool, a panic is better than
data loss, for /usr, /etc, etc ;-) , running read-only is acceptable,
and
in some eerie cases, "errors=continue" is used.
> If you have and ext3 that you want to revert to ext2, you can just:
>
> tune2fs -O ^has_journal /dev/hdXX
..and then 'fsck -y /dev/hdXX ; tune2fs -O has_journal /dev/hdXX ',
which _is_ the right thing to do, whenever the journal is wrong.
.._is_ this possible to do without reboots?
--
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
Scenarios always come in sets of three:
best case, worst case, and just in case.
Monique Y. Herman
>
> Right. But, the OP said something about sticking with ext2 instead of
> ext3. I assumed that he already had an ext3 drive that he wanted to
> make ext2.
>
> -Roberto
>
Ah. I didn't read it like that, but maybe he did.
Pigeon
> Monique Y. Herman wrote:
> >On Thu, 09 Oct 2003 at 22:49 GMT, Roberto Sanchez penned:
> >
> > >If you have and ext3 that you want to revert to ext2, you can just:
> > >
> > >tune2fs -O ^has_journal /dev/hdXX
> > >
> > >-Roberto
...be sure the journal is clean first though, and if you have to force
it with -f be sure you know what you're doing.
> >Out of curiosity, why would one want to do this?
One example: if you have an external journal and the drive with that
on goes bad. (Though you would probably immediately follow it with
attaching a new journal on a different drive.)
> >Also, you can always mount an ext3 drive as ext2 just by specifying the
> >type. In fact, I think mount will autodetect ext3 as ext2 -- you have
> >to explicitly ask for ext3-mounting.
# mount /dev/hda2 /mnt -o ro
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
#
Again, don't do this with a dirty journal.
> Right. But, the OP said something about sticking with ext2 instead of
> ext3. I assumed that he already had an ext3 drive that he wanted to
> make ext2.
No, he has an ext2 drive which he is wondering whether to make ext3.
cr
Thanks everybody for your input.
As it happens, all my partitions are ext2 at the moment (except for some
FAT16's but we needn't go into that ;)
I'm contemplating swapping some of 'em to ext3, I was just wondering if the
pluses outweight the minuses. It appears as if they do.
It does reassure me, though, that if I happen to run/install a kernel that
doesn't have ext3, I can use ext2 if necessary.
Regards
cr (the OP)
Monique Y. Herman
>
> Thanks everybody for your input.
>
> As it happens, all my partitions are ext2 at the moment (except for
> some FAT16's but we needn't go into that ;)
>
> I'm contemplating swapping some of 'em to ext3, I was just wondering
> if the pluses outweight the minuses. It appears as if they do.
>
> It does reassure me, though, that if I happen to run/install a kernel
> that doesn't have ext3, I can use ext2 if necessary.
>
> Regards
>
> cr (the OP)
>
There was a link to an article on slashdot today comparing various
journaling FSes. Apparently (I just read the comments, not the actual
article, like the typical /. reader), ext3 is pretty much el crapola
compared to the rest of them when it comes to performance. But for me,
my machine doesn't need to be bleeding-edge fast; I would much prefer
the reassurance that I can boot off of just about anything and have my
drive be recognized.
OTOH, I just was told by my fiance, who follows the linux kernel mailing
list (and if you think this place is busy ...) and says that the study
was not all that reliable. So ... eh, whatever. ext3 has been working
for me for about a year or so.
--
monique
Unless you need to share ultra-sensitive super-spy stuff with me, please
don't email me directly. I will most likely see your post before I read
your mail, anyway.
Tim Connors
> There was a link to an article on slashdot today comparing various
> journaling FSes. Apparently (I just read the comments, not the actual
> article, like the typical /. reader), ext3 is pretty much el crapola
> compared to the rest of them when it comes to performance.
You might want to have read all of the replies to these comments then :)
Not a case of ext3 being crap, a case of ext3 with journalled *data*
being crap. Quite a nice allrounder with the other two ext3 options
set. And you get the same problems with all other fses when their
equivalent of journalled *data* was turned on (if they had such a
feature).
I have been using ext3 just fine on all of my drives since.... 2 years
ago? One even has many bad sectors, and is not repairable by
reformatting, but it's only a disk in a 486 that is never used :)
The comment made earlier about bad sectors when power is turned off is
a comments that can be made about any fs, not just ext3, and is a
function of what drive you are using. It affects the IBM DTLA drives,
because the motor slows down, but doesn't cut off the write head when
power is cut, so the sector gets corrupted, and the drive is not smart
enough to repair this upon power being reapplied, even if you try to
write to that sector again without reading it first. Moral of that
story: Stay away from IBM drives in general, given their incompetance
in other matters (think, IBM DeathStar, etc).
--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
"Eddies in the space time continuum"
"Oh. Is he?" -- Zem?
JOS...@telefonica.net
I can't startup my machine...
José Salavert Torres
> How can I clean a dirty journal???
> I can't startup my machine...
Well I have done:
tune2fs -O as_journal /dev/hdxx
Now everithing goes properly, It seems that the ext3 , is not that safe.
Another tip is that my system mounts it as ext3 (fstab says).
Does this mean that the system has rebuilt the journal table???
Monique Y. Herman
>
> Not a case of ext3 being crap, a case of ext3 with journalled *data*
> being crap. Quite a nice allrounder with the other two ext3 options
> set. And you get the same problems with all other fses when their
> equivalent of journalled *data* was turned on (if they had such a
> feature).
I read that but didn't understand it. Is it that you can use ext3
without journalling? Or is journalling data different from normal
journalling somehow? I'm confused.
> The comment made earlier about bad sectors when power is turned off is
> a comments that can be made about any fs, not just ext3, and is a
> function of what drive you are using. It affects the IBM DTLA drives,
> because the motor slows down, but doesn't cut off the write head when
> power is cut, so the sector gets corrupted, and the drive is not smart
> enough to repair this upon power being reapplied, even if you try to
> write to that sector again without reading it first. Moral of that
> story: Stay away from IBM drives in general, given their incompetance
> in other matters (think, IBM DeathStar, etc).
I heard about the deathstars and told myself I'd check my model number
"eventually." Then one day my OS started behaving *really* weirdly,
while at the same time the hard drive started making really ...
interesting noises. It turned out to be a deathstar. Fortunately, that
machine wasn't being used for anything terribly important, and the drive
was still under warranty (back when 3-year warranties were standard), so
it was only a minor annoyance.
--
monique
Unless you need to share ultra-sensitive super-spy stuff with me, please
don't email me directly. I will most likely see your post before I read
your mail, anyway.
cr
> On Fri, Oct 10, 2003 at 08:49:26PM +1300, cr wrote:
> > On Thu, 09 Oct 2003 03:49, Pigeon wrote:
> > > On Thu, Oct 09, 2003 at 08:11:53PM +1300, cr wrote:
(snip)
> > > >
> > > > Are there any downsides to ext3?
> > >
> > > If you have a filesystem with a dirty journal you MUST try and replay
> > > the journal, ie, fsck it, before doing anything else with it. If you
> > > forget this you'll probably end up with worse damage than if you made
> > > the same mistake with ext2. ext3 can be mounted as ext2 in emergency,
> > > eg. if your rescue kernel hasn't got ext3 support, but don't be
> > > tempted to mount it read-write.
> >
> > I think, with my capability for pushing the wrong button at critical
> > moments, I might be safer to stick with ext2 then.
>
> Well, I admit that I found out about this the hard way. But I think
> that was when I was running slink; the woody versions of the tools all
> seem to spit out warnings if you try and treat ext3 as ext2.
>
> AIUI running fsck on ext2 will return the filesystem to a logically
> consistent state but doesn't guarantee that you won't lose or corrupt
> any files - as you've found out. ext3's journalling is a big safeguard
> against this. It is unfortunate that power failures are one area where
> this safeguard is noticeably incomplete.
It seems to me that, since X is running on top of Linux, keyboard input must
go to linux first then to X, and therefore it should be possible to program
some keystroke combination (e.g. Alt-Ctrl-Backspace, though I still don't
know if that works in the event of an X siezure) that would either tell Linux
to just kill X or even, in dire emergency, tell Linux to 'unmount all drives
*now* and shut down'.
This would be handy since in my (limited) experience, X is often a bit shaky
whereas Linux is rock-solid. It would also be handy in cases of e.g.
monitor failure or video card glitches etc. (I'm running a standalone on a
dial-up modem so telnetting in, as someone suggested, isn't really practical
for me).
But I'm no programmer so I don't know.
Geordie Birch
> Anyway, *now*, Ctrl-Alt-BS does indeed just kill X and leave me in Linux as
> it should. However, whether it'll still work if X 'siezes' I'll only know
> if and when I have a sieze.
Check out the magic sysreq key. With its secure access key you can
kill all processes running on the current VT. This will likely leave the
keyboard in raw mode (which is easy to fix with the magic sysreq key)
and the video modes borked (which is *possibly* fixable with mode3 or
restoretextmode.) I have successfully used this method in the past when
X was unzappable and otherwise hung.
Anyone know an easy way to force X 4.2 to to hang?
Geordie.
Pigeon
Well, there's always Ctrl-Alt-Del (which you can redefine in
/etc/inittab to do whatever you want), and /etc/inittab also lets you
define one other hot-key action. (Quite why we are limited to two "hot
keys" I don't know.) Or you can build a kernel with CONFIG_MAGIC_SYSRQ
set, to give you a little bit of control even when the machine's
screwed itself up badly (or just to give you the satisfaction of
having the "SysRq" key actually do something :-) ).
> This would be handy since in my (limited) experience, X is often a bit shaky
> whereas Linux is rock-solid.
Yeah. The reasoning behind not running X apps as root is similar.
> It would also be handy in cases of e.g.
> monitor failure or video card glitches etc. (I'm running a standalone on a
> dial-up modem so telnetting in, as someone suggested, isn't really practical
> for me).
Well, you could enable "support for console on serial port" and grab
an old teletype from a surplus store... then you'd have a printed
record of what you did to try and unscrew the system, which could be
quite valuable :-)
> But I'm no programmer so I don't know.
Well, you figured it pretty close.
It does seem, though, that for doing anything more complicated, "hot
keys" in the console are one area which Linux isn't very good at.
Keyboard input goes right to the process that's reading it, and there
doesn't seem to be a generally-applicable method of intercepting it
without patching something. There's no "raw keyboard device" you can
peek at, and you can't make one without patching the kernel to allow
sharing of the keyboard interrupt - an utterly trivial patch, but
enough to destroy portability. I suppose you could have a daemon
polling the keyboard input port, but I'd rather not.
I googled on this at some length a while ago, and found: 1) untold
thousands of pages saying "a daemon is what you have in Linux instead
of a TSR in DOS" but giving no clue as to how to make your magic key
combination wake it up; 2) a couple of references to the keyboard
request function in /etc/inittab with which you can define _one_ hot
key apart from Ctrl-Alt-Del; and 3) one very skeletal raw keyboard
device driver with kernel patch, given as a coding example in a kernel
programming lecture.
It does seem strange to me that the keyboard is the "odd man out" of
devices - every other I/O device has a /dev entry, but the keyboard
does not.
Interestingly, there is a /dev/kbd on Linux SPARC - I wonder what's
different about SPARC architecture to cause that?
Jacob Anawalt
> On Fri, 10 Oct 2003 at 11:09 GMT, Tim Connors penned:
>
>>Not a case of ext3 being crap, a case of ext3 with journalled *data*
>>being crap. Quite a nice allrounder with the other two ext3 options
>>set. And you get the same problems with all other fses when their
>>equivalent of journalled *data* was turned on (if they had such a
>>feature).
>
>
> I read that but didn't understand it. Is it that you can use ext3
> without journalling? Or is journalling data different from normal
> journalling somehow? I'm confused.
>
I believe they are referring to the type of journaling being done. The
default on Woody 2.4.18-bf2.4 (and RH7.3) is data=ordered. With the
first version of ext3 or if you are using data=journal, the data is
written to the journal and then to the normal location on the file
system. With data=ordered only metadata is written to the journal but it
guarentees that it won't commit transactions until the real data has hit
the disk.
This is a pretty good EXT3 faq
http://batleth.sapienti-sat.org/projects/FAQs/ext3-faq.html
If I am rememering correctly other journaling file systems journal
metadata as well. It is obviously a larger performance hit to write the
same data twice; data=ordered avoids that and still gives good
journaling protection. As fhe FAQ points out, you could use
data=writeback for even less of a runtime performance hit with a faster
fsck recovery than ext2.
It was my understanding that ext3 is ext2 with some additional structure
information (within the space allocated for such things by ext2, so 100%
reverse compatable) and a journal file. I hadn't heard anything about
needing to be careful about mounting rw with a "dirty journal" before
this thread. That is something that I'll read into.
I've been using ext3 since it shipped standard on RH with version2
data=ordered. That's been at least a year and a half (probably longer)
and I've never had a problem on the dozen machines I've run it on. Ext2,
while not extreme in any performance spec, has been a reliable Linux FS,
and ext3 just builds onto that. I don't loose any sleep over any data I
put on it, and I have yet to fret over how it affects dsk I/O on any of
the servers.
--
Jacob