Re: [Cluster-devel] [PATCH 2/2] fence_scsi: remove limitations section from man page
ACK On 04/18/2012 02:02 AM, Ryan O'Hara wrote: > Resolves: rhbz#753839 > > Signed-off-by: Ryan O'Hara > --- > fence/man/fence_scsi.8 |7 --- > 1 files changed, 0 insertions(+), 7 deletions(-) > > diff --git a/fence/man/fence_scsi.8 b/fence/man/fence_scsi.8 > index 8a2d5a8..d9ab03f 100644 > --- a/fence/man/fence_scsi.8 > +++ b/fence/man/fence_scsi.8 > @@ -99,12 +99,5 @@ Name of the node to be fenced. > \fIverbose = < param >\fR > Verbose output. > -.SH LIMITATIONS > -The fence_scsi fencing agent requires a minimum of three nodes in the > -cluster to operate. For SAN devices connected via fiber channel, > -these must be physical nodes. SAN devices connected via iSCSI may use > -virtual or physical nodes. In addition, fence_scsi cannot be used in > -conjunction with qdisk. > - > .SH SEE ALSO > fence(8), fence_node(8), sg_persist(8), lvs(8), lvm.conf(5)
Re: [Cluster-devel] [PATCH 1/2] fence_scsi: fix typos in debug messages
ACK
On 04/18/2012 02:01 AM, Ryan O'Hara wrote:
> Resolves: rhbz#674497
>
> Signed-off-by: Ryan O'Hara
> ---
> fence/agents/scsi/fence_scsi.pl |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fence/agents/scsi/fence_scsi.pl
> b/fence/agents/scsi/fence_scsi.pl
> index 91f113d..84cee91 100755
> --- a/fence/agents/scsi/fence_scsi.pl
> +++ b/fence/agents/scsi/fence_scsi.pl
> @@ -111,7 +111,7 @@ sub get_node_id
> sub get_node_name
> {
> -print "[$pname]: get_hode_name = $opt_n\n" if $opt_v;
> +print "[$pname]: get_node_name = $opt_n\n" if $opt_v;
> return $opt_n;
> }
> @@ -163,7 +163,7 @@ sub get_host_name
> }
> }
> -print "[$pname]: get_host_nam = $host_name\n" if $opt_v;
> +print "[$pname]: get_host_name = $host_name\n" if $opt_v;
> return $host_name;
> }
[Cluster-devel] [PATCH 2/2] fence_scsi: remove limitations section from man page
Resolves: rhbz#753839 Signed-off-by: Ryan O'Hara --- fence/man/fence_scsi.8 |7 --- 1 files changed, 0 insertions(+), 7 deletions(-) diff --git a/fence/man/fence_scsi.8 b/fence/man/fence_scsi.8 index 8a2d5a8..d9ab03f 100644 --- a/fence/man/fence_scsi.8 +++ b/fence/man/fence_scsi.8 @@ -99,12 +99,5 @@ Name of the node to be fenced. \fIverbose = < param >\fR Verbose output. -.SH LIMITATIONS -The fence_scsi fencing agent requires a minimum of three nodes in the -cluster to operate. For SAN devices connected via fiber channel, -these must be physical nodes. SAN devices connected via iSCSI may use -virtual or physical nodes. In addition, fence_scsi cannot be used in -conjunction with qdisk. - .SH SEE ALSO fence(8), fence_node(8), sg_persist(8), lvs(8), lvm.conf(5) -- 1.7.1
[Cluster-devel] [PATCH 1/2] fence_scsi: fix typos in debug messages
Resolves: rhbz#674497
Signed-off-by: Ryan O'Hara
---
fence/agents/scsi/fence_scsi.pl |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fence/agents/scsi/fence_scsi.pl
b/fence/agents/scsi/fence_scsi.pl
index 91f113d..84cee91 100755
--- a/fence/agents/scsi/fence_scsi.pl
+++ b/fence/agents/scsi/fence_scsi.pl
@@ -111,7 +111,7 @@ sub get_node_id
sub get_node_name
{
-print "[$pname]: get_hode_name = $opt_n\n" if $opt_v;
+print "[$pname]: get_node_name = $opt_n\n" if $opt_v;
return $opt_n;
}
@@ -163,7 +163,7 @@ sub get_host_name
}
}
-print "[$pname]: get_host_nam = $host_name\n" if $opt_v;
+print "[$pname]: get_host_name = $host_name\n" if $opt_v;
return $host_name;
}
--
1.7.1
Re: [Cluster-devel] [PATCH 00/19 v5] Fix filesystem freezing deadlocks
On Tue, Apr 17, 2012 at 11:32:46AM +0200, Jan Kara wrote: > On Mon 16-04-12 15:02:50, Andreas Dilger wrote: > > On 2012-04-16, at 9:13 AM, Jan Kara wrote: > > > Another potential contention point might be patch 19. In that patch > > > we make freeze_super() refuse to freeze the filesystem when there > > > are open but unlinked files which may be impractical in some cases. > > > The main reason for this is the problem with handling of file deletion > > > from fput() called with mmap_sem held (e.g. from munmap(2)), and > > > then there's the fact that we cannot really force such filesystem > > > into a consistent state... But if people think that freezing with > > > open but unlinked files should happen, then I have some possible > > > solutions in mind (maybe as a separate patchset since this is > > > large enough). > > > > Looking at a desktop system, I think it is very typical that there > > are open-unlinked files present, so I don't know if this is really > > an acceptable solution. It isn't clear from your comments whether > > this is a blanket refusal for all open-unlinked files, or only in > > some particular cases... > Thanks for looking at this. It is currently a blanket refusal. And I > agree it's problematic. There are two problems with open but unlinked > files. Let me add my name to the chorus of "we have to handle freezing with open+unlinked, we cannot assume they don't exist." > One is that some old filesystems cannot get in a consistent state in > presence of open but unlinked files but for filesystems we really care > about - xfs, ext4, ext3, btrfs, or even ocfs2, gfs2 - that is not a real > issue (these filesystems will delete those inodes on next mount read-write). Others have pointed out that we can flag the safe filesystems. I'd even be willing to say you can't freeze the unsafe filesystems. > The other problem is with what should happen when you put last inode > reference on a frozen filesystem. Two possibilities I see are: > > a) block the iput() call - that is inconvenient because it can be > called in various contexts. I think we could possibly use the same level of > freeze protection as for page fault (this has changed since I originally > thought about this and that would make things simpler) but I'm not > completely sure. Given that frozen filesystems can stay that way for a while, couldn't that lead to a million frozen df(1)s? It's like your average NFS network failure. > b) let the iput finish but filesystem will keep inode on its orphan list > (or it's equivalent) and the inode will be deleted after the filesystem is > thawed. The advantage of this is we don't have to block iput(), the > disadvantage is we have to have filesystem support and not all filesystems > can do this. Perhaps we handle iput() like unlinked. If the filesystem can handle it, we allow it, otherwise we block. Joel > > Any thoughts? > > Honza > > > > lsof | grep deleted > > nautilus 25393 adilger 19r REG 253,0 340 253954 > > /home/adilger/.local/share/gvfs-metadata/home (deleted) > > nautilus 25393 adilger 20r REG 253,032768 253964 > > /home/adilger/.local/share/gvfs-metadata/home-f332a8f3.log (deleted) > > gnome-ter 25623 adilger 22u REG0,18178412717846 > > /tmp/vtePIRJCW (deleted) > > gnome-ter 25623 adilger 23u REG0,18 55682717847 > > /tmp/vteDCSJCW (deleted) > > gnome-ter 25623 adilger 29u REG0,18 4802728484 > > /tmp/vte6C1TCW (deleted) > > -- > Jan Kara > SUSE Labs, CR -- "The first requisite of a good citizen in this republic of ours is that he shall be able and willing to pull his weight." - Theodore Roosevelt http://www.jlbec.org/ jl...@evilplan.org
Re: [Cluster-devel] [PATCH 00/19 v5] Fix filesystem freezing deadlocks
On Mon 16-04-12 15:02:50, Andreas Dilger wrote: > On 2012-04-16, at 9:13 AM, Jan Kara wrote: > > Another potential contention point might be patch 19. In that patch > > we make freeze_super() refuse to freeze the filesystem when there > > are open but unlinked files which may be impractical in some cases. > > The main reason for this is the problem with handling of file deletion > > from fput() called with mmap_sem held (e.g. from munmap(2)), and > > then there's the fact that we cannot really force such filesystem > > into a consistent state... But if people think that freezing with > > open but unlinked files should happen, then I have some possible > > solutions in mind (maybe as a separate patchset since this is > > large enough). > > Looking at a desktop system, I think it is very typical that there > are open-unlinked files present, so I don't know if this is really > an acceptable solution. It isn't clear from your comments whether > this is a blanket refusal for all open-unlinked files, or only in > some particular cases... Thanks for looking at this. It is currently a blanket refusal. And I agree it's problematic. There are two problems with open but unlinked files. One is that some old filesystems cannot get in a consistent state in presence of open but unlinked files but for filesystems we really care about - xfs, ext4, ext3, btrfs, or even ocfs2, gfs2 - that is not a real issue (these filesystems will delete those inodes on next mount read-write). The other problem is with what should happen when you put last inode reference on a frozen filesystem. Two possibilities I see are: a) block the iput() call - that is inconvenient because it can be called in various contexts. I think we could possibly use the same level of freeze protection as for page fault (this has changed since I originally thought about this and that would make things simpler) but I'm not completely sure. b) let the iput finish but filesystem will keep inode on its orphan list (or it's equivalent) and the inode will be deleted after the filesystem is thawed. The advantage of this is we don't have to block iput(), the disadvantage is we have to have filesystem support and not all filesystems can do this. Any thoughts? Honza > > lsof | grep deleted > nautilus 25393 adilger 19r REG 253,0 340 253954 > /home/adilger/.local/share/gvfs-metadata/home (deleted) > nautilus 25393 adilger 20r REG 253,032768 253964 > /home/adilger/.local/share/gvfs-metadata/home-f332a8f3.log (deleted) > gnome-ter 25623 adilger 22u REG0,18178412717846 > /tmp/vtePIRJCW (deleted) > gnome-ter 25623 adilger 23u REG0,18 55682717847 > /tmp/vteDCSJCW (deleted) > gnome-ter 25623 adilger 29u REG0,18 4802728484 > /tmp/vte6C1TCW (deleted) -- Jan Kara SUSE Labs, CR
