On Sat, Oct 11, 2003 at 02:56:49PM +1300, cr wrote: > On Fri, 10 Oct 2003 05:17, Pigeon wrote: > > 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'. 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? -- Pigeon Be kind to pigeons Get my GPG key here: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x21C61F7F
Attachment:
pgpkZ8DjROWcg.pgp
Description: PGP signature