linux-kernel - Re: GFS2: Add blktrace support to glocks

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 20 Feb 2009 08:16:58 +0000
From:	Steven Whitehouse <swhiteho@...hat.com>
To:	Christoph Hellwig <hch@...radead.org>
Cc:	cluster-devel@...hat.com, linux-kernel@...r.kernel.org,
	linux-btrace@...r.kernel.org, axboe@...nel.dk
Subject: Re: GFS2: Add blktrace support to glocks

Hi,

On Thu, 2009-02-19 at 13:59 -0500, Christoph Hellwig wrote:
> On Thu, Feb 19, 2009 at 04:55:39PM +0000, Steven Whitehouse wrote:
> > Hi,
> > 
> > Since I last posted this pair of patches, I've done some extensive
> > updating of the kernel patch, so it should now be happy to compile
> > under all possible Kconfigs (fingers crossed) and also its a fair
> > bit cleaner too.
> > 
> > I'm adding the linux-btrace list, since I didn't know about that
> > list when I made the initial posting.
> > 
> > Since there is probably more GFS2 changes than blktrace changes, I
> > could push this through the GFS2 tree. Let me know if you'd prefer
> > it to go via the blktrace tree. I'd like to be able to push this
> > in at the next merge window if possible. This patch is against the
> > head of the GFS2 -nmw git tree (obviously that makes no difference
> > to the blktrace side of the patch).
> > 
> > An updated blktrace userland patch follows in the next email, although
> > the changes from the last version are fairly minor,
> 
> Umm, why would you put fs internal stuff into blktrace?  Just use
> the generic ringbuffer directly and trace into that one.
> 

>>From the patch description:

Glocks are the cache control subsystem for GFS2. It is very useful
to be able to trace the state changes of the glocks using the
same set of sequence numbers as the I/O requests, since this
allows us to see if there are any ordering errors.


Maybe there is a way to keep the sequencing between I/O and glocks some
other way, but it looked to me like I would lose that if I were to have
a separate logging system for glocks. So really what I'm saying is that
logging glocks on their own isn't a lot of use, its only useful when
combined with I/O logging,

Steve.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/