From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24354 invoked by alias); 10 Nov 2006 22:16:51 -0000 Received: (qmail 24249 invoked by uid 9475); 10 Nov 2006 22:16:47 -0000 Date: Fri, 10 Nov 2006 22:16:00 -0000 Message-ID: <20061110221647.24248.qmail@sourceware.org> From: bmarzins@sourceware.org To: cluster-cvs@sources.redhat.com Subject: cluster gfs-kernel/src/gfs/recovery.c gnbd-ker ... Mailing-List: contact cluster-cvs-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: cluster-cvs-owner@sourceware.org X-SW-Source: 2006-q4/txt/msg00394.txt.bz2 List-Id: CVSROOT: /cvs/cluster Module name: cluster Branch: RHEL5 Changes by: bmarzins@sourceware.org 2006-11-10 22:16:47 Modified files: gfs-kernel/src/gfs: recovery.c gnbd-kernel/src: gnbd.c Log message: fix for bz215095 & 215099. for 215099, gnbd now only handles signals in sock_xmit() when it is called by the gnbd_recvd process. Otherwise, it simply blocks the signals until it completes the IO. This keeps gnbd from sending partial requests to the server, which can lead to data corruption. for 215095, the gfs function clean_journal() now uses the noinline attriubute, gfs_find_jhead() only uses on struct gfs_log_header, and gfs_recover_journal() dynamically allocates its struct gfs_log_header, all to conserve stack space. In the gnbd function sock_xmit(), you no longer get the signal info, so gnbd_recvd cannot print which signal it received, but it saves over 120 bytes of stack space. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/recovery.c.diff?cvsroot=cluster&only_with_tag=RHEL5&r1=1.9&r2=1.9.2.1 http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gnbd-kernel/src/gnbd.c.diff?cvsroot=cluster&only_with_tag=RHEL5&r1=1.15&r2=1.15.2.1