* Re: Htree ate my hard drive, was: post-halloween 0.2
@ 2002-10-31 11:19 Petr Vandrovec
2002-10-31 21:42 ` [Ext2-devel] " chrisl
2002-10-31 22:03 ` Theodore Ts'o
0 siblings, 2 replies; 6+ messages in thread
From: Petr Vandrovec @ 2002-10-31 11:19 UTC (permalink / raw)
To: Duncan Sands; +Cc: Linux Kernel, ext2-devel, adilger
On 31 Oct 02 at 9:20, Duncan Sands wrote:
> > I wonder if there is still a bug in the e2fsck code for re-hashing
> > directories? It shouldn't be possible to have e2fsck complete and
> > there still be an error in the filesystem (ok, sometimes it happens,
> > but in those cases it spews a lot of warnings about the filesystem
> > not being fixed yet and to run manually).
>
> It is possible that the filesystem was fine when fsck completed, but
> was damaged afterwards, i.e. in the time between fsck completing
> and the reboot.
Just stupid idea. Two or three months ago I complained that if
my box crashes shortly after boot, following things happen:
(1) system for some reason reads /var/run directory to page cache
(2) fsck finds that /var/run/* entries points to invalid nodes, and
removes them (through block device access)
(4) / is remounted read-write
(5) because of page cache for block device and directory is not
coherent (or what...), system still sees /var/run/* populated
(6) rm /var/run/* is run. FS is remounted read-only due to
freeing inode already freeed...
(7) Reboot, run fsck again, reboot, fine...
Nobody answered it at that time, and it happened at least 5 times
again to me - until I modified initscripts to do unconditional
reboot if "fsck /" did ANY modifications to filesystem.
Maybe kernel still uses old directory indexes structure after
fsck created new one?
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [Ext2-devel] Re: Htree ate my hard drive, was: post-halloween 0.2
2002-10-31 11:19 Htree ate my hard drive, was: post-halloween 0.2 Petr Vandrovec
@ 2002-10-31 21:42 ` chrisl
2002-10-31 22:03 ` Theodore Ts'o
1 sibling, 0 replies; 6+ messages in thread
From: chrisl @ 2002-10-31 21:42 UTC (permalink / raw)
To: Petr Vandrovec; +Cc: Duncan Sands, Linux Kernel, ext2-devel, adilger
On Thu, Oct 31, 2002 at 01:19:23PM +0200, Petr Vandrovec wrote:
> On 31 Oct 02 at 9:20, Duncan Sands wrote:
> > > I wonder if there is still a bug in the e2fsck code for re-hashing
> > > directories? It shouldn't be possible to have e2fsck complete and
> > > there still be an error in the filesystem (ok, sometimes it happens,
> > > but in those cases it spews a lot of warnings about the filesystem
> > > not being fixed yet and to run manually).
> >
> > It is possible that the filesystem was fine when fsck completed, but
> > was damaged afterwards, i.e. in the time between fsck completing
> > and the reboot.
>
> Just stupid idea. Two or three months ago I complained that if
> my box crashes shortly after boot, following things happen:
>
> (1) system for some reason reads /var/run directory to page cache
> (2) fsck finds that /var/run/* entries points to invalid nodes, and
> removes them (through block device access)
> (4) / is remounted read-write
> (5) because of page cache for block device and directory is not
> coherent (or what...), system still sees /var/run/* populated
> (6) rm /var/run/* is run. FS is remounted read-only due to
> freeing inode already freeed...
> (7) Reboot, run fsck again, reboot, fine...
>
> Nobody answered it at that time, and it happened at least 5 times
> again to me - until I modified initscripts to do unconditional
> reboot if "fsck /" did ANY modifications to filesystem.
>
> Maybe kernel still uses old directory indexes structure after
> fsck created new one?
File system needs to unmount and remount after e2fsck packed
directory index. Kernel need to trash all the dentry cache of
that file system. If you pack the "/". It'd better reboot.
Chris
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Ext2-devel] Re: Htree ate my hard drive, was: post-halloween 0.2
2002-10-31 11:19 Htree ate my hard drive, was: post-halloween 0.2 Petr Vandrovec
2002-10-31 21:42 ` [Ext2-devel] " chrisl
@ 2002-10-31 22:03 ` Theodore Ts'o
1 sibling, 0 replies; 6+ messages in thread
From: Theodore Ts'o @ 2002-10-31 22:03 UTC (permalink / raw)
To: Petr Vandrovec; +Cc: Duncan Sands, Linux Kernel, ext2-devel, adilger
On Thu, Oct 31, 2002 at 01:19:23PM +0200, Petr Vandrovec wrote:
>
> Nobody answered it at that time, and it happened at least 5 times
> again to me - until I modified initscripts to do unconditional
> reboot if "fsck /" did ANY modifications to filesystem.
>
In fact, e2fsck should return an exit code which indicates that the
systme should be rebooted if an fsck the root filesystem makes any
changes to the filesystem. See the man page to fsck(8) for a
definition of fsck's exit codes, but if (exit_status & 2) is non-zero,
the init scripts **should** reboot.
Unfortunately, not all distributions get this right. However, your
analysis is right. If fsck needs to make any modifications to the
root filesystem, which is mounted read-only, it is possible for the
corrupted filesystem elements to still be cached in memory, and then
written back out to disk when the filesystem is remounted read/write.
This is one reason why I normally recommend that / be a small
filesystem of approximately 128 megs, with separate partitions for
/usr, and either using a separate partition for /var, or using a
symlink from /usr/var to /var. (And doing something similar for /home
and and /opt, as necessary.) It minimizes the chances that the root
filesystem will get corrupted, and makes running fsck on the root
filesystem take much less time (obviously, since the root filesystem
becomes quite small.)
- Ted
^ permalink raw reply [flat|nested] 6+ messages in thread
* post-halloween 0.2
@ 2002-10-30 17:11 Dave Jones
2002-10-31 6:27 ` Htree ate my hard drive, was: " Duncan Sands
0 siblings, 1 reply; 6+ messages in thread
From: Dave Jones @ 2002-10-30 17:11 UTC (permalink / raw)
To: Linux Kernel
I updated the list of various things that wannabe testers might hit.
If theres something I missed let me know, and I'll get it right
next time round..
Dave
The post-halloween document. v0.2
(aka, 2.5 - what to expect)
Dave Jones <davej@codemonkey.org.uk>
This document explains some of the new functionality to be found in the 2.5
Linux kernel, some pitfalls you may encounter, and also points out some new
features which could really use testing.
Note, that "contact foo@bar.com" below also implies that you should also
cc: linux-kernel@vger.kernel.org.
Latest version of this document can always be found at
http://www.codemonkey.org.uk/post-halloween-2.5.txt
Regressions:
~~~~~~~~~~~~
(Things not expected to work just yet)
- The hptraid/promise RAID drivers are currently non functional.
- Various SCSI drivers still need work, and don't even compile.
- software suspend is still in development, and in need of more work.
It is unlikely to work as expected currently.
- Some filesystems still need work (Coda, Intermezzo).
Deprecated features:
~~~~~~~~~~~~~~~~~~~~
- khttpd is gone.
- Older Direct Rendering Manager (DRM) support (For XFree86 4.0)
has been removed. Upgrade to XFree86 4.1.0 or higher.
IO subsystem.
~~~~~~~~~~~~~
You should notice considerable throughput improvements over 2.4 due
to much reworking of the block and the memory management layers.
Report any regressions in this area to Jens Axboe <axboe@suse.de>
and Andrew Morton <akpm@digeo.com>.
Assorted changes throughout the block layer meant various block
device drivers had a large scale cleanup whilst being updated to
newer APIs.
Kernel preemption.
~~~~~~~~~~~~~~~~~~
The much talked about preemption patches made it into 2.5.
With this included you should notice much lower latencies especially
in demanding multimedia applications.
Note, there are still cases where preemption must be temporarily disabled
where we do not. If you get "xxx exited with preempt count=n" messages
in syslog, don't panic, these are non fatal, but are somewhat unclean.
Report such cases (and any other preemption related problems) to
rml@tech9.net
O(1) Scheduling improvements.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Another much talked about feature. Ingo Molnar reworked the process
scheduler to use an O(1) algorithm. In operation, you should notice
no changes with low loads, and increased scalability with large numbers
of processes, especially on large SMP systems. Regressions to mingo@redhat.com
Input layer
~~~~~~~~~~~
Possibly the most visible change to the end user. If misconfigured,
you'll find that your keyboard/mouse/other input device will no longer work.
2.5 offers a much more flexable interface to devices such as keyboards.
The downside is more confusing options.
In the "Input device support" menu, be sure to enable at least the following.
--- Input I/O drivers
< > Serial i/o support
< > i8042 PC Keyboard controller
[ ] Keyboards
[ ] Mice
(Also choose the relevant keyboard/mouse from the list)
If you find your keyboard/mouse still don't work, edit the file
drivers/input/serio/i8042.c, and replace the #undef DEBUG
with a #define DEBUG
When you boot, you should now see a lot more debugging information.
Forward this information to Vojtech Pavlik <vojtech@suse.cz>
If you use a KVM switcher, and experience problems, booting
with the boot time argument 'psmouse_noext' should fix your
problems.
PnP layer
~~~~~~~~~
Support for plug and play devices such as early ISAPNP cards has
improved a lot in the 2.5 kernel. You should no longer need to
futz with userspace tools to configure IRQ's and the likes.
Report any regressions in plug & play functionality to
Adam Belay <ambx1@neo.rr.com>
ALSA
~~~~
The advanced linux sound architecture got merged into 2.5.
This offers considerably improved functionality over the
older OSS drivers, but requires new userspace tools.
Several distros have shipped ALSA for some time, so you
may already have the necessary tools. If not, you can find them
at http://www.alsa-project.org/
(Note that the OSS drivers are also still functional, and
still present)
procps
~~~~~~
The 2.5 /proc filesystems exports more statistics, which confuse
older versions of procps. Rik van Riel and Robert Love have
been maintaining a forked version of procps during the 2.5 cycle,
which you can find at http://tech9.net/rml/procps/
Framebuffer layer
~~~~~~~~~~~~~~~~~
James Simmons has reworked the framebuffer/console layer
considerably during 2.5. Support for some cards is still
lagging a little, but it should be functionally no different
than previous incarnations.
IDE
~~~
The IDE code was subject to much criticism in early 2.5.x, which
put off a lot of people from testing. This work was then subsequently
dropped, and reverted back to a 2.4.18 IDE status.
(Since then additional work has occured, but not to the extent
of the first cleanup attempts).
Additional work on the ATA code is happening in 2.4-ac, and pending
merging to 2.5
IDE TCQ
~~~~~~~
Tagged command queueing for IDE devices has been included.
Not all devices may like this, so handle with care.
If you didn't choose the "TCQ on by default" option,
you can enable it by using the command
echo "using_tcq:32" > /proc/ide/hdX/settings
(replacing 32 with 0 disables TCQ again).
Report success/failure stories to Jens Axboe <axboe@suse.de> with
inclusion of hdparm -i /dev/hdX
v4l2
~~~~
The video4linux API finally got its long awaited cleanup.
xawtv, bttv and most other existing v4l tools are also compatable
with the new v4l2 layer. You should notice no loss in functionality.
http://bytesex.org/v4l/
Quota reworking
~~~~~~~~~~~~~~~
The new quota system needs new tools.
ftp://atrey.karlin.mff.cuni.cz/pub/local/jack/quota/utils/alpha/quota-3.05-pre1.tar.gz
CD Recording
~~~~~~~~~~~~
Jens Axboe added the ability to use DMA for writing CDs on
ATAPI devices. Writing CDs should be much faster than it
was in 2.4, and also less prone to buffer underruns and the like.
Updated cdrecord in rpm and tar.gz can be found at
*.kernel.org/pub/linux/kernel/people/axboe/tools/
With the above tools, you also no longer need ide-scsi
in order to use an IDE CD writer.
Ripping audio tracks off of CDs now also uses DMA and should
be notably faster. You can also find an updated cdda2wav
at the same location.
Send good/bad reports of audio extraction with cdda2wav
and burning with cdrecord to Jens Axboe <axboe@suse.de>
More info at http://lwn.net/Articles/13538/ & http://lwn.net/Articles/13160/
Filesystems:
~~~~~~~~~~~~
A number of additional filesystems have made their way into 2.5.
Whilst these have had testing out of tree, the level of testing
after merging is unparalleled. Be wary of trusting data to immature
filesystems. A number of new features and improvements have also
been made to the existing filesystems from 2.4.
Reports of stress testing with the various tools available would
be beneficial.
NFS
~~~
Support has been added for NFSv4 (server and client), and additionally,
NFS over TCP. Reports of interoperability with other OS's would be useful.
driverfs
~~~~~~~~
In simple terms, the driverfs filesystem is a saner way for
drivers to export their innards than /proc.
This filesystem is always compiled in, and can be mounted
just like another virtual filesystem. No userspace tools
beyond cat and echo are needed.
mount -t driverfs none /sys
*NB*, at some point the name of this filesystem will be changing to sysfs.
See Documentation/filesystems/sysfs.txt for more info.
XFS
~~~
The SGI XFS filesystem has been merged, and has a number of userspace
features. Users are encouraged to read http://oss.sgi.com/project
for more information.
The various utilties for creating and manipulating XFS volumes can
be found on SGI's ftp server..
ftp://oss.sgi.com/projects/xfs/download/download/cmd_tars/xfsprogs-2.2.2.src.tar.gz
CIFS
~~~~
Support utilities and documentation for the common internet file system (CIFS)
can be found at http://us1.samba.org/samba/Linux_CIFS_client.html
EXT3 Htree support.
~~~~~~~~~~~~~~~~~~~
The ext3 filesystem has gained indexed directory support, which offers
considerable performance gains when used on filesystems with large directories.
In order to use the htree feature, you need at least version 1.29 of e2fsprogs.
Existing filesystems can be converted using the command "tune2fs -O dir_index /dev/hdXXX"
The latest e2fsprogs can be found at http://prdownloads.sourceforge.net/e2fsprogs
Oprofile.
~~~~~~~~~
A system wide performance profiler has been included in 2.5.
The userspace utilities for this are very young, and still being developed.
You can find out more at http://oprofile.sourceforge.net/oprofile-2.5.html
Simple boot flag support.
~~~~~~~~~~~~~~~~~~~~~~~~~
The SBF specification is an x86 BIOS extension that allows improved
system boot speeds. It does this by marking a CMOS field to say
"I booted okay, skip extensive POST next reboot".
Userspace tool is at http://www.codemonkey.org.uk/cruft/sbf-0.3.c
More info on SBF is at http://www.microsoft.com/hwdev/resources/specs/simp_bios.asp
x86 CPU detection.
~~~~~~~~~~~~~~~~~~
The CPU detection code got a pretty hefty shake up. To be certain your
CPU has all relevant workarounds applied, be sure to check that it was
detected correctly. cat /proc/cpuinfo will tell what the kernel thinks it is.
Likewise, the x86 MTRR driver got a considerable makeover.
Any regressions in both should go to mochel@osdl.org
Extra tainting.
~~~~~~~~~~~~~~~
Running certain AMD processors in SMP boxes is out of spec, and will taint
the kernel with the 'S' flag. Running 2 Athlon XPs for example may seem to
work fine, but may also introduce difficult to pin down bugs.
In time it's likely this tainting will be extended to cover other out of
spec cases.
Power management.
~~~~~~~~~~~~~~~~~
2.5 contains a more up to date snapshot of the ACPI driver. Should
you experience any problems booting, try booting with the argument
"acpi=off" to rule out any ACPI interaction. ACPI has a much more involved
role in bringing the system up in 2.5 than it did in 2.4
The old "acpismp=force" boot option is now obsolete, and will be ignored
due to the old "mini ACPI" parser being removed.
CPU frequency scaling.
~~~~~~~~~~~~~~~~~~~~~~
Certain processors have the facility to scale their voltage/clockspeed.
2.5 introduces an interface to this feature, see Documentation/cpufreq
for more information. This functionality also covers features like
Intel's speedstep, and will be extended in time to cover the Powernow
feature present in mobile Athlons.
Background polling of MCE
~~~~~~~~~~~~~~~~~~~~~~~~~
The machine check handler has been extended so that it regularly polls
for any problems on AMD Athlon systems. This may result in machine check
exceptions occuring more frequently than they did in 2.4 on out of spec
systems (Overclocking/poor cooling/underated PSU etc..).
LVM2 - DeviceMapper.
~~~~~~~~~~~~~~~~~~~~
The LVM code got a massive overhaul (read as: replacement).
This means new tools are needed to manage the device mapper.
You can get these from ftp://ftp.sistina.com/pub/LVM2/tools/
Debugging options.
~~~~~~~~~~~~~~~~~~
During the stabilising period, it's likely that the debugging options
in the kernel hacking menu will trigger quite a few problems.
Please report any of these problems to linux-kernel@vger.kernel.org
rather than just disabling the relevant CONFIG_ options.
TODO
~~~~
- Reiser4 ?
http://www.namesys.com/snapshots/2002.10.29/reiser4progs-0.1.0.tar.gz
- ipsec ?
- ebtables
- compilers
When compiled with a modern gcc (Ie gcc 3.x), 2.5 will use additional
optimisations that 2.4 didn't. This may shake out compiler bugs that
2.4 didn't expose. The recommended compiler is still 2.95.3.
- boot time root= parsing changed.
ramdisks now have ram<n> isntead of rd<n> and cm206 - cm206cd (instead of cm206).
--
| Dave Jones. http://www.codemonkey.org.uk
^ permalink raw reply [flat|nested] 6+ messages in thread* Htree ate my hard drive, was: post-halloween 0.2
2002-10-30 17:11 Dave Jones
@ 2002-10-31 6:27 ` Duncan Sands
2002-10-31 8:07 ` Andreas Dilger
0 siblings, 1 reply; 6+ messages in thread
From: Duncan Sands @ 2002-10-31 6:27 UTC (permalink / raw)
To: Dave Jones, Linux Kernel
> EXT3 Htree support.
> ~~~~~~~~~~~~~~~~~~~
> The ext3 filesystem has gained indexed directory support, which offers
> considerable performance gains when used on filesystems with large
> directories. In order to use the htree feature, you need at least version
> 1.29 of e2fsprogs. Existing filesystems can be converted using the command
> "tune2fs -O dir_index /dev/hdXXX" The latest e2fsprogs can be found at
> http://prdownloads.sourceforge.net/e2fsprogs
I ran this (tune2fs -O dir_index /dev/hdXXX).
After a bit of switching back and forth between 2.4.19 and 2.5.44,
fsck was run while booting 2.4.19 (the usual check because of >30
mounts). There was a message about optimizing directories. Booting
continued but (big surprise) X refused to run. It turned out that some
device files had vanished. Very strange. On rebooting, fsck found a
gazillion bad inodes. They all turned out to be from the 2.5.44 tree -
poetic justice I suppose! But this did not suffice. Rebooting, I got
"optimizing directories" again. Next fsck showed up more dud inodes.
After a few cycles of this, I ran
tune2fs -O ^dir_index /dev/hdXXX
to remove htree support. No problems since then.
Duncan.
PS: UP, no preempt.
tune2fs 1.30-WIP (30-Sep-2002)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: ee433ceb-6b14-45b1-894c-2a8aad1e280f
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal needs_recovery
Filesystem state: clean
Errors behavior: Unknown (continue)
Filesystem OS type: Linux
Inode count: 290816
Block count: 2315368
Reserved block count: 115768
Free blocks: 871842
Free inodes: 36718
First block: 0
Block size: 4096
Fragment size: 4096
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 4096
Inode blocks per group: 128
Last mount time: Thu Oct 31 06:37:46 2002
Last write time: Thu Oct 31 06:37:46 2002
Mount count: 7
Maximum mount count: 30
Last checked: Wed Oct 30 11:50:37 2002
Check interval: 0 (<none>)
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Journal UUID: <none>
Journal inode: 493
Journal device: 0x0000
First orphan inode: 139500
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Htree ate my hard drive, was: post-halloween 0.2
2002-10-31 6:27 ` Htree ate my hard drive, was: " Duncan Sands
@ 2002-10-31 8:07 ` Andreas Dilger
2002-11-04 22:42 ` [Ext2-devel] " Stephen C. Tweedie
0 siblings, 1 reply; 6+ messages in thread
From: Andreas Dilger @ 2002-10-31 8:07 UTC (permalink / raw)
To: Duncan Sands; +Cc: Dave Jones, Linux Kernel, ext2-devel
On Oct 31, 2002 07:27 +0100, Duncan Sands wrote:
> > EXT3 Htree support.
> > ~~~~~~~~~~~~~~~~~~~
> > The ext3 filesystem has gained indexed directory support, which offers
> > considerable performance gains when used on filesystems with large
> > directories. In order to use the htree feature, you need at least version
> > 1.29 of e2fsprogs. Existing filesystems can be converted using the command
> > "tune2fs -O dir_index /dev/hdXXX" The latest e2fsprogs can be found at
> > http://prdownloads.sourceforge.net/e2fsprogs
>
> I ran this (tune2fs -O dir_index /dev/hdXXX).
>
> After a bit of switching back and forth between 2.4.19 and 2.5.44,
> fsck was run while booting 2.4.19 (the usual check because of >30
> mounts). There was a message about optimizing directories. Booting
> continued but (big surprise) X refused to run. It turned out that some
> device files had vanished. Very strange. On rebooting, fsck found a
> gazillion bad inodes. They all turned out to be from the 2.5.44 tree -
> poetic justice I suppose! But this did not suffice. Rebooting, I got
> "optimizing directories" again. Next fsck showed up more dud inodes.
> After a few cycles of this, I ran
>
> tune2fs -O ^dir_index /dev/hdXXX
>
> to remove htree support. No problems since then.
>
> tune2fs 1.30-WIP (30-Sep-2002)
I wonder if there is still a bug in the e2fsck code for re-hashing
directories? It shouldn't be possible to have e2fsck complete and
there still be an error in the filesystem (ok, sometimes it happens,
but in those cases it spews a lot of warnings about the filesystem
not being fixed yet and to run manually).
What else is strange (at least to me) is e2fsck "optimizing directories"
on a reboot. My understanding at least is that this would be done only
when explicitly asked for, otherwise it might slow down booting a lot,
and as you can see it adds to the possibility of corrupting the fs when
e2fsck should only be fixing it.
Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Ext2-devel] Re: Htree ate my hard drive, was: post-halloween 0.2
2002-10-31 8:07 ` Andreas Dilger
@ 2002-11-04 22:42 ` Stephen C. Tweedie
2002-11-04 22:59 ` Duncan Sands
2002-11-04 23:22 ` Udo A. Steinberg
0 siblings, 2 replies; 6+ messages in thread
From: Stephen C. Tweedie @ 2002-11-04 22:42 UTC (permalink / raw)
To: Duncan Sands, Dave Jones, Linux Kernel, ext2-devel
Hi,
On Thu, Oct 31, 2002 at 01:07:17AM -0700, Andreas Dilger wrote:
> On Oct 31, 2002 07:27 +0100, Duncan Sands wrote:
> > After a bit of switching back and forth between 2.4.19 and 2.5.44,
> > fsck was run while booting 2.4.19 (the usual check because of >30
> > mounts). There was a message about optimizing directories. Booting
> > continued but (big surprise) X refused to run. It turned out that some
> > device files had vanished.
> > tune2fs -O ^dir_index /dev/hdXXX
> > to remove htree support. No problems since then.
> I wonder if there is still a bug in the e2fsck code for re-hashing
> directories?
Possibly, but I'm more worried about why the fsck did a directory
optimise on reboot, especially on the root filesystem (where /dev is
usually stored). Doing major fs surgery on a mounted, readonly
filesystem is sort-of safe, but only if you reboot afterwards.
Continuing and remounting read-write can cause all sorts of damage as
the cached fs data no longer matches what's on disk.
Duncan, did you have fsck set up to do a forced htree rebuild on
reboot?
Cheers,
Stephen
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Ext2-devel] Re: Htree ate my hard drive, was: post-halloween 0.2
2002-11-04 22:42 ` [Ext2-devel] " Stephen C. Tweedie
@ 2002-11-04 22:59 ` Duncan Sands
2002-11-04 23:22 ` Udo A. Steinberg
1 sibling, 0 replies; 6+ messages in thread
From: Duncan Sands @ 2002-11-04 22:59 UTC (permalink / raw)
To: Stephen C. Tweedie, Dave Jones, Linux Kernel, ext2-devel
On Monday 04 November 2002 23:42, Stephen C. Tweedie wrote:
> Hi,
>
> On Thu, Oct 31, 2002 at 01:07:17AM -0700, Andreas Dilger wrote:
> > On Oct 31, 2002 07:27 +0100, Duncan Sands wrote:
> > > After a bit of switching back and forth between 2.4.19 and 2.5.44,
> > > fsck was run while booting 2.4.19 (the usual check because of >30
> > > mounts). There was a message about optimizing directories. Booting
> > > continued but (big surprise) X refused to run. It turned out that some
> > > device files had vanished.
> > >
> > > tune2fs -O ^dir_index /dev/hdXXX
> > > to remove htree support. No problems since then.
> >
> > I wonder if there is still a bug in the e2fsck code for re-hashing
> > directories?
>
> Possibly, but I'm more worried about why the fsck did a directory
> optimise on reboot, especially on the root filesystem (where /dev is
> usually stored). Doing major fs surgery on a mounted, readonly
> filesystem is sort-of safe, but only if you reboot afterwards.
> Continuing and remounting read-write can cause all sorts of damage as
> the cached fs data no longer matches what's on disk.
>
> Duncan, did you have fsck set up to do a forced htree rebuild on
> reboot?
Hmmm, fsck is called from the debian checkroot init script which does
fsck -a -C
So I guess the answer is "no".
Duncan.
PS: I am using version 1.30-WIP of e2fsck.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [Ext2-devel] Re: Htree ate my hard drive, was: post-halloween 0.2
2002-11-04 22:42 ` [Ext2-devel] " Stephen C. Tweedie
2002-11-04 22:59 ` Duncan Sands
@ 2002-11-04 23:22 ` Udo A. Steinberg
1 sibling, 0 replies; 6+ messages in thread
From: Udo A. Steinberg @ 2002-11-04 23:22 UTC (permalink / raw)
To: Stephen C. Tweedie; +Cc: linux-kernel, ext2-devel
[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]
On Mon, 4 Nov 2002 22:42:13 +0000 Stephen C. Tweedie (SCT) wrote:
SCT> On Thu, Oct 31, 2002 at 01:07:17AM -0700, Andreas Dilger wrote:
SCT> > I wonder if there is still a bug in the e2fsck code for re-hashing
SCT> > directories?
SCT>
SCT> Possibly, but I'm more worried about why the fsck did a directory
SCT> optimise on reboot, especially on the root filesystem (where /dev is
SCT> usually stored). Doing major fs surgery on a mounted, readonly
SCT> filesystem is sort-of safe, but only if you reboot afterwards.
SCT> Continuing and remounting read-write can cause all sorts of damage as
SCT> the cached fs data no longer matches what's on disk.
Just a "me too". I've used htree with 2.5.44 and 2.4.20rc1. The next
fs check on the root filesystem founds corruption in /dev. After repairing
the damage and recreating the lost devices the machine ran ok for 2 days.
Then I had some ext3-fs errors and the partition got remounted read-only.
The following fsck revealed two inodes sharing the same block. I don't
have any logs of that incident anymore though :/
I'm running Slackware 9.0-beta and e2fsprogs-1.30-WIP.
Regards,
-Udo.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2002-11-04 23:16 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-10-31 11:19 Htree ate my hard drive, was: post-halloween 0.2 Petr Vandrovec
2002-10-31 21:42 ` [Ext2-devel] " chrisl
2002-10-31 22:03 ` Theodore Ts'o
-- strict thread matches above, loose matches on Subject: below --
2002-10-30 17:11 Dave Jones
2002-10-31 6:27 ` Htree ate my hard drive, was: " Duncan Sands
2002-10-31 8:07 ` Andreas Dilger
2002-11-04 22:42 ` [Ext2-devel] " Stephen C. Tweedie
2002-11-04 22:59 ` Duncan Sands
2002-11-04 23:22 ` Udo A. Steinberg
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.