All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <mason@suse.com>
To: linux-lvm@sistina.com
Subject: Re: [linux-lvm] Snapshots with 2.4.1?
Date: Wed, 07 Feb 2001 17:32:37 -0500	[thread overview]
Message-ID: <721750000.981585157@tiny> (raw)
In-Reply-To: <20010207142510.D16262@ultraviolet.org>


On Wednesday, February 07, 2001 02:25:10 PM -0800 Tracy R Reed <treed@ultraviolet.org> wrote:

> On Fri, Feb 02, 2001 at 04:56:42PM +0000, Joe Thornber wrote:
>> 2.4.1 hadn't been released when we made the beta3 tarball.  If you
>> want to make a beta3 patch for the kernel create an empty file call
>> PATCHES/fragments-2.4.1 (2.4.1 needs no extra fragments) then run
>> PATCHES/make.  That should remove all the conflicts.
> 
> I need to get snapshots working with 2.4.1. I've tried using just the
> straight LVM that comes with the kernel and I have tried applying the
> patches as described above. I either case, when I uncomment:
> 
> #define LVM_VFS_ENHANCEMENT 
> 
> in drivers/md/lvm.c to enable the hooks for snapshots the compile fails:
> 
> drivers/md/mddev.o: In function `lvm_do_lv_create':
> drivers/md/mddev.o(.text+0x11bdb): undefined reference to `fsync_dev_lockfs'
> drivers/md/mddev.o(.text+0x11c90): undefined reference to `unlockfs'
> 
> Can someone point out what else I am missing?
> 

This patch should do it, the reiserfs in 2.4.1 has code to take advantage of it.

diff -urN diff/linux/fs/buffer.c linux/fs/buffer.c
--- diff/linux/fs/buffer.c	Tue Oct  3 12:31:22 2000
+++ linux/fs/buffer.c	Tue Oct  3 12:16:16 2000
@@ -312,6 +312,28 @@
 	return sync_buffers(dev, 1);
 }
 
+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) ;
+}
+
 asmlinkage long sys_sync(void)
 {
 	fsync_dev(0);
diff -urN diff/linux/fs/super.c linux/fs/super.c
--- diff/linux/fs/super.c	Tue Oct  3 12:31:23 2000
+++ linux/fs/super.c	Fri Sep 29 10:01:09 2000
@@ -628,6 +628,46 @@
 	}
 }
 
+/*
+ * Note: don't check the dirty flag before waiting, we want the lock
+ * to happen every time this is called.
+ */
+void sync_supers_lockfs(kdev_t dev)
+{
+	struct super_block * sb;
+
+	for (sb = sb_entry(super_blocks.next);
+	     sb != sb_entry(&super_blocks); 
+	     sb = sb_entry(sb->s_list.next)) {
+		if (!sb->s_dev)
+			continue;
+		if (dev && sb->s_dev != dev)
+			continue;
+		lock_super(sb);
+		if (sb->s_dev && (!dev || dev == sb->s_dev))
+			if (sb->s_op && sb->s_op->write_super_lockfs)
+				sb->s_op->write_super_lockfs(sb);
+		unlock_super(sb);
+	}
+}
+
+void unlockfs(kdev_t dev)
+{
+	struct super_block * sb;
+
+	for (sb = sb_entry(super_blocks.next);
+	     sb != sb_entry(&super_blocks); 
+	     sb = sb_entry(sb->s_list.next)) {
+		if (!sb->s_dev)
+			continue;
+		if (dev && sb->s_dev != dev)
+			continue;
+		if (sb->s_dev && (!dev || dev == sb->s_dev))
+			if (sb->s_op && sb->s_op->unlockfs)
+				sb->s_op->unlockfs(sb);
+	}
+}
+
 /**
  *	get_super	-	get the superblock of a device
  *	@dev: device to get the superblock for

      reply	other threads:[~2001-02-07 22:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-02 10:15 [linux-lvm] with 2.4.1, should I use beta2 or beta3 lvm-tools? Håkan Jettingstad
2001-02-02 10:30 ` Joe Thornber
2001-02-02 13:53   ` Rik van Riel
2001-02-02 15:54     ` Joe Thornber
2001-02-02 16:35       ` Rik van Riel
2001-02-02 16:58         ` Joe Thornber
2001-02-02 17:33           ` Rik van Riel
2001-02-02 16:25   ` Gregory McLean
2001-02-02 16:56     ` Joe Thornber
2001-02-07 22:25       ` [linux-lvm] Snapshots with 2.4.1? Tracy R Reed
2001-02-07 22:32         ` Chris Mason [this message]

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=721750000.981585157@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.