From: Chris Mason <mason@suse.com>
To: linux-lvm@sistina.com
Subject: Re: [linux-lvm] snapshot of Reiserfs
Date: Wed, 21 Feb 2001 14:17:27 -0500 [thread overview]
Message-ID: <2320640000.982783047@tiny> (raw)
In-Reply-To: <200102211855.f1LItGq04889@webber.adilger.net>
On Wednesday, February 21, 2001 11:55:14 AM -0700 Andreas Dilger
<adilger@turbolinux.com> wrote:
>> > Given that the VFS support for the *unlockfs methods is included in
>> > 2.4.1, this should probably become something like:
>> >
>> > /* lvm_do_lv_create calls fsync_dev_lockfs()/unlockfs() */
>> > #if LINUX_KERNEL_VERSION >= KERNEL_VERSION(2,4,1)
>> > #define LVM_VFS_ENHANCEMENT
>> > #else
>> > /* Need to apply a kernel patch to add lockfs/unlockfs VFS methods */
>> > /* #define LVM_VFS_ENHANCEMENT */
>> > #endif
>> >
>>
>> I like this idea.
>
> Note that I thought the fsync_dev_lockfs() code was added to 2.4.1 when
> reiserfs was added. However, it appears that only the *lockfs pointers
> were added to the super_operations, and the actual code that uses them
> was NOT added. This means we can't do the above until fsync_dev_lockfs()
> is actually there.
>
Yes, it would have been smarter for me to push for the entire lockfs patch
a long time ago.
>> > Also, if the sync_supers_lockfs() method is changed to call
>> > write_super() if write_super_lockfs() doesn't exist, like:
>>
>> The fsync_dev_lockfs call does this for us, if there is no
>> write_super_lockfs provided, fsync_dev_lockfs is effectively the same as
>> calling fsync_dev.
>
> Except that fsync_dev() calls the write_super() method, and
> fsync_dev_lockfs() only calls the write_super_lockfs() method if it
> exists - it does not call write_super() if write_super_lockfs() does not
> exist. If it were changed as I suggest, then the two would be the same.
Hmmm, fsync_dev_lockfs should look like this:
+int fsync_dev_lockfs(kdev_t dev)
+{
+ sync_buffers(dev, 0);
+
+ lock_kernel();
+ sync_supers(dev);
^^^^^^^^^^^^^^^^^^
+ /* note, the FS might need to start transactions to
+ ** sync the inodes, or the quota, no locking until
+ ** after these are done
+ */
+ sync_inodes(dev);
+ DQUOT_SYNC(dev);
+ /* if inodes or quotas could be dirtied during the
+ ** sync_supers_lockfs call, the FS is responsible for getting
+ ** them on disk, without deadlocking against the lock
+ */
+ sync_supers_lockfs(dev) ;
+ unlock_kernel();
+
+ return sync_buffers(dev, 1) ;
+}
+
It is amost exactly a cut n' paste of fsync_dev, with an extra call to
sync_supers_lockfs. It should do what fsync_dev does, even when there are
no sync_super_lockfs methods are provided. The only reason I didn't just
call fsync_dev from fsync_dev_lockfs is because I wanted the sync_buffers
call to happen after the lockfs call ;-)
-chris
next prev parent reply other threads:[~2001-02-21 19:17 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-20 22:49 [linux-lvm] *** ANNOUNCEMENT *** LVM 0.9.1 beta5 available at www.sistina.com Heinz J. Mauelshagen
2001-02-20 22:42 ` [lvm-devel] " Andrea Arcangeli
2001-02-21 0:31 ` Andreas Dilger
2001-02-21 1:12 ` Andrea Arcangeli
2001-02-21 3:49 ` Richard Gooch
2001-02-21 17:00 ` Andrea Arcangeli
2001-02-21 17:03 ` Richard Gooch
2001-02-21 17:18 ` Christoph Hellwig
2001-02-22 4:12 ` Peter Samuelson
2001-02-22 9:46 ` Christoph Hellwig
2001-02-22 10:52 ` Peter Samuelson
2001-02-22 11:53 ` Christoph Hellwig
2001-02-21 4:19 ` [linux-lvm] snapshot of Reiserfs lvm, lvm
2001-02-21 8:59 ` Patrick Caulfield
2001-02-21 14:04 ` lvm
2001-02-21 14:11 ` Patrick Caulfield
2001-02-21 15:34 ` Chris Mason
2001-02-21 16:05 ` lvm
2001-02-21 16:12 ` Patrick Caulfield
2001-02-21 16:44 ` Andreas Dilger
2001-02-21 17:07 ` Chris Mason
2001-02-21 18:55 ` Andreas Dilger
2001-02-21 19:17 ` Chris Mason [this message]
2001-02-21 23:23 ` Andreas Dilger
2001-02-22 17:12 ` Chris Mason
-- strict thread matches above, loose matches on Subject: below --
2003-05-20 6:31 [linux-lvm] Snapshot of ReiserFS Dietmar Stein
2001-02-19 16:11 [linux-lvm] snapshot of Reiserfs lvm
2001-02-19 16:12 ` Joe Thornber
2001-02-19 17:04 ` Christoph Hellwig
2001-02-19 16:59 ` Joe Thornber
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=2320640000.982783047@tiny \
--to=mason@suse.com \
--cc=linux-lvm@sistina.com \
/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 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.