The ext3 way of journalling - Kernel

This is a discussion on The ext3 way of journalling - Kernel ; On 2008-01-08, Diego Calleja wrote: > 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. Unfortunately they do not support ...

+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast
Results 21 to 40 of 74

Thread: The ext3 way of journalling

  1. Re: The ext3 way of journalling

    On 2008-01-08, Diego Calleja wrote:
    > 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.


    Unfortunately they do not support my hardware, and also switching OS distro
    on a full system is painful. (Although I heard previously commercial OSS is
    freely available now, so there might now be support for my sound card..
    At some point at least FreeBSD was missing support for my SATA controller,
    though...)

    --
    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

    Theodore Tso writes:
    >
    > 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").


    If these reasons are good ones (some skepticism here) then the correct
    way to really handle this would be to do regular background scrubbing
    during runtime; ideally with metadata checksums so that you can actually
    detect all corruption.

    But since fsck is so slow and disks are so big this whole thing
    is a ticking time bomb now. e.g. it is not uncommon to require tens
    of minutes or even hours of fsck time and some server that reboots
    only every few months will eat that when it happens to reboot.
    This means you get a quite long downtime.

    -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/

  3. Re: The ext3 way of journalling

    On Tuesday 08 January 2008 21:51:53 Andi Kleen wrote:
    > Theodore Tso writes:
    > > 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").

    >
    > If these reasons are good ones (some skepticism here) then the correct
    > way to really handle this would be to do regular background scrubbing
    > during runtime; ideally with metadata checksums so that you can actually
    > detect all corruption.
    >
    > But since fsck is so slow and disks are so big this whole thing
    > is a ticking time bomb now. e.g. it is not uncommon to require tens
    > of minutes or even hours of fsck time and some server that reboots
    > only every few months will eat that when it happens to reboot.
    > This means you get a quite long downtime.


    That's why I always do "tune2fs -c 0 -i 0" on any new filesystem. It probably
    should be default.

    >
    > -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/




    --
    Ondrej Zary
    --
    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" == Tuomo Valkonen writes:

    Tuomo> 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.


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

    As Andy say, reset the counts using tune2fs, then make sure they are
    actually reset. I've been using ext3 for a long time and even with
    crashes, it's been good about coming up and replaying the journal
    nicely.

    Again, we can't tell much without boot logs.

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


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

    I use a Sil 3112 as well for some of my disks (I've got six, two each
    of SCSI, PATA and SATA) and it all works well. So does an ancient but
    upto date Debian Unstable install running 2.6.24-rc6, so it's not
    impossible to install new kernels on old systems.

    Get rid of initrd and you should be all set. But again, without
    details we can't really help.

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

    So reboot it before you goto bed tonight and tell us what it says in
    the morning. Esp in terms of the filesystems and their counts.

    Hmm... but thinking about it, you're running 2.4.x something, and
    there were bugs back then with ext3, so you just might be hitting some
    of those bugs. Can you goto the latest 2.4.x release?

    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/

  5. Re: The ext3 way of journalling

    On Tue 2008-01-08 16:07:27, Tuomo Valkonen wrote:
    >
    > 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


    rm /sbin/fsck?

    And no, ext3 here does not corrupt last_checked here.
    --
    (english) http://www.livejournal.com/~pavelmachek
    (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pav...rses/blog.html
    --
    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

    > > 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.


    That what LABEL und UUID-Support in mount is for.

    You label the filesystems (e2label for ext2 and ext3) and use that label to mount them

    - fstab -
    LABEL=root / xfs defaults,noatime 0 1
    LABEL=boot /boot ext2 defaults,noatime 0 2
    ....
    - snip -





    Bis denn

    --
    Real Programmers consider "what you see is what you get" to be just as
    bad a concept in Text Editors as it is in women. No, the Real Programmer
    wants a "you asked for it, you got it" text editor -- complicated,
    cryptic, powerful, unforgiving, dangerous.

    --
    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

    Sorry for feeding the troll:

    On Die, 2008-01-08 at 17:52 +0000, 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.


    At least you get a simple solution for your problem: Configure your
    system in a slightly different way (once!) and that's it.
    There are far too many commercial vendors out there where you probably
    wouldn't get an answer at all. And if, days or weeks later.

    And if a - in your opinion! - wrong default value (for whatever reason)
    is a bug in your universe, then you should probably adopt the
    interpretation of words of this universe.
    BTW changing the default value in the source now doesn't fix the
    sub-optimal default value on your system.


    > > 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 don't have the time to fix your problems, why should anyone else
    have the time to fix your problems?

    That is BTW the typical "i'm your customer and you have to obey me"
    attitude. Perhaps you want to buy somewhere the time to fix your
    problems.

    Bernd
    --
    Firmix Software GmbH http://www.firmix.at/
    mobil: +43 664 4416156 fax: +43 1 7890849-55
    Embedded Linux Development and Services


    --
    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 08, 2008, at 15:51:53, Andi Kleen wrote:
    > Theodore Tso writes:
    >> 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").

    >
    > If these reasons are good ones (some skepticism here) then the
    > correct way to really handle this would be to do regular background
    > scrubbing during runtime; ideally with metadata checksums so that
    > you can actually detect all corruption.


    Poor man's background scrubbing:

    (A) Use LVM like virtually all modern distros offer
    (B) Leave some extra space in your LVM volume group (enough for 1
    snapshot over the time it takes to do an FSCK).
    (C) Periodically run the following scriptlet:

    set -e
    START="$(date +'%Y%m%d%H%M%S')"
    lvcreate -s -n "${VOLUME}-snap" "${VG}/${VOLUME}"
    if nice +20 fsck -fy "/dev/mapper/${VG}_${VOLUME}-snap"; then
    echo 'Background scrubbing succeeded!'
    tune2fs -T "${START}" "/dev/mapper/${VG}_${VOLUME}"
    else
    echo 'Background scrubbing failed! Reboot to fsck soon!'
    tune2fs -C 16383 -T "19000101" "/dev/mapper/${VG}_${VOLUME}"
    fi
    lvremove "${VG}/${VOLUME}-snap"

    Basically you can fsck the offline snapshot in the background. If it
    succeeds you can adjust the "last checked" date to the time when the
    snapshot was taken and if it fails you can schedule an FSCK at next
    reboot (and possibly remount the filesystem read-only or reboot
    immediately).

    You can do the same thing for your /boot volume, although you
    probably have to manually use dmsetup since most bootloaders can't
    interpret LVM volumes.

    I've always been surprised that distros like RedHat which
    automatically use LVM don't stuff this in their weekly or monthly
    checks on desktop systems. User experience could also be
    dramatically improved with automated smartd configuration and user-
    interactive logging and warning messages.


    > But since fsck is so slow and disks are so big this whole thing is
    > a ticking time bomb now. e.g. it is not uncommon to require tens of
    > minutes or even hours of fsck time and some server that reboots
    > only every few months will eat that when it happens to reboot. This
    > means you get a quite long downtime.


    My servers all have an "interval-between-checks" of 2-6 weeks and are
    configured to run nice +20 background "fsck" checks during off-hours
    between once every few days and once every few weeks. I also have
    the "max mount count" numbers set to primes between 7 and 37
    (depending on the filesystem) so that troubled or frequently-rebooted
    systems are more frequently verified. The end result is that I
    almost never have the dreaded 4-hour-fsck-on-boot problem. A drive
    has certainly been fscked within the last few weeks of operation, and
    I will only ever have multiple large filesystems all fscked at the
    same time very rarely (gcd of their max-mount-counts).

    Cheers,
    Kyle Moffett

    --
    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 Tue, 08 Jan 2008 22:21:02 EST, Kyle Moffett said:

    > lvcreate -s -n "${VOLUME}-snap" "${VG}/${VOLUME}"



    > Basically you can fsck the offline snapshot in the background.


    Something the lvcreate manpage is specifically not clear about is:

    Does this create a snapshot of the *disk* at that moment, or does it capture
    "disk plus still-to-be-written blocks in the cache"? (Phrased differently, does
    it Do The Right Thing regarding "blocks queued before lvcreate" and "blocks
    queued for write after lvcreate")?

    If the snapshot doesn't capture the blocks queued but still unwritten by
    kjournald and similar, then you're still hitting the same old problems that
    you always get when you fsck an "active disk".

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.8 (GNU/Linux)
    Comment: Exmh version 2.5 07/13/2001

    iD8DBQFHhH4JcC3lWbTT17ARAnyZAJ4kNHkzWhExqI7Ixs3hzG 5iltYaFACfWCYs
    hcPh59JbkgM702ChJhH65Yc=
    =f/oM
    -----END PGP SIGNATURE-----


  10. Re: The ext3 way of journalling

    The help for CONFIG_DM_SNAPSHOT says it is EXPERIMENTAL (in
    2.6.23.12). So this would mean that there is very high risk of
    software failure using snapshots. Would you want to do that for your
    fsck?

    On 1/9/08, Kyle Moffett wrote:
    > On Jan 08, 2008, at 15:51:53, Andi Kleen wrote:
    > > Theodore Tso writes:
    > >> 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").

    > >
    > > If these reasons are good ones (some skepticism here) then the
    > > correct way to really handle this would be to do regular background
    > > scrubbing during runtime; ideally with metadata checksums so that
    > > you can actually detect all corruption.

    >
    > Poor man's background scrubbing:
    >
    > (A) Use LVM like virtually all modern distros offer
    > (B) Leave some extra space in your LVM volume group (enough for 1
    > snapshot over the time it takes to do an FSCK).
    > (C) Periodically run the following scriptlet:
    >
    > set -e
    > START="$(date +'%Y%m%d%H%M%S')"
    > lvcreate -s -n "${VOLUME}-snap" "${VG}/${VOLUME}"
    > if nice +20 fsck -fy "/dev/mapper/${VG}_${VOLUME}-snap"; then
    > echo 'Background scrubbing succeeded!'
    > tune2fs -T "${START}" "/dev/mapper/${VG}_${VOLUME}"
    > else
    > echo 'Background scrubbing failed! Reboot to fsck soon!'
    > tune2fs -C 16383 -T "19000101" "/dev/mapper/${VG}_${VOLUME}"
    > fi
    > lvremove "${VG}/${VOLUME}-snap"
    >
    > Basically you can fsck the offline snapshot in the background. If it
    > succeeds you can adjust the "last checked" date to the time when the
    > snapshot was taken and if it fails you can schedule an FSCK at next
    > reboot (and possibly remount the filesystem read-only or reboot
    > immediately).
    >
    > You can do the same thing for your /boot volume, although you
    > probably have to manually use dmsetup since most bootloaders can't
    > interpret LVM volumes.
    >
    > I've always been surprised that distros like RedHat which
    > automatically use LVM don't stuff this in their weekly or monthly
    > checks on desktop systems. User experience could also be
    > dramatically improved with automated smartd configuration and user-
    > interactive logging and warning messages.
    >
    >
    > > But since fsck is so slow and disks are so big this whole thing is
    > > a ticking time bomb now. e.g. it is not uncommon to require tens of
    > > minutes or even hours of fsck time and some server that reboots
    > > only every few months will eat that when it happens to reboot. This
    > > means you get a quite long downtime.

    >
    > My servers all have an "interval-between-checks" of 2-6 weeks and are
    > configured to run nice +20 background "fsck" checks during off-hours
    > between once every few days and once every few weeks. I also have
    > the "max mount count" numbers set to primes between 7 and 37
    > (depending on the filesystem) so that troubled or frequently-rebooted
    > systems are more frequently verified. The end result is that I
    > almost never have the dreaded 4-hour-fsck-on-boot problem. A drive
    > has certainly been fscked within the last few weeks of operation, and
    > I will only ever have multiple large filesystems all fscked at the
    > same time very rarely (gcd of their max-mount-counts).
    >
    > Cheers,
    > Kyle Moffett
    >
    > --
    > 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/
    >

    --
    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 Wed, 09 Jan 2008 15:00:46 +0700, BuraphaLinux Server said:
    > The help for CONFIG_DM_SNAPSHOT says it is EXPERIMENTAL (in
    > 2.6.23.12). So this would mean that there is very high risk of
    > software failure using snapshots. Would you want to do that for your
    > fsck?


    The overall current state of EXPERIMENTAL in the tree is, quite frankly,
    somewhere between a complete crock and a wheelbarrow full of bovine fertilizer.
    There's a lot of things labeled EXPERIMENTAL that shouldn't be, and a lot of
    bleeding edge things that may eat your disks and cause your dog to turn green
    that aren't labelled EXPERIMENTAL.

    Having said that, I have *no* idea what state the snapshot code is in, but I
    have approximately zero confidence that the EXPERIMENTAL tag tells me anything
    actually useful about the snapshot code.


    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.8 (GNU/Linux)
    Comment: Exmh version 2.5 07/13/2001

    iD8DBQFHhIP0cC3lWbTT17ARApC/AKDlP1ovJqASpsFJkbTflFN8eGLrNgCg1Ul6
    6qsyttrUFbjoA+cZaZvoMC0=
    =tCzs
    -----END PGP SIGNATURE-----


  12. Re: The ext3 way of journalling

    On 2008-01-09 00:06 +0100, Matthias Schniedermeyer wrote:
    > That what LABEL und UUID-Support in mount is for.


    That's udev ****. I don't want it.

    --
    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/

  13. Re: The ext3 way of journalling

    On Jan 8, 2008 7:15 PM, Theodore Tso wrote:
    > 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.


    Actually you can force Windows to accept a hardware clock in UTC:
    HKEY_LOCAL_MACHINE/SYSTEMCurrentControlSetControl/TimeZoneInformation/RealTimeIsUniversal

    I'm using this on my dual-boot machine at home because I that stupid
    Daylight Savings Time change twice a year really annoyed me. So far
    the only downside I found is that you have to remember that the time
    you enter in the BIOS has to be UTC.

    --
    blue skies,
    Martin
    --
    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 09.01.2008 11:21, Matthias Schniedermeyer wrote:
    > On 09.01.2008 09:56, Tuomo Valkonen wrote:
    > > On 2008-01-09 00:06 +0100, Matthias Schniedermeyer wrote:
    > > > That what LABEL und UUID-Support in mount is for.

    > >
    > > That's udev ****. I don't want it.

    >
    > No.


    To be more verbose.

    The 'LABEL=' is native mount turf and is much older than udev.

    That udev ALSO supports the same labels, by providing sym-links in
    /dev/disk/by-label/<...>, is written on another page.




    Bis denn

    --
    Real Programmers consider "what you see is what you get" to be just as
    bad a concept in Text Editors as it is in women. No, the Real Programmer
    wants a "you asked for it, you got it" text editor -- complicated,
    cryptic, powerful, unforgiving, dangerous.

    --
    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 09.01.2008 09:56, Tuomo Valkonen wrote:
    > On 2008-01-09 00:06 +0100, Matthias Schniedermeyer wrote:
    > > That what LABEL und UUID-Support in mount is for.

    >
    > That's udev ****. I don't want it.


    No.




    Bis denn

    --
    Real Programmers consider "what you see is what you get" to be just as
    bad a concept in Text Editors as it is in women. No, the Real Programmer
    wants a "you asked for it, you got it" text editor -- complicated,
    cryptic, powerful, unforgiving, dangerous.

    --
    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 Wed, Jan 09, 2008 at 10:54:11AM +0100, Martin Schwidefsky wrote:
    > On Jan 8, 2008 7:15 PM, Theodore Tso wrote:
    > > 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.

    >
    > Actually you can force Windows to accept a hardware clock in UTC:
    > HKEY_LOCAL_MACHINE/SYSTEMCurrentControlSetControl/TimeZoneInformation/RealTimeIsUniversal


    Oh, so cool!!! Do you know off hand what version of Windows started
    honoring that registry setting?

    And what do you set that registry value to? Just a boolean "true"?

    Now, how to convince Ubuntu to put this in their FAQ so I stop having
    their ahhh, less than clueful dual-booting Windows users who happen to
    live in Europe stop submitting bugs on this issue....

    - 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/

  17. Re: The ext3 way of journalling

    On Wed, Jan 09, 2008 at 11:28:21AM +0100, Matthias Schniedermeyer wrote:
    > On 09.01.2008 11:21, Matthias Schniedermeyer wrote:
    > > On 09.01.2008 09:56, Tuomo Valkonen wrote:
    > > > On 2008-01-09 00:06 +0100, Matthias Schniedermeyer wrote:
    > > > > That what LABEL und UUID-Support in mount is for.
    > > >
    > > > That's udev ****. I don't want it.

    > >
    > > No.

    >
    > To be more verbose.
    >
    > The 'LABEL=' is native mount turf and is much older than udev.


    Native fsck supports it to; "LABEL=" and "UUID=" support has been in
    e2fsprogs since July 3rd, 1999. (Mount had it a little before then,
    but you needed both mount and fsck support before the feature could be
    used.)

    And it has *nothing* to do with udev....

    - 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/

  18. Re: The ext3 way of journalling

    On Wed, 9 Jan 2008 07:25:56 -0500
    Theodore Tso wrote:

    > On Wed, Jan 09, 2008 at 10:54:11AM +0100, Martin Schwidefsky wrote:
    > > On Jan 8, 2008 7:15 PM, Theodore Tso wrote:
    > > > 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.

    > >
    > > Actually you can force Windows to accept a hardware clock in UTC:
    > > HKEY_LOCAL_MACHINE/SYSTEMCurrentControlSetControl/TimeZoneInformation/RealTimeIsUniversal

    >
    > Oh, so cool!!! Do you know off hand what version of Windows started
    > honoring that registry setting?
    >
    > And what do you set that registry value to? Just a boolean "true"?
    >
    > Now, how to convince Ubuntu to put this in their FAQ so I stop having
    > their ahhh, less than clueful dual-booting Windows users who happen to
    > live in Europe stop submitting bugs on this issue....


    According to http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html it's
    been there since Windows NT, but it is more or less broken in all newer
    versions.

    Michal
    --
    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/

  19. Re: The ext3 way of journalling

    On Wed, Jan 09, 2008 at 02:55:53AM -0500, Valdis.Kletnieks@vt.edu wrote:
    >
    > Does this create a snapshot of the *disk* at that moment, or does it
    > capture "disk plus still-to-be-written blocks in the cache"?
    > (Phrased differently, does it Do The Right Thing regarding "blocks
    > queued before lvcreate" and "blocks queued for write after
    > lvcreate")?
    >
    > If the snapshot doesn't capture the blocks queued but still
    > unwritten by kjournald and similar, then you're still hitting the
    > same old problems that you always get when you fsck an "active
    > disk".


    Actually, it does better than that. For ext3 and xfs, it will take a
    snapshot of the filesystem in a quiscent state; that is, it will force
    the journal transaction to close, suspend all filesystem activity,
    take a snapshot of the disk as if it had been unmounted, and then
    allow filesystem activity to continue.

    So if you look at an ext3 filesystem taken in this way, you will see
    that the NEEDS_RECOVERY flag is not set, since the ext3 journal is
    empty on the snapshot. So snapshots are also a great way of doing
    stable backups. For the purposes of stable backups, you'll also want
    to quiesce your application files, particularly databases.

    For example, in the case of mysql, send the server the sql commands
    "flush tables with read lock; flush logs", take the snapshot, and
    then after the snapshot send the server the sql command "unlock tables".
    For more information, see:

    http://forums.mysql.com/read.php?26,...302#msg-185302

    If you do this, you will get a snapshot of your disk where *both* the
    database and the filesystem is at a stable state, perfect for doing a
    backup.

    - 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/

  20. Re: The ext3 way of journalling

    Vous m'avez dit récemment :

    > 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.


    fix your hardware clock then

    --
    Mathieu
    --
    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 2 of 4 FirstFirst 1 2 3 4 LastLast