The ext3 way of journalling - Kernel

This is a discussion on The ext3 way of journalling - Kernel ; The ext3 journalling code can be summarised as: superblock->last_checked = random(); sync(superblock) I hate it: every time Linux crashes, e.g. due to power failure, it takes almost an hour to boot, because the kernel has decided to corrupt the superblock ...

+ Reply to Thread
Page 1 of 4 1 2 3 ... LastLast
Results 1 to 20 of 74

Thread: The ext3 way of journalling

  1. The ext3 way of journalling


    The ext3 journalling code can be summarised as:

    superblock->last_checked = random();
    sync(superblock)

    I hate it: every time Linux crashes, e.g. due to power failure, it takes
    almost an hour to boot, because the kernel has decided to corrupt the
    superblock to indicate that it's been years since last file system
    check. And obviously the crappy init system provides no simple way to
    stop the checking, to put it in the background, or whatever. The FOSS
    herd is totally concentrated on creating a WIMP idiot box -- a cheap
    plastic clone of Windows -- instead of fixing such fundamental problems.
    Windows, by the way, boots like a blaze compared to woeful Linux crap
    (even without the very definition of pure ****: udev, which the crap
    known as Linux practically requires these days).

    A partial contributor to the slow fsck process is:

    hde: ST3160023AS, ATA DISK drive
    hde: applying pessimistic Seagate errata fix

    # hdparm -t /dev/hde
    /dev/hde:
    Timing buffered disk reads: 48 MB in 3.01 seconds = 15.96 MB/sec

    Thank you very much. The disk worked perfectly well without that "fix"
    in earlier (2.2 or was it some 2.4?) kernels and, in Windows too. That
    raw timing is worse than the _encrypted_ transfer rate I get from other
    disks.

    One should always indicate the version of software when complaining. Well,

    $ uname -a
    Linux noi 2.6.14 #1 PREEMPT Sun Oct 30 20:18:48 EET 2005 i686 GNU/Linux

    I've tried upgrading, and failed: the megatonne monolith with a gazillion
    hidden options (and totally worthless make oldconfig) is impossible to
    compile these days, and the distros' stock kernel are utter and total crap
    that load drivers in wrong order etc., and are difficult to configure
    (demanding crap that demands udev to edit their initrds). Not to even
    speak of the udev-demanding scsi-mapping insanity of SATA etc. devices
    these days.

    I've had it with Linux. It's no longer for power users. It's so complex
    that it's only for idiot users that are content with the shoddy defaults,
    and (paid) developers.

    --
    Tuomo

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: The ext3 way of journalling


    On Jan 8 2008 16:07, Tuomo Valkonen wrote:
    >
    >One should always indicate the version of software when complaining. Well,
    >
    > $ uname -a
    > Linux noi 2.6.14 #1 PREEMPT Sun Oct 30 20:18:48 EET 2005 i686 GNU/Linux
    >
    >I've tried upgrading, and failed: the megatonne monolith with a gazillion
    >hidden options (and totally worthless make oldconfig) is impossible to
    >compile these days,


    Do it step-by-step.

    git checkout v2.6.15
    make oldconfig
    git checkout v2.6.16
    make oldconfig
    ....

    >and the distros' stock kernel are utter and total crap


    I can recommend that you try another distribution then.

    >that load drivers in wrong order etc.,


    What specific modules and which order do you need for the disks?
    There is also kernel-side loading order coming up:
    http://lwn.net/Articles/260856/

    >and are difficult to configure


    I do not really have to configure anything on my machine. Then again,
    yours might be vastly different. I can seamlessy switch distro and
    self-built kernels, with the only extra that I have to call mkinitrd
    (on opensuse that works without arguments even) for the self-built one.

    >(demanding crap that demands udev to edit their initrds).


    mkinitrd should take care of that.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. Re: The ext3 way of journalling

    >>>>> "Tuomo" == Tuomo Valkonen writes:

    Tuomo> The ext3 journalling code can be summarised as:

    superblock-> last_checked = random();
    Tuomo> sync(superblock)

    Tuomo> I hate it: every time Linux crashes, e.g. due to power failure,
    Tuomo> it takes almost an hour to boot, because the kernel has decided
    Tuomo> to corrupt the superblock to indicate that it's been years
    Tuomo> since last file system check.

    Bull****. But first, why don't you post some bootup message logs so
    people can actually look at the problem, instead of your space wasting
    rant? Oh wait... I just did waste the time. Sigh...

    Look at your filesystems, using 'tune2fs' and see if the ext3 journal
    is actually turned on and used. If it's not, then I can see why
    you're having problems on reboots.

    Tuomo> And obviously the crappy init system provides no simple way to
    Tuomo> stop the checking, to put it in the background, or
    Tuomo> whatever. The FOSS herd is totally concentrated on creating a
    Tuomo> WIMP idiot box -- a cheap plastic clone of Windows -- instead
    Tuomo> of fixing such fundamental problems. Windows, by the way,
    Tuomo> boots like a blaze compared to woeful Linux crap (even without
    Tuomo> the very definition of pure ****: udev, which the crap known as
    Tuomo> Linux practically requires these days).

    And I fell for it.

    Tuomo> A partial contributor to the slow fsck process is:

    Tuomo> hde: ST3160023AS, ATA DISK drive
    Tuomo> hde: applying pessimistic Seagate errata fix

    Tuomo> # hdparm -t /dev/hde
    Tuomo> /dev/hde:
    Tuomo> Timing buffered disk reads: 48 MB in 3.01 seconds = 15.96 MB/sec

    Tuomo> Thank you very much. The disk worked perfectly well without
    Tuomo> that "fix" in earlier (2.2 or was it some 2.4?) kernels and, in
    Tuomo> Windows too. That raw timing is worse than the _encrypted_
    Tuomo> transfer rate I get from other disks.

    So go back to 2.4 then, noone is stopping you. But I'd rather have a
    slower disk that didn't corrupt my data behind my back...

    Tuomo> One should always indicate the version of software when
    Tuomo> complaining. Well,

    Tuomo> $ uname -a Linux noi 2.6.14 #1 PREEMPT Sun Oct 30 20:18:48
    Tuomo> EET 2005 i686 GNU/Linux

    What CPU are you using? Chipset? Output of lspci? dmesg output?

    Tuomo> I've tried upgrading, and failed: the megatonne monolith with a
    Tuomo> gazillion hidden options (and totally worthless make oldconfig)
    Tuomo> is impossible to compile these days, and the distros' stock
    Tuomo> kernel are utter and total crap that load drivers in wrong
    Tuomo> order etc., and are difficult to configure (demanding crap that
    Tuomo> demands udev to edit their initrds). Not to even speak of the
    Tuomo> udev-demanding scsi-mapping insanity of SATA etc. devices these
    Tuomo> days.

    What are you talking about?

    Tuomo> I've had it with Linux. It's no longer for power users. It's so
    Tuomo> complex that it's only for idiot users that are content with
    Tuomo> the shoddy defaults, and (paid) developers.

    "It's so complex it's for Idiot users" is really funny to read.


    John
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. Re: The ext3 way of journalling

    Tuomo Valkonen writes:

    > The ext3 journalling code can be summarised as:
    >
    > superblock->last_checked = random();
    > sync(superblock)
    >
    > I hate it: every time Linux crashes, e.g. due to power failure, it takes
    > almost an hour to boot,


    tune2fs -i0 -c0 device for each file system

    Yes that should be default, unfortunately it is not. It's one
    of the first things I do on new machines.

    > Thank you very much. The disk worked perfectly well without that "fix"


    fsck is actually seek bound, most likely it won't make much difference
    for fsck. Seeky disk IO is always slow on a spinning disk.

    There's actually been a patchkit recently to make fsck much faster
    by clustering metadata better so it can be reached with less seeks,
    but that hasn't reached mainline yet and and will unfortunately
    require freshly created file systems.

    -Andi
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: The ext3 way of journalling

    On 2008-01-08, John Stoffel wrote:
    > Look at your filesystems, using 'tune2fs' and see if the ext3 journal
    > is actually turned on and used. If it's not, then I can see why
    > you're having problems on reboots.


    Journalling is on, but it's no use because the superblock always has
    corrupted last-checked time at boot. "File system check forced: 31352
    days since last check" or so.

    > What CPU are you using? Chipset? Output of lspci? dmesg output?


    Athlon XP 2500+, SiI 3112 (the obsoleted driver that makes the disk
    appear as the predictable hde, not the random scsi mapping driver).

    As for the rest... I'm on Windows, because I can't be arsed waiting
    for an hour for Linux to boot.

    --
    Tuomo

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: The ext3 way of journalling

    On 2008-01-08, Jan Engelhardt wrote:
    > Do it step-by-step.


    Still too much work.

    > I can recommend that you try another distribution then.


    They all suck.

    >>that load drivers in wrong order etc.,

    >
    > What specific modules and which order do you need for the disks?
    > There is also kernel-side loading order coming up:
    > http://lwn.net/Articles/260856/
    >
    >>and are difficult to configure

    >
    > I do not really have to configure anything on my machine. Then again,
    > yours might be vastly different.


    Typically distros' stock kernels load the intorable integrated buzz-chip
    as the first sound card, and the wrong network adapter as eth0. SATA and
    USB disks appear as some randomly ordered scsi nodes, and so on. This
    could be configured with udev if one were willing to learn -- for a
    fundamentally very trivial task -- yet another wheel-reinving unnecessarily
    cryptic piece of ****, to tolerate distros breaking your cryptic config
    constantly, and to tolerate its intolerable slowness at boot. (/dev should
    still be the UI for modifying dynamic device mappings, reacting to ln, mv,
    chmod, etc., instead of being reduced into a race-condition ridden tmpfs
    shadow, that loses your normally created symlinks and permissions at boot.)

    But the stock kernels also takes age at boot in (trying to) load a zillion
    unnecessary drivers. They need to be configured to not load them. But
    _obviously_ they won't use a _simple_ listing of the modules to load
    (/etc/modules), but demand complex initrd editing. And all of those tools
    that I've seen and have not required too much work, have again demanded
    udev. No thanks.

    --
    Tuomo

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: The ext3 way of journalling

    On 2008-01-08, Andi Kleen wrote:
    > tune2fs -i0 -c0 device for each file system
    >
    > Yes that should be default, unfortunately it is not. It's one
    > of the first things I do on new machines.


    I have ages ago increased those counts, but I don't want to
    completely disable them. The problem is that the superblock
    is corrupted to indicate absurd "31352 days since last check".
    Who knows, maybe it would even corrupt those settings.

    --
    Tuomo

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. Re: The ext3 way of journalling


    On Jan 8 2008 16:52, Tuomo Valkonen wrote:
    >
    >> I can recommend that you try another distribution then.

    >
    >They all suck.


    Roll your own.

    >Typically distros' stock kernels load the intorable integrated buzz-chip
    >as the first sound card,


    While that is true, configuration tools such as, ads aside, yast2
    (designed for those "idiots" you referred to with 'WIMP idiot box') has
    a setting for which card should be loaded first. "Power users" may still
    use the index= option of sound card modules and wire it up in
    /etc/modprobe.d if they prefer.

    >and the wrong network adapter as eth0.


    You can guess my answer: udev will fix it. And actually, udev will
    record the MAC address and the device name the first time it encounters
    a new device, hence will always use the same interface name for a MAC
    address. So the MAC--interface mapping may be wrong on the first
    install (until you 'fix' the mapping so that it is to your liking),
    but will remain the same afterwards.
    Exempt are some nvidia-based weirdo chips which assign a random
    MAC at every boot.

    >SATA and
    >USB disks appear as some randomly ordered scsi nodes, and so on.


    Well what do you expect of it? The kernel does not keep USB port <->
    SCSI device mappings. Neither USB device <-> SCSI device mapping,
    because not all USB ports or USB devices are mass-storage devices.
    It just is not the kernel's job.

    Now that you mention that,
    /dev/disk/by-id/ata-DIAMOND_250G_2B5400_030400026 always has had the
    contents I expected it to have. Wonder how that comes!? Don't tell me
    you are using those old-fashioned /dev/sda - that would be negligent.
    Some/most(?) distros do not follow /dev/disk consistently yet, so you
    are free to blame them. Not to forget that udev makes this possible

    >This could be configured with udev if one were willing to learn -- for
    >a fundamentally very trivial task --


    Nothing to configure, this is standard udev configuration file
    boilerplate and comes prepackaged. Upgrade udev to version 114 at least.

    >yet another wheel-reinving unnecessarily
    >cryptic piece of ****, to tolerate distros breaking your cryptic config
    >constantly,


    Mine plays very well.

    $ cat /etc/crypttab
    home /dev/disk/by-id/ata-DIAMOND_250G_2B5400_030400026-part2 none
    cipher=aes-cbc-essiv:sha256

    and /dev/mapper/home is a fixed name.

    >and to tolerate its intolerable slowness at boot. (/dev should
    >still be the UI for modifying dynamic device mappings, reacting to ln, mv,
    >chmod, etc., instead of being reduced into a race-condition ridden tmpfs
    >shadow, that loses your normally created symlinks and permissions at boot.)


    May I remind you that the kernel also "loses" all your network interface
    configuration, routes, firewalling rules and all sysctl settings at
    boot (sic: reboot & powerdown).

    >But the stock kernels also takes age at boot in (trying to) load a zillion
    >unnecessary drivers.


    Distros have to decide whether to

    - not autoload a zillion of modules, potentially generating lots of
    crying "idiot" users

    - autoload a zillion of modules, potentially firing you up.


    >They need to be configured to not load them. But
    >_obviously_ they won't use a _simple_ listing of the modules to load
    >(/etc/modules), but demand complex initrd editing.


    Nonsense. The kernel notices udev about all available hardware and udev
    will load modules. It has nothing to do with initrd, in fact, this very
    step of loading a gazillion of modules is done after initrd has passed
    control on to /sbin/init. At least, in opensuse.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: The ext3 way of journalling

    On 16:07, Tuomo Valkonen wrote:

    > I hate it: every time Linux crashes, e.g. due to power failure, it takes
    > almost an hour to boot, because the kernel has decided to corrupt the
    > superblock to indicate that it's been years since last file system
    > check.


    Use tune2fs to deactivate checking.

    > And obviously the crappy init system provides no simple way to
    > stop the checking, to put it in the background, or whatever.


    Modify the init scripts or use another distro.

    > The FOSS herd is totally concentrated on creating a WIMP idiot box --
    > a cheap plastic clone of Windows -- instead of fixing such fundamental
    > problems.
    > Windows, by the way, boots like a blaze compared to woeful Linux crap
    > (even without the very definition of pure ****: udev, which the crap
    > known as Linux practically requires these days).


    Don't use udev then. Good old static dev works fine if you have a fixed
    set of devices.

    > A partial contributor to the slow fsck process is:
    >
    > hde: ST3160023AS, ATA DISK drive
    > hde: applying pessimistic Seagate errata fix
    >
    > # hdparm -t /dev/hde
    > /dev/hde:
    > Timing buffered disk reads: 48 MB in 3.01 seconds = 15.96 MB/sec


    You're using the sil3112 driver? Edit its blacklist and remove the
    entry for your drive. That gives you the usual speed.

    > Linux noi 2.6.14 #1 PREEMPT Sun Oct 30 20:18:48 EET 2005 i686 GNU/Linux
    >
    > I've tried upgrading, and failed: the megatonne monolith with a gazillion
    > hidden options (and totally worthless make oldconfig)


    Gradually upgrade to 2.6.15, 2.6.16...

    > is impossible to compile these days,


    Check your tool-chain. Many people compile recent kernels with no problems.

    > and the distros' stock kernel are utter and total crap
    > that load drivers in wrong order etc., and are difficult to configure
    > (demanding crap that demands udev to edit their initrds).


    Use a kernel.org version.

    > Not to even speak of the udev-demanding scsi-mapping insanity of SATA
    > etc. devices these days.


    Nobody forces you to use udev. Moreover, you can write your own udev
    rules that match your expectations.

    > I've had it with Linux. It's no longer for power users. It's so complex
    > that it's only for idiot users that are content with the shoddy defaults,
    > and (paid) developers.


    You're not ranting about Linux but about your Distro. Complain on
    the corresponding distro-specific mailing list, use another distro
    and and stop whining.

    Thanks
    Andre
    --
    The only person who always got his work done by Friday was Robinson Crusoe

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.1 (GNU/Linux)

    iD8DBQFHg6lvWto1QDEAkw8RArL5AKCfCEZD4luSlF8nJR7EJw kO15l2tACgoLc9
    i5ajLx1iSuSi1iIsN/OYEfI=
    =y0Qc
    -----END PGP SIGNATURE-----


  10. Re: The ext3 way of journalling

    On 2008-01-08, Jan Engelhardt wrote:
    > Roll your own.


    Nah, too much work, and I want all distros to perish.

    > "Power users" may still
    > use the index= option of sound card modules and wire it up in
    > /etc/modprobe.d if they prefer.


    Another very cryptic directory whose contents say nothing to me.
    Configuration files should be self-documenting and editable,
    instead having to be created based on long documentation.
    The simple /etc/modules -- which at least Debian's stock kernels
    do not use -- qualifies, but few other files these days do.

    > You can guess my answer: udev will fix it.


    And break everything else, such as my symlinks, permissions, etc.
    I'm not going to learn its cryptic special-case config files for
    such trivial tasks as creating a ****ing symlink or change the
    permissions of a file, for which exist general purpose methods:
    chmod, chown, ln -s.

    > Well what do you expect of it? The kernel does not keep USB port <->
    > SCSI device mappings. Neither USB device <-> SCSI device mapping,
    > because not all USB ports or USB devices are mass-storage devices.
    > It just is not the kernel's job.


    Mapping everything to scsi nodes is brain damaged. The old hda, hdb,
    etc. mappings had somewhat clear correspondence between to physical
    evice addresses, and were easy to use without such complicated crap
    as udev. Of course, I'd prefer just device unique IDs being used,
    where possible... but I'm not going to suffer udev for that.

    > Mine plays very well.


    I was not talking of encrypted disks but cryptic udev config files,
    that the distros are going to break on every upgrade.

    > May I remind you that the kernel also "loses" all your network interface
    > configuration, routes, firewalling rules and all sysctl settings at
    > boot (sic: reboot & powerdown).


    But traditional /dev does not lose permissions and symlinks. udev
    tmpfs shadow brain damage does. You have to illogically and
    inconveniently edit udev's cryptic config files instead, and yet
    it in no way stops /dev from being modified.

    > Distros have to decide whether to
    >
    > - not autoload a zillion of modules, potentially generating lots of
    > crying "idiot" users
    >
    > - autoload a zillion of modules, potentially firing you up.


    And they most of them cater for idiot users, and the rest for
    develors what want to do it all from scratch. Mere power users
    who want to tune the system to their needs, but easily and without
    WIMP**** (through _simple_ self-documenting configuration files),
    are forgotten these days.

    > Nonsense. The kernel notices udev about all available hardware and udev
    > will load modules. It has nothing to do with initrd, in fact, this very
    > step of loading a gazillion of modules is done after initrd has passed
    > control on to /sbin/init. At least, in opensuse.


    I've never seen a system that would do so. And I won't use udev.

    --
    Tuomo

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: The ext3 way of journalling

    On 2008-01-08, Andre Noll wrote:
    > Use tune2fs to deactivate checking.


    So, a workaround is the answer to a clear bug. Typical FOSS.

    > Modify the init scripts or use another distro.


    Another typical FOSS answer. "You have the source, you can fix it."
    With what time?

    > Don't use udev then. Good old static dev works fine if you have a fixed
    > set of devices.


    It doesn't, with the unpredictable SCSI mapping insanity.

    > You're using the sil3112 driver? Edit its blacklist and remove the
    > entry for your drive. That gives you the usual speed.


    Recompiling? No thanks. Compiling the Linux kernel is too painful.

    > Check your tool-chain. Many people compile recent kernels with no problems.


    And recompile and recompile and recompile ad infinitum, because always
    some option was missing or wrong, there being far too many of them and
    hidden all over the place.

    > Nobody forces you to use udev. Moreover, you can write your own udev
    > rules that match your expectations.


    See above on having time to learn over-cryptic systems.

    > You're not ranting about Linux but about your Distro. Complain on
    > the corresponding distro-specific mailing list, use another distro
    > and and stop whining.


    I don't use a distro kernel. I use a kernel I compiled myself over
    two years ago. I have tried compiling newer ones, but it's too much
    work to get all the options right. And then there's the problem that
    the "good" driver for my SATA disk may not be there anymore in the
    latest kernels, and so on.

    --
    Tuomo

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: The ext3 way of journalling

    On Tue, Jan 08, 2008 at 05:01:30PM +0000, Tuomo Valkonen wrote:
    > On 2008-01-08, Andi Kleen wrote:
    > > tune2fs -i0 -c0 device for each file system
    > >
    > > Yes that should be default, unfortunately it is not. It's one
    > > of the first things I do on new machines.

    >
    > I have ages ago increased those counts, but I don't want to
    > completely disable them. The problem is that the superblock
    > is corrupted to indicate absurd "31352 days since last check".
    > Who knows, maybe it would even corrupt those settings.


    Newer e2fsprogs display a better message, and you can set an
    /etc/e2fsck.conf setting:

    [options]
    buggy_init_scripts = 1

    That will fix the this issue. The problem you are facing is that you
    have your hardware clock set to ticking localtime, instead of GMT.
    Windows ticks localtime, which is a mistake carried over from the
    1970's and MS-DOS. Ticking localtime has all sorts of problems, among
    which is if you reboot around the transition between Summer Time (or
    Daylight Savings Time, depending on your contry) and normal time, the
    OS has no idea whether the DST adjustment has been applied or not.

    It gets even worse if you have multiple operating systems, because
    then one OS may have made the adjustment, and other one may no have
    made the adjustment. It's for that reason that if you reboot around
    the right time of year, Windows throws up a big dialog box asking you
    what the correct time should be. Genius!

    The problem on the Linux side is that some distributions, and Ubuntu
    is the worse offender, but probably not the only one, do not correctly
    set the system clock before they run fsck. And if you live east of
    GMT, such that your localtime offset is positive instead of negative,
    then time can appear to go backwards and e2fsck can't trust the last
    superblock check time. Old versions of e2fsprogs display a funny
    large time interval due to an integer overflow bug; that's since been
    fixed. (This bug doesn't support people in the US, because of our
    time zone offset, but it tends to affect people in Europe who are
    dual-booting with Windows and hance have their hardware clock tick
    localtime.)

    Now, there are good reasons for doing periodic checks every N mounts
    and after M months. And it has to do with PC class hardware. (Ted's
    aphorism: "PC class hardware is cr*p"). Windows users don't notice it
    much because they generally blame the occasional blue screen of death
    or corrupted file as an OS bug. But very often, it is a hardware
    issue, particularily on the cheaper PC class machines with no ECC
    memory, and cheapest, unshielded hard drive cables from Taiwan that
    the manufacturers can find. Hence, the default is to do periodic
    checks, since if you don't a random corruption can cause massive
    filesystem corruption leading to massive data loss.

    But, if you're confident in your hardware, you can turn that off.
    tune2fs -c 0 will disable the number of mounts check, and tune2fs -i 0
    will turn of the periodic time-based check. And given that you have a
    Linux distribution with buggy init scripts, that is one way of working
    around the problem.

    You could also simply change your CMOS/hardware clock to use GMT time,
    and not localtime. But that doesn't work well when you need to
    dual-boot with Windows, since Windows doesn't support GMT time for the
    hardware clock.

    Another approach would involve using the /etc/e2fsck.conf settings
    described above, but that will require possibly upgrading the version
    of e2fsprogs that you have. This will be the preferred mechanism
    going forward, but perhaps not for the version of e2fsprogs you have
    installed on your system.

    Finally, I'm sorry this has obviously caused you so much stress. If
    you're happier using some other OS, please use whatever OS you find
    makes you happiest. I find that other deficiencies in Windows caused
    my blood pressure to boil when I was forced (for a previous job) to
    work on making programs run on Windows. I consider the fact that I
    can spend full-time working on Linux to be a blessing. But if you
    don't feel that way, my condolences, and please do what you need to do
    so you can stay in your happy place.

    Best regards,

    - Ted
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: The ext3 way of journalling


    On Jan 8 2008 17:52, Tuomo Valkonen wrote:
    >On 2008-01-08, Andre Noll wrote:
    >> Use tune2fs to deactivate checking.

    >
    >So, a workaround is the answer to a clear bug. Typical FOSS.


    Well if it is a problem for you, why do not you come and fix it?

    >> Modify the init scripts or use another distro.

    >
    >Another typical FOSS answer. "You have the source, you can fix it."
    >With what time?


    If you do not like spending time yourself, hire someone.

    >> Check your tool-chain. Many people compile recent kernels with no problems.

    >
    >And recompile and recompile and recompile ad infinitum, because always
    >some option was missing or wrong, there being far too many of them and
    >hidden all over the place.


    Yes. Either you compile or you use a distro kernel. But you do not want
    either, so that kinda narrows it down.

    >> Nobody forces you to use udev. Moreover, you can write your own udev
    >> rules that match your expectations.

    >
    >See above on having time to learn over-cryptic systems.


    http://linux.oneandoneis2.org/LNW.htm . Replace Windows by favorite OS you wanted to originally have>.

    >> You're not ranting about Linux but about your Distro. Complain on
    >> the corresponding distro-specific mailing list, use another distro
    >> and and stop whining.

    >
    >I don't use a distro kernel. I use a kernel I compiled myself over
    >two years ago. I have tried compiling newer ones, but it's too much
    >work to get all the options right. And then there's the problem that
    >the "good" driver for my SATA disk may not be there anymore in the
    >latest kernels, and so on.


    I did the same previously. As soon as there was more than three
    machines to administer, I stopped building kernels the typical way
    for production machines and instead built one central RPM (sort of
    distro kernel). I never look back.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. Re: The ext3 way of journalling


    On Jan 8 2008 17:48, Tuomo Valkonen wrote:
    >
    >> You can guess my answer: udev will fix it.

    >
    >And break everything else, such as my symlinks, permissions, etc.
    >I'm not going to learn its cryptic special-case config files for
    >such trivial tasks as creating a ****ing symlink or change the
    >permissions of a file, for which exist general purpose methods:
    >chmod, chown, ln -s.


    So create /sdev and fill it with all the device nodes that you deem
    static and worthy of chowning. As far as sound goes, /dev/dsp and
    /dev/snd/* is made writable by something called resmgr+hal+hal_resmgr
    (yes, more clutter!). I have not worried about device permissions
    in a long time. The only exception is vmware, but that is its very
    own problem.

    >> Mine plays very well.

    >
    >I was not talking of encrypted disks but cryptic udev config files,
    >that the distros are going to break on every upgrade.


    If yours does, then that is bad luck. Mine (again) does not.
    That is what a distro is supposed to bring: a system that does not
    break ("as much", if you like the extra) on an upgrade as if you
    did upgrade software and such by hand.

    >> May I remind you that the kernel also "loses" all your network interface
    >> configuration, routes, firewalling rules and all sysctl settings at
    >> boot (sic: reboot & powerdown).

    >
    >But traditional /dev does not lose permissions and symlinks. udev
    >tmpfs shadow brain damage does. You have to illogically and
    >inconveniently edit udev's cryptic config files instead, and yet
    >it in no way stops /dev from being modified.


    If you dislike udev so much, why don't you just add

    chmod 666 /dev/*

    to /etc/init.d/boot.local...

    >> Distros have to decide whether to
    >>
    >> - not autoload a zillion of modules, potentially generating lots of
    >> crying "idiot" users
    >>
    >> - autoload a zillion of modules, potentially firing you up.

    >
    >And they most of them cater for idiot users, and the rest for
    >develors what want to do it all from scratch. Mere power users
    >who want to tune the system to their needs, but easily and without
    >WIMP**** (through _simple_ self-documenting configuration files),
    >are forgotten these days.


    ISTR that most Windows programs do not even have a configuration
    file, but store their bits and pieces in the *even more cryptic*
    thing they call Registry. Do you prefer _that_?

    >> Nonsense. The kernel notices udev about all available hardware and udev
    >> will load modules. It has nothing to do with initrd, in fact, this very
    >> step of loading a gazillion of modules is done after initrd has passed
    >> control on to /sbin/init. At least, in opensuse.

    >
    >I've never seen a system that would do so.


    You just did not use the right distribution yet.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  15. Re: The ext3 way of journalling

    On 2008-01-08, Jan Engelhardt wrote:
    > http://linux.oneandoneis2.org/LNW.htm . Replace Windows by > favorite OS you wanted to originally have>.


    Linux is too much like Windows, and that's a big part of the problem.
    People are obssessed on providing WIMP**** interfaces to everything,
    and the underlying layers are allowed to become complex and cluttered,
    being designed according to the worse-is-better fallacy, and are only
    suitable for developers with the time to study them, not power users,
    who are completely left out.

    --
    Tuomo

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. Re: The ext3 way of journalling

    On Tue, 8 Jan 2008 18:16:49 +0000 (UTC)
    Tuomo Valkonen wrote:

    > On 2008-01-08, Masoud Sharbiani "مسعود شربیانی" wrote:
    > > It isn't a bug. It is a feature;

    >
    > To me, it seems to be a rather clear bug when the last-checked field
    > contains an absurd value of years ago, on _all_ disks, and yet there's
    > no complaint of other superblock corruption.


    So report it to your distribution vendor, and they can help you work out
    why you are about the only person on the planet reporting that problem.

    Alan
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. Re: The ext3 way of journalling

    http://freebsd.org
    http://netbsd.org
    http://openbsd.org
    http://opensolaris.org


    There're so many options, that wasting your time arguing with people that thinks
    that you're a troll is worthless.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  18. Re: The ext3 way of journalling

    On 17:52, Tuomo Valkonen wrote:
    > On 2008-01-08, Andre Noll wrote:
    > > Use tune2fs to deactivate checking.

    >
    > So, a workaround is the answer to a clear bug. Typical FOSS.


    It's not a workaround. The ext3 maintainers argue that every file
    system should be checked from time to time. Therefore it's the
    default. You do not agree with them, so change the default and be
    happy. Or use another fs which claims that no check is necessary.

    > Another typical FOSS answer. "You have the source, you can fix it."


    Indeed, and I think it's a very good answer.

    > With what time?


    Use the time you are currently using for whining on mailing lists.

    > > Don't use udev then. Good old static dev works fine if you have a fixed
    > > set of devices.

    >
    > It doesn't, with the unpredictable SCSI mapping insanity.


    Then write a set of udev rules for your SCSI devices. It's easy.

    > > Check your tool-chain. Many people compile recent kernels with no problems.

    >
    > And recompile and recompile and recompile ad infinitum, because always
    > some option was missing or wrong, there being far too many of them and
    > hidden all over the place.


    If you're not willing to compile, you'll have to use what other
    people provide. It's your choice, but at least there _is_ a choice.

    > > You're not ranting about Linux but about your Distro. Complain on
    > > the corresponding distro-specific mailing list, use another distro
    > > and and stop whining.

    >
    > I don't use a distro kernel. I use a kernel I compiled myself over
    > two years ago. I have tried compiling newer ones, but it's too much
    > work to get all the options right.


    I tend to disagree. It's not hard at all to configure a kernel if
    you know the hardware. It's even easier if you already have a working
    config for some kernel version. Just use "make oldconfig" to upgrade
    from one version to the next as already suggested by others and me.

    > And then there's the problem that the "good" driver for my SATA disk
    > may not be there anymore in the latest kernels, and so on.


    That is clearly a regression and I'm sure Jeff and other maintainers
    of the driver would be interested in details on this matter.

    Andre
    --
    The only person who always got his work done by Friday was Robinson Crusoe

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.1 (GNU/Linux)

    iD8DBQFHg8DwWto1QDEAkw8RAopkAJ9GOcrcivlBxBoff1O6oB fQzdIH1ACePA2M
    pEkTuEQ44GTS4dhdqchNZ2c=
    =nTQr
    -----END PGP SIGNATURE-----


  19. Re: The ext3 way of journalling

    On 2008-01-08, Andre Noll wrote:
    > It's not a workaround. The ext3 maintainers argue that every file
    > system should be checked from time to time. Therefore it's the
    > default. You do not agree with them, so change the default and be
    > happy.


    The thing is, I agree with them (although the default intervals could
    be a bit longer), but it gets confused and thinks it's been years since
    last check, when it hasn't. I have my doubts that Theodore Tso's reply
    is the problem here, because I didn't use to have this problem; it
    appeared relatively recently. But maybe old versions of e2fsck were
    smarter...

    > Use the time you are currently using for whining on mailing lists.


    That's doable on time you'd spend idling anyway. There are only so
    many hours of the day that you can do work that demands considerable
    thinking.

    > Then write a set of udev rules for your SCSI devices. It's easy.


    It isn't. There's no simple pre-existing setting to edit. And besides,
    it's the wrong approach from the POV of clean consistent design. It's
    the kludged worse-is-better approach that results in unusable
    cluster****s.

    > If you're not willing to compile, you'll have to use what other
    > people provide. It's your choice, but at least there _is_ a choice.


    I'd compile, if the thing to be compiled weren't made uncompilable.
    I'd use pre-compiled ****, if it wasn't ****.

    > I tend to disagree. It's not hard at all to configure a kernel if
    > you know the hardware. It's even easier if you already have a working
    > config for some kernel version. Just use "make oldconfig" to upgrade
    >=66rom one version to the next as already suggested by others and me.


    It didn't use to be hard for 1.2 or so, but it's been constantly getting
    worse, along with all the bloat.

    >> And then there's the problem that the "good" driver for my SATA disk
    >> may not be there anymore in the latest kernels, and so on.

    >
    > That is clearly a regression and I'm sure Jeff and other maintainers
    > of the driver would be interested in details on this matter.


    I don't know the details; all I know is that I've heard that the old
    SATA drivers that appear as /dev/hd$PREDICTABLE are being obsoleted in
    favour of those that appear as /dev/sd$RANDOM along with all the USB
    devices and whatnot.

    --
    Tuomo

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  20. Re: The ext3 way of journalling

    > be a bit longer), but it gets confused and thinks it's been years since
    > last check, when it hasn't. I have my doubts that Theodore Tso's reply
    > is the problem here, because I didn't use to have this problem; it
    > appeared relatively recently. But maybe old versions of e2fsck were


    This is a bug in your system or distribution. We used to see it years ago
    when the disk caches didn't get flushed before power off. The last write
    would vanish and on a shutdown was almost always the superblock time
    update.

    Alan
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 1 of 4 1 2 3 ... LastLast