Am Dienstag, den 10.03.2009, 16:50 + schrieb Chrissie Caulfield:
Marc - A. Dahlhaus wrote:
Chrissie Caulfield schrieb:
Marc - A. Dahlhaus [ Administration | Westermann GmbH ] wrote:
Hello,
what is the right approach to build LVM2 with STABLE3,
a build with
On 30/07/09 08:45, Marc - A. Dahlhaus [ Administration | Westermann GmbH
] wrote:
Am Dienstag, den 10.03.2009, 16:50 + schrieb Chrissie Caulfield:
Marc - A. Dahlhaus wrote:
Chrissie Caulfield schrieb:
Marc - A. Dahlhaus [ Administration | Westermann GmbH ] wrote:
Hello,
what is the
Am Donnerstag, den 30.07.2009, 10:01 +0100 schrieb Christine Caulfield:
On 30/07/09 08:45, Marc - A. Dahlhaus [ Administration | Westermann GmbH
] wrote:
Am Dienstag, den 10.03.2009, 16:50 + schrieb Chrissie Caulfield:
Marc - A. Dahlhaus wrote:
Chrissie Caulfield schrieb:
Marc - A.
On 30/07/09 11:36, Marc - A. Dahlhaus [ Administration | Westermann GmbH
] wrote:
Am Donnerstag, den 30.07.2009, 10:01 +0100 schrieb Christine Caulfield:
On 30/07/09 08:45, Marc - A. Dahlhaus [ Administration | Westermann GmbH
] wrote:
Am Dienstag, den 10.03.2009, 16:50 + schrieb Chrissie
Am Donnerstag, den 30.07.2009, 11:42 +0100 schrieb Christine Caulfield:
On 30/07/09 11:36, Marc - A. Dahlhaus [ Administration | Westermann GmbH
] wrote:
Am Donnerstag, den 30.07.2009, 10:01 +0100 schrieb Christine Caulfield:
On 30/07/09 08:45, Marc - A. Dahlhaus [ Administration |
On 30/07/09 11:52, Marc - A. Dahlhaus [ Administration | Westermann GmbH
] wrote:
Am Donnerstag, den 30.07.2009, 11:42 +0100 schrieb Christine Caulfield:
On 30/07/09 11:36, Marc - A. Dahlhaus [ Administration | Westermann GmbH
] wrote:
Am Donnerstag, den 30.07.2009, 10:01 +0100 schrieb
Am Donnerstag, den 30.07.2009, 11:54 +0100 schrieb Christine Caulfield:
On 30/07/09 11:52, Marc - A. Dahlhaus [ Administration | Westermann GmbH
] wrote:
Am Donnerstag, den 30.07.2009, 11:42 +0100 schrieb Christine Caulfield:
On 30/07/09 11:36, Marc - A. Dahlhaus [ Administration |
On 30/07/09 13:32, Marc - A. Dahlhaus [ Administration | Westermann GmbH
] wrote:
Am Donnerstag, den 30.07.2009, 11:54 +0100 schrieb Christine Caulfield:
On 30/07/09 11:52, Marc - A. Dahlhaus [ Administration | Westermann GmbH
] wrote:
Am Donnerstag, den 30.07.2009, 11:42 +0100 schrieb
Hi,
Here is the current content of the GFS2 -fixes git tree. Nothing
very exciting this time... some fixes for issues we've
had relating to flushing glocks/memory usage, plus a couple of
other fixes relating to statfs and the timely removal of inodes
which have been unlinked on a remote node,
From: Benjamin Marzinski bmarz...@redhat.com
It is possible for gfs2_shrink_glock_memory() to check a glock for
demotion
that's in the process of being freed by gfs2_glock_put(). In this case,
gfs2_shrink_glock_memory() will acquire a new reference to this glock,
and
then try to free the glock
From: Benjamin Marzinski bmarz...@redhat.com
GFS2 wasn't syncing its statfs info on grows. This causes a problem
when you grow the filesystem on multiple nodes. GFS2 would calculate
the new space based on the resource groups (which are always current),
and then assume that the filesystem had
When searching for unlinked, but still allocated inodes during block
allocation, avoid the block relating to the inode that is doing the
allocation. This fixes a hang caused when an unlinked, but still
open, inode tries to allocate some more blocks and lands up
finding itself during the search for
This patch removes some of the special cases that the shrinker
was trying to deal with. As a result we leave fewer items on
the list and none at all which cannot be demoted. This makes
the list scanning more efficient and solves some issues seen
with large numbers of inodes.
Signed-off-by: Steven
From: Benjamin Marzinski bmarz...@redhat.com
Since both linked and unlinked inodes are counted by rgd-rd_dinodes, It
makes no sense to count them with the used data blocks (first check that
I changed), it makes sense to count them with the linked inodes (second
check), and it makes no sense to
From: Benjamin Marzinski bmarz...@redhat.com
When a file is deleted from a gfs2 filesystem on one node, a dcache
entry for it may still exist on other nodes in the cluster. If this
happens, gfs2 will be unable to free this file on disk. Because of this,
it's possible to have a gfs2 filesystem
From: Benjamin Marzinski bmarz...@redhat.com
GFS2 was placing far too many glocks on the reclaim list that were not good
candidates for freeing up from cache. These locks would sit there and
repeatedly get scanned to see if they could be reclaimed, wasting a lot
of time when there was memory
Hi,
Please consider pulling the following changes,
Steve.
The following changes since commit 4be3bd7849165e7efa6b0b35a23d6a3598d97465:
Linus Torvalds (1):
Linux 2.6.31-rc4
are available in the git repository
Am Donnerstag, den 30.07.2009, 13:39 +0100 schrieb Christine Caulfield:
On 30/07/09 13:32, Marc - A. Dahlhaus [ Administration | Westermann GmbH
] wrote:
Am Donnerstag, den 30.07.2009, 11:54 +0100 schrieb Christine Caulfield:
On 30/07/09 11:52, Marc - A. Dahlhaus [ Administration |
Am Donnerstag, den 30.07.2009, 15:06 +0200 schrieb Marc - A. Dahlhaus
[ Administration | Westermann GmbH ]:
Am Donnerstag, den 30.07.2009, 13:39 +0100 schrieb Christine Caulfield:
On 30/07/09 13:32, Marc - A. Dahlhaus [ Administration | Westermann GmbH
] wrote:
Am Donnerstag, den
On 30/07/09 14:11, Marc - A. Dahlhaus [ Administration | Westermann GmbH
] wrote:
Am Donnerstag, den 30.07.2009, 15:06 +0200 schrieb Marc - A. Dahlhaus
[ Administration | Westermann GmbH ]:
Am Donnerstag, den 30.07.2009, 13:39 +0100 schrieb Christine Caulfield:
On 30/07/09 13:32, Marc - A.
I was working on fence_scsi configuration file and will be very happy
for opinions of larger audience for syntax/semantic.
Syntax:
Basically it's little improved corosync.conf so example:
# Comment line
# ^^^ white lines ignored
# Definition of device
/dev/sda
# Can be more
/dev/sdb
/dev/sdc
21 matches
Mail list logo
