From: Andreas Dilger <adilger@enel.ucalgary.ca>
To: hpa@zytor.com (H. Peter Anvin)
Cc: linux-kernel@vger.kernel.org
Subject: Re: Dump corrupts ext2?
Date: Wed, 10 Oct 2001 21:13:40 -0600 (MDT) [thread overview]
Message-ID: <200110110313.f9B3Dje11005@munet-d.enel.ucalgary.ca> (raw)
In-Reply-To: <9q31re$7hb$1@cesium.transmeta.com> from "H. Peter Anvin" at Oct 10, 2001 07:57:50 PM
H. Peter Anvin writes:
> By author: Andreas Dilger <adilger@turbolabs.com>
> > In Linus kernels 2.4.11+ the block devices and filesystems all use the
> > page cache, so no more coherency issues.
>
> How do you find a random block in the page cache? Last my
> understanding was that the page cache is organized by inode/offset,
> which wouldn't lend itself to looking up a random hardware block.
Doh, you are right of course. I was just thinking "buffer cache" vs.
"page cache", but of course the address space of /dev/hda1 is different
than that of any file inside the mounted filesystem. However, at least
the ext2 metadata is coherent between user space and kernel space (which
is half the battle when doing a backup) and your file data can only be
a few seconds out of date.
> I understand this can be done by sending a "quiet point" command to the
> filesystems, followed by an LVM snapshot, but I doubt may people do that!
Yes, there is now a hook in the VFS to support a snapshot of the filesystem
for backups (or whatever), which LVM uses. It is directly supported by
ext3, reiserfs and XFS. Other filesystems will only have a fsync_dev() and
write_super done, but this should be enough to get things to disk.
It turns out that this is also a handy thing for doing "live" fsck on an
ext2/ext3 filesystem for systems which don't get rebooted very often - you
can still verify that the disk/cables/kernel haven't corrupted anything.
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
next prev parent reply other threads:[~2001-10-11 3:13 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-10-10 23:03 Lew Wolfgang
2001-10-10 23:11 ` Doug McNaught
2001-10-10 23:34 ` Andreas Dilger
2001-10-10 23:55 ` Doug McNaught
2001-10-11 1:48 ` Chris Mason
2001-10-11 4:16 ` Benjamin LaHaise
2001-10-11 4:29 ` Alexander Viro
2001-10-11 11:47 ` Chris Mason
2001-10-11 2:57 ` H. Peter Anvin
2001-10-11 3:13 ` Andreas Dilger [this message]
2001-10-11 0:38 ` Mike Fedyk
2001-10-11 5:07 ` Eric W. Biederman
2001-10-11 1:33 ` Richard Gooch
2001-10-11 4:25 ` Richard Gooch
2001-10-10 23:28 ` H. Peter Anvin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200110110313.f9B3Dje11005@munet-d.enel.ucalgary.ca \
--to=adilger@enel.ucalgary.ca \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®