From amit.sahrawat83@gmail.com Wed Dec 1 01:13:20 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.9 required=5.0 tests=BAYES_50,FREEMAIL_FROM, HTML_MESSAGE,J_CHICKENPOX_46,T_DKIM_INVALID autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB17DJhq183896 for ; Wed, 1 Dec 2010 01:13:20 -0600 X-ASG-Debug-ID: 1291187699-7bb202420000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-qy0-f181.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 603831C85653 for ; Tue, 30 Nov 2010 23:14:59 -0800 (PST) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.216.181]) by cuda.sgi.com with ESMTP id M6hQb6dEIOfeklxh for ; Tue, 30 Nov 2010 23:14:59 -0800 (PST) Received: by qyk12 with SMTP id 12so7482028qyk.5 for ; Tue, 30 Nov 2010 23:14:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=2KY/5nuxsrUFEXqaLX3/mYQnOfJwfBTwXzBGUOh8mD4=; b=AidEvLXC+1nC50PHVzWwk87pvpApNPSadIMVaI2aY05Ahe/BHF/yPBvHy/cSK0Y2A6 4UtPUdOX4JG4FTxeOt/OsTqSYo0yKfWLCAjFsS8h7rqITTrs5Ixkvpy2+kIK12LOepMK hHd6ywe56LiemULfTBOY1dB2g+Uw67FC/aIAU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=weZ2QikcmXIs815Ub9GZfICraxlkNrPKmzSGVkiFqccyZmmD/OGJxR0RydIKR9qysU Co1n3WYW+xFgtYI8ZnqGP2R2B8yDrOpXuv1mNTU9GnFHJbF85Rck66vPaUZ1GtYCLyBZ y90WEQKcNpn4NwSOD+XPvlWvuGx8PPZ18A0iI= MIME-Version: 1.0 Received: by 10.224.6.141 with SMTP id 13mr7708468qaz.26.1291187699083; Tue, 30 Nov 2010 23:14:59 -0800 (PST) Received: by 10.220.194.3 with HTTP; Tue, 30 Nov 2010 23:14:58 -0800 (PST) Date: Wed, 1 Dec 2010 12:44:58 +0530 Message-ID: X-ASG-Orig-Subj: XFS file system corruption(Return Bad Transaction) kernel - 2.6.34 Subject: XFS file system corruption(Return Bad Transaction) kernel - 2.6.34 From: Amit Sahrawat To: Eric Sandeen , xfs@oss.sgi.com, sandeen-xfs@sandeen.net Content-Type: multipart/alternative; boundary=0015175cb71a246c770496541099 X-Barracuda-Connect: mail-qy0-f181.google.com[209.85.216.181] X-Barracuda-Start-Time: 1291187700 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.50 X-Barracuda-Spam-Status: No, SCORE=-1.50 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=DKIM_SIGNED, DKIM_VERIFIED, HTML_MESSAGE, MIME_BASE64_TEXT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48143 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.00 HTML_MESSAGE BODY: HTML included in message 0.52 MIME_BASE64_TEXT RAW: Message text disguised using base64 encoding X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --0015175cb71a246c770496541099 Content-Type: text/plain; charset=ISO-8859-1 Dear Member, I am getting following corruption on XFS formatted disk during a simple copy operation: sd 9:0:0:0: Attached scsi removable disk sdc sd 9:0:0:0: Attached scsi generic sg2 type 0 XFS mounting filesystem sdc2 Starting XFS recovery on filesystem: sdc2 (logdev: internal) XFS: xlog_recover_process_data: bad transaction XFS: log mount/recovery failed: error 5 XFS: log mount failed [root@localhost TEGRA]# [root@localhost TEGRA]# mount /dev/sdc2 /mnt/ mount: /dev/sdc2: can't read superblock [root@localhost TEGRA]# xfs_logprint -t /dev/sdc2 xfs_logprint: data device: 0x822 log device: 0x822 daddr: 6809632 length: 20480 log tail: 284 head: 412 state: LOG REC AT LSN cycle 1 block 284 (0x1, 0x11c) ============================================================================ TRANS: tid:0x863c5000 type:CREATE #items:5 trans:0x0 q:0x80b5c08 BUF: cnt:2 total:2 a:0x80ad6f8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x2 len:1 bmap size:1 flags:0x0 AGI Buffer: (XAGI) BUF: cnt:2 total:2 a:0x80ad7b8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x18 len:8 bmap size:2 flags:0x0 BUF DATA INO: cnt:2 total:2 a:0x80adaa8 len:56 a:0x80adb20 len:96 INODE: #regs:2 ino:0x85 flags:0x1 dsize:0 CORE inode: INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80b5c48 len:96 a:0x80b5cb0 len:68 INODE: #regs:3 ino:0x80 flags:0x3 dsize:68 CORE inode: DATA FORK LOCAL inode data: BUF: cnt:2 total:2 a:0x80b5cf8 len:24 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5d18 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80adbe8 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80adbc8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80adae8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c08 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c48 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5c68 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80b5c88 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80ad6f8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80ad7b8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c28 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5d18 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5cf8 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80adbe8 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80adbc8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80adae8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c08 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c68 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5c48 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80b5c88 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80ad6f8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80ad7b8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c28 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5cf8 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5d18 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80adbe8 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80adbc8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80adae8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c08 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c48 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5c68 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80b5c88 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80ad6f8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80ad7b8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c28 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5d18 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5cf8 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80adbe8 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80adbc8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80adae8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c08 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c68 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5c48 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80b5c88 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80ad6f8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80ad7b8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c28 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5cf8 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5d18 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80adbe8 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80adbc8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80adae8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c08 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c48 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5c68 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80b5c88 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80ad6f8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80ad7b8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c28 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5d18 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5cf8 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80adbe8 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80adbc8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80adae8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c08 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c68 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5c48 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80b5c88 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80ad6f8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80ad7b8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c28 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5cf8 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5d18 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80adbe8 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80adbc8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80adae8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c08 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c48 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5c68 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80b5c88 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80ad6f8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80ad7b8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c28 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5d18 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5cf8 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80adbe8 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80adbc8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80adae8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c08 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c68 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5c48 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80b5c88 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80ad6f8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80ad7b8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c28 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5cf8 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5d18 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80adbe8 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80adbc8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80adae8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c08 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c48 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5c68 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80b5c88 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80ad6f8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80ad7b8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c28 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5d18 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5cf8 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80adbe8 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80adbc8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80adae8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c08 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c68 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5c48 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80b5c88 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80ad6f8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80ad7b8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c28 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5cf8 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5d18 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80adbe8 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80adbc8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80adae8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c08 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c48 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5c68 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80b5c88 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80ad6f8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80ad7b8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c28 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5d18 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5cf8 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80adbe8 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80adbc8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80adae8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c08 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c68 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5c48 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80b5c88 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80ad6f8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80ad7b8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c28 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5cf8 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5d18 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80adbe8 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80adbc8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80adae8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c08 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c48 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5c68 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80b5c88 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80ad6f8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80ad7b8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c28 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5d18 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5cf8 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80adbe8 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80adbc8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80adae8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c08 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c68 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5c48 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80b5c88 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80ad6f8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80ad7b8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c28 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5cf8 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5d18 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80adbe8 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80adbc8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80adae8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c08 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c48 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5c68 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80b5c88 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80ad6f8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80ad7b8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c28 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5d18 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5cf8 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80adbe8 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80adbc8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80adae8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c08 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c68 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: ============================================================================ TRANS: tid:0x863c5000 type:STRAT_WRITE #items:5 trans:0x0 q:0x80b5c48 INO: cnt:3 total:3 a:0x80adb88 len:56 a:0x80adb20 len:96 a:0x80b5c88 len:16 INODE: #regs:3 ino:0x85 flags:0x5 dsize:16 CORE inode: DATA FORK EXTENTS inode data: BUF: cnt:2 total:2 a:0x80ad6f8 len:24 a:0x80ad730 len:128 BUF: #regs:2 start blkno:0x1 len:1 bmap size:1 flags:0x0 AGF Buffer: (XAGF) BUF: cnt:2 total:2 a:0x80ad7b8 len:28 a:0x80ada20 len:128 BUF: #regs:2 start blkno:0x10 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5c28 len:28 a:0x80b5d38 len:128 BUF: #regs:2 start blkno:0x8 len:8 bmap size:2 flags:0x0 BUF DATA BUF: cnt:2 total:2 a:0x80b5cf8 len:24 a:0x80b5dc0 len:128 BUF: #regs:2 start blkno:0x0 len:1 bmap size:1 flags:0x0 SUPER Block Buffer: LOG REC AT LSN cycle 1 block 348 (0x1, 0x15c) XFS: xlog_recover_process_data: bad transaction xfs_logprint: failed in xfs_do_recovery_pass, error: 5 --0015175cb71a246c770496541099 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: base64 PGRpdj5EZWFyIE1lbWJlciw8L2Rpdj4KPGRpdj6gPC9kaXY+CjxkaXY+SSBhbSBnZXR0aW5nIGZv bGxvd2luZyBjb3JydXB0aW9uIG9uIFhGUyBmb3JtYXR0ZWQgZGlzayBkdXJpbmcgYSBzaW1wbGUg Y29weSBvcGVyYXRpb246PC9kaXY+CjxkaXY+c2QgOTowOjA6MDogQXR0YWNoZWQgc2NzaSByZW1v dmFibGUgZGlzayBzZGM8YnI+c2QgOTowOjA6MDogQXR0YWNoZWQgc2NzaSBnZW5lcmljIHNnMiB0 eXBlIDA8YnI+WEZTIG1vdW50aW5nIGZpbGVzeXN0ZW0gc2RjMjxicj5TdGFydGluZyBYRlMgcmVj b3Zlcnkgb24gZmlsZXN5c3RlbTogc2RjMiAobG9nZGV2OiBpbnRlcm5hbCk8YnI+WEZTOiB4bG9n X3JlY292ZXJfcHJvY2Vzc19kYXRhOiBiYWQgdHJhbnNhY3Rpb248YnI+ClhGUzogbG9nIG1vdW50 L3JlY292ZXJ5IGZhaWxlZDogZXJyb3IgNTxicj5YRlM6IGxvZyBtb3VudCBmYWlsZWQ8YnI+W3Jv b3RAbG9jYWxob3N0IFRFR1JBXSMgPGJyPltyb290QGxvY2FsaG9zdCBURUdSQV0jIG1vdW50IC9k ZXYvc2RjMiAvbW50Lzxicj5tb3VudDogL2Rldi9zZGMyOiBjYW4mIzM5O3QgcmVhZCBzdXBlcmJs b2NrPGJyPltyb290QGxvY2FsaG9zdCBURUdSQV0jIHhmc19sb2dwcmludCAtdCAvZGV2L3NkYzI8 YnI+Cnhmc19sb2dwcmludDo8YnI+oKCgIGRhdGEgZGV2aWNlOiAweDgyMjxicj6goKAgbG9nIGRl dmljZTogMHg4MjIgZGFkZHI6IDY4MDk2MzIgbGVuZ3RoOiAyMDQ4MDxicj6gPGJyPqCgoCBsb2cg dGFpbDogMjg0IGhlYWQ6IDQxMiBzdGF0ZTogJmx0O0RJUlRZJmd0Ozxicj6gPGJyPqA8YnI+TE9H IFJFQyBBVCBMU04gY3ljbGUgMSBibG9jayAyODQgKDB4MSwgMHgxMWMpPGJyPj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT08YnI+ClRSQU5TOiB0aWQ6MHg4NjNjNTAwMKAgdHlwZTpDUkVBVEWgICNpdGVtczo1 oCB0cmFuczoweDCgIHE6MHg4MGI1YzA4PGJyPkJVRjogY250OjIgdG90YWw6MiBhOjB4ODBhZDZm OCBsZW46MjQgYToweDgwYWQ3MzAgbGVuOjEyOCA8YnI+oKCgoKCgoCBCVUY6oCAjcmVnczoyoKAg c3RhcnQgYmxrbm86MHgyoKAgbGVuOjGgoCBibWFwIHNpemU6MaCgIGZsYWdzOjB4MDxicj6goKCg oKCgIEFHSSBCdWZmZXI6IChYQUdJKTxicj4KQlVGOiBjbnQ6MiB0b3RhbDoyIGE6MHg4MGFkN2I4 IGxlbjoyOCBhOjB4ODBhZGEyMCBsZW46MTI4IDxicj6goKCgoKCgIEJVRjqgICNyZWdzOjKgoCBz dGFydCBibGtubzoweDE4oKAgbGVuOjigoCBibWFwIHNpemU6MqCgIGZsYWdzOjB4MDxicj6goKCg oKCgIEJVRiBEQVRBPGJyPklOTzogY250OjIgdG90YWw6MiBhOjB4ODBhZGFhOCBsZW46NTYgYTow eDgwYWRiMjAgbGVuOjk2IDxicj4KoKCgoKCgoCBJTk9ERTogI3JlZ3M6MqCgIGlubzoweDg1oCBm bGFnczoweDGgoCBkc2l6ZTowPGJyPqCgoKCgoKAgQ09SRSBpbm9kZTo8YnI+SU5POiBjbnQ6MyB0 b3RhbDozIGE6MHg4MGFkYjg4IGxlbjo1NiBhOjB4ODBiNWM0OCBsZW46OTYgYToweDgwYjVjYjAg bGVuOjY4IDxicj6goKCgoKCgIElOT0RFOiAjcmVnczozoKAgaW5vOjB4ODCgIGZsYWdzOjB4M6Cg IGRzaXplOjY4PGJyPqCgoKCgoKAgQ09SRSBpbm9kZTo8YnI+CqCgoKCgoKCgoKCgoKCgoCBEQVRB IEZPUksgTE9DQUwgaW5vZGUgZGF0YTo8YnI+QlVGOiBjbnQ6MiB0b3RhbDoyIGE6MHg4MGI1Y2Y4 IGxlbjoyNCBhOjB4ODBiNWQzOCBsZW46MTI4IDxicj6goKCgoKCgIEJVRjqgICNyZWdzOjKgoCBz dGFydCBibGtubzoweDCgoCBsZW46MaCgIGJtYXAgc2l6ZToxoKAgZmxhZ3M6MHgwPGJyPqCgoKCg oKAgU1VQRVIgQmxvY2sgQnVmZmVyOjxicj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPgpUUkFOUzog dGlkOjB4ODYzYzUwMDCgIHR5cGU6U1RSQVRfV1JJVEWgICNpdGVtczo1oCB0cmFuczoweDCgIHE6 MHg4MGI1ZDE4PGJyPklOTzogY250OjMgdG90YWw6MyBhOjB4ODBhZGI4OCBsZW46NTYgYToweDgw YWRiMjAgbGVuOjk2IGE6MHg4MGFkYmU4IGxlbjoxNiA8YnI+oKCgoKCgoCBJTk9ERTogI3JlZ3M6 M6CgIGlubzoweDg1oCBmbGFnczoweDWgoCBkc2l6ZToxNjxicj6goKCgoKCgIENPUkUgaW5vZGU6 PGJyPgqgoKCgoKCgoKCgoKCgoKAgREFUQSBGT1JLIEVYVEVOVFMgaW5vZGUgZGF0YTo8YnI+QlVG OiBjbnQ6MiB0b3RhbDoyIGE6MHg4MGFkYmM4IGxlbjoyNCBhOjB4ODBhZDczMCBsZW46MTI4IDxi cj6goKCgoKCgIEJVRjqgICNyZWdzOjKgoCBzdGFydCBibGtubzoweDGgoCBsZW46MaCgIGJtYXAg c2l6ZToxoKAgZmxhZ3M6MHgwPGJyPqCgoKCgoKAgQUdGIEJ1ZmZlcjogKFhBR0YpPGJyPkJVRjog Y250OjIgdG90YWw6MiBhOjB4ODBhZGFlOCBsZW46MjggYToweDgwYWRhMjAgbGVuOjEyOCA8YnI+ CqCgoKCgoKAgQlVGOqAgI3JlZ3M6MqCgIHN0YXJ0IGJsa25vOjB4MTCgoCBsZW46OKCgIGJtYXAg c2l6ZToyoKAgZmxhZ3M6MHgwPGJyPqCgoKCgoKAgQlVGIERBVEE8YnI+QlVGOiBjbnQ6MiB0b3Rh bDoyIGE6MHg4MGI1YzA4IGxlbjoyOCBhOjB4ODBiNWQzOCBsZW46MTI4IDxicj6goKCgoKCgIEJV RjqgICNyZWdzOjKgoCBzdGFydCBibGtubzoweDigoCBsZW46OKCgIGJtYXAgc2l6ZToyoKAgZmxh Z3M6MHgwPGJyPgqgoKCgoKCgIEJVRiBEQVRBPGJyPkJVRjogY250OjIgdG90YWw6MiBhOjB4ODBi NWM0OCBsZW46MjQgYToweDgwYjVkYzAgbGVuOjEyOCA8YnI+oKCgoKCgoCBCVUY6oCAjcmVnczoy oKAgc3RhcnQgYmxrbm86MHgwoKAgbGVuOjGgoCBibWFwIHNpemU6MaCgIGZsYWdzOjB4MDxicj6g oKCgoKCgIFNVUEVSIEJsb2NrIEJ1ZmZlcjo8YnI+PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4KVFJB TlM6IHRpZDoweDg2M2M1MDAwoCB0eXBlOlNUUkFUX1dSSVRFoCAjaXRlbXM6NaAgdHJhbnM6MHgw oCBxOjB4ODBiNWM2ODxicj5JTk86IGNudDozIHRvdGFsOjMgYToweDgwYWRiODggbGVuOjU2IGE6 MHg4MGFkYjIwIGxlbjo5NiBhOjB4ODBiNWM4OCBsZW46MTYgPGJyPqCgoKCgoKAgSU5PREU6ICNy ZWdzOjOgoCBpbm86MHg4NaAgZmxhZ3M6MHg1oKAgZHNpemU6MTY8YnI+oKCgoKCgoCBDT1JFIGlu b2RlOjxicj4KoKCgoKCgoKCgoKCgoKCgIERBVEEgRk9SSyBFWFRFTlRTIGlub2RlIGRhdGE6PGJy PkJVRjogY250OjIgdG90YWw6MiBhOjB4ODBhZDZmOCBsZW46MjQgYToweDgwYWQ3MzAgbGVuOjEy OCA8YnI+oKCgoKCgoCBCVUY6oCAjcmVnczoyoKAgc3RhcnQgYmxrbm86MHgxoKAgbGVuOjGgoCBi bWFwIHNpemU6MaCgIGZsYWdzOjB4MDxicj6goKCgoKCgIEFHRiBCdWZmZXI6IChYQUdGKTxicj5C VUY6IGNudDoyIHRvdGFsOjIgYToweDgwYWQ3YjggbGVuOjI4IGE6MHg4MGFkYTIwIGxlbjoxMjgg PGJyPgqgoKCgoKCgIEJVRjqgICNyZWdzOjKgoCBzdGFydCBibGtubzoweDEwoKAgbGVuOjigoCBi bWFwIHNpemU6MqCgIGZsYWdzOjB4MDxicj6goKCgoKCgIEJVRiBEQVRBPGJyPkJVRjogY250OjIg dG90YWw6MiBhOjB4ODBiNWMyOCBsZW46MjggYToweDgwYjVkMzggbGVuOjEyOCA8YnI+oKCgoKCg oCBCVUY6oCAjcmVnczoyoKAgc3RhcnQgYmxrbm86MHg4oKAgbGVuOjigoCBibWFwIHNpemU6MqCg IGZsYWdzOjB4MDxicj4KoKCgoKCgoCBCVUYgREFUQTxicj5CVUY6IGNudDoyIHRvdGFsOjIgYTow eDgwYjVkMTggbGVuOjI0IGE6MHg4MGI1ZGMwIGxlbjoxMjggPGJyPqCgoKCgoKAgQlVGOqAgI3Jl Z3M6MqCgIHN0YXJ0IGJsa25vOjB4MKCgIGxlbjoxoKAgYm1hcCBzaXplOjGgoCBmbGFnczoweDA8 YnI+oKCgoKCgoCBTVVBFUiBCbG9jayBCdWZmZXI6PGJyPj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+ ClRSQU5TOiB0aWQ6MHg4NjNjNTAwMKAgdHlwZTpTVFJBVF9XUklURaAgI2l0ZW1zOjWgIHRyYW5z OjB4MKAgcToweDgwYjVjZjg8YnI+SU5POiBjbnQ6MyB0b3RhbDozIGE6MHg4MGFkYjg4IGxlbjo1 NiBhOjB4ODBhZGIyMCBsZW46OTYgYToweDgwYWRiZTggbGVuOjE2IDxicj6goKCgoKCgIElOT0RF OiAjcmVnczozoKAgaW5vOjB4ODWgIGZsYWdzOjB4NaCgIGRzaXplOjE2PGJyPqCgoKCgoKAgQ09S RSBpbm9kZTo8YnI+CqCgoKCgoKCgoKCgoKCgoCBEQVRBIEZPUksgRVhURU5UUyBpbm9kZSBkYXRh Ojxicj5CVUY6IGNudDoyIHRvdGFsOjIgYToweDgwYWRiYzggbGVuOjI0IGE6MHg4MGFkNzMwIGxl bjoxMjggPGJyPqCgoKCgoKAgQlVGOqAgI3JlZ3M6MqCgIHN0YXJ0IGJsa25vOjB4MaCgIGxlbjox oKAgYm1hcCBzaXplOjGgoCBmbGFnczoweDA8YnI+oKCgoKCgoCBBR0YgQnVmZmVyOiAoWEFHRik8 YnI+QlVGOiBjbnQ6MiB0b3RhbDoyIGE6MHg4MGFkYWU4IGxlbjoyOCBhOjB4ODBhZGEyMCBsZW46 MTI4IDxicj4KoKCgoKCgoCBCVUY6oCAjcmVnczoyoKAgc3RhcnQgYmxrbm86MHgxMKCgIGxlbjo4 oKAgYm1hcCBzaXplOjKgoCBmbGFnczoweDA8YnI+oKCgoKCgoCBCVUYgREFUQTxicj5CVUY6IGNu dDoyIHRvdGFsOjIgYToweDgwYjVjMDggbGVuOjI4IGE6MHg4MGI1ZDM4IGxlbjoxMjggPGJyPqCg oKCgoKAgQlVGOqAgI3JlZ3M6MqCgIHN0YXJ0IGJsa25vOjB4OKCgIGxlbjo4oKAgYm1hcCBzaXpl OjKgoCBmbGFnczoweDA8YnI+CqCgoKCgoKAgQlVGIERBVEE8YnI+QlVGOiBjbnQ6MiB0b3RhbDoy IGE6MHg4MGI1YzY4IGxlbjoyNCBhOjB4ODBiNWRjMCBsZW46MTI4IDxicj6goKCgoKCgIEJVRjqg ICNyZWdzOjKgoCBzdGFydCBibGtubzoweDCgoCBsZW46MaCgIGJtYXAgc2l6ZToxoKAgZmxhZ3M6 MHgwPGJyPqCgoKCgoKAgU1VQRVIgQmxvY2sgQnVmZmVyOjxicj49PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PGJyPgpUUkFOUzogdGlkOjB4ODYzYzUwMDCgIHR5cGU6U1RSQVRfV1JJVEWgICNpdGVtczo1oCB0 cmFuczoweDCgIHE6MHg4MGI1YzQ4PGJyPklOTzogY250OjMgdG90YWw6MyBhOjB4ODBhZGI4OCBs ZW46NTYgYToweDgwYWRiMjAgbGVuOjk2IGE6MHg4MGI1Yzg4IGxlbjoxNiA8YnI+oKCgoKCgoCBJ Tk9ERTogI3JlZ3M6M6CgIGlubzoweDg1oCBmbGFnczoweDWgoCBkc2l6ZToxNjxicj6goKCgoKCg IENPUkUgaW5vZGU6PGJyPgqgoKCgoKCgoKCgoKCgoKAgREFUQSBGT1JLIEVYVEVOVFMgaW5vZGUg ZGF0YTo8YnI+QlVGOiBjbnQ6MiB0b3RhbDoyIGE6MHg4MGFkNmY4IGxlbjoyNCBhOjB4ODBhZDcz MCBsZW46MTI4IDxicj6goKCgoKCgIEJVRjqgICNyZWdzOjKgoCBzdGFydCBibGtubzoweDGgoCBs ZW46MaCgIGJtYXAgc2l6ZToxoKAgZmxhZ3M6MHgwPGJyPqCgoKCgoKAgQUdGIEJ1ZmZlcjogKFhB R0YpPGJyPkJVRjogY250OjIgdG90YWw6MiBhOjB4ODBhZDdiOCBsZW46MjggYToweDgwYWRhMjAg bGVuOjEyOCA8YnI+CqCgoKCgoKAgQlVGOqAgI3JlZ3M6MqCgIHN0YXJ0IGJsa25vOjB4MTCgoCBs ZW46OKCgIGJtYXAgc2l6ZToyoKAgZmxhZ3M6MHgwPGJyPqCgoKCgoKAgQlVGIERBVEE8YnI+QlVG OiBjbnQ6MiB0b3RhbDoyIGE6MHg4MGI1YzI4IGxlbjoyOCBhOjB4ODBiNWQzOCBsZW46MTI4IDxi cj6goKCgoKCgIEJVRjqgICNyZWdzOjKgoCBzdGFydCBibGtubzoweDigoCBsZW46OKCgIGJtYXAg c2l6ZToyoKAgZmxhZ3M6MHgwPGJyPgqgoKCgoKCgIEJVRiBEQVRBPGJyPkJVRjogY250OjIgdG90 YWw6MiBhOjB4ODBiNWNmOCBsZW46MjQgYToweDgwYjVkYzAgbGVuOjEyOCA8YnI+oKCgoKCgoCBC VUY6oCAjcmVnczoyoKAgc3RhcnQgYmxrbm86MHgwoKAgbGVuOjGgoCBibWFwIHNpemU6MaCgIGZs YWdzOjB4MDxicj6goKCgoKCgIFNVUEVSIEJsb2NrIEJ1ZmZlcjo8YnI+PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PTxicj4KVFJBTlM6IHRpZDoweDg2M2M1MDAwoCB0eXBlOlNUUkFUX1dSSVRFoCAjaXRlbXM6 NaAgdHJhbnM6MHgwoCBxOjB4ODBiNWQxODxicj5JTk86IGNudDozIHRvdGFsOjMgYToweDgwYWRi ODggbGVuOjU2IGE6MHg4MGFkYjIwIGxlbjo5NiBhOjB4ODBhZGJlOCBsZW46MTYgPGJyPqCgoKCg oKAgSU5PREU6ICNyZWdzOjOgoCBpbm86MHg4NaAgZmxhZ3M6MHg1oKAgZHNpemU6MTY8YnI+oKCg oKCgoCBDT1JFIGlub2RlOjxicj4KoKCgoKCgoKCgoKCgoKCgIERBVEEgRk9SSyBFWFRFTlRTIGlu b2RlIGRhdGE6PGJyPkJVRjogY250OjIgdG90YWw6MiBhOjB4ODBhZGJjOCBsZW46MjQgYToweDgw YWQ3MzAgbGVuOjEyOCA8YnI+oKCgoKCgoCBCVUY6oCAjcmVnczoyoKAgc3RhcnQgYmxrbm86MHgx oKAgbGVuOjGgoCBibWFwIHNpemU6MaCgIGZsYWdzOjB4MDxicj6goKCgoKCgIEFHRiBCdWZmZXI6 IChYQUdGKTxicj5CVUY6IGNudDoyIHRvdGFsOjIgYToweDgwYWRhZTggbGVuOjI4IGE6MHg4MGFk YTIwIGxlbjoxMjggPGJyPgqgoKCgoKCgIEJVRjqgICNyZWdzOjKgoCBzdGFydCBibGtubzoweDEw oKAgbGVuOjigoCBibWFwIHNpemU6MqCgIGZsYWdzOjB4MDxicj6goKCgoKCgIEJVRiBEQVRBPGJy PkJVRjogY250OjIgdG90YWw6MiBhOjB4ODBiNWMwOCBsZW46MjggYToweDgwYjVkMzggbGVuOjEy OCA8YnI+oKCgoKCgoCBCVUY6oCAjcmVnczoyoKAgc3RhcnQgYmxrbm86MHg4oKAgbGVuOjigoCBi bWFwIHNpemU6MqCgIGZsYWdzOjB4MDxicj4KoKCgoKCgoCBCVUYgREFUQTxicj5CVUY6IGNudDoy IHRvdGFsOjIgYToweDgwYjVjNDggbGVuOjI0IGE6MHg4MGI1ZGMwIGxlbjoxMjggPGJyPqCgoKCg oKAgQlVGOqAgI3JlZ3M6MqCgIHN0YXJ0IGJsa25vOjB4MKCgIGxlbjoxoKAgYm1hcCBzaXplOjGg oCBmbGFnczoweDA8YnI+oKCgoKCgoCBTVVBFUiBCbG9jayBCdWZmZXI6PGJyPj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT08YnI+ClRSQU5TOiB0aWQ6MHg4NjNjNTAwMKAgdHlwZTpTVFJBVF9XUklURaAgI2l0 ZW1zOjWgIHRyYW5zOjB4MKAgcToweDgwYjVjNjg8YnI+SU5POiBjbnQ6MyB0b3RhbDozIGE6MHg4 MGFkYjg4IGxlbjo1NiBhOjB4ODBhZGIyMCBsZW46OTYgYToweDgwYjVjODggbGVuOjE2IDxicj6g oKCgoKCgIElOT0RFOiAjcmVnczozoKAgaW5vOjB4ODWgIGZsYWdzOjB4NaCgIGRzaXplOjE2PGJy PqCgoKCgoKAgQ09SRSBpbm9kZTo8YnI+CqCgoKCgoKCgoKCgoKCgoCBEQVRBIEZPUksgRVhURU5U UyBpbm9kZSBkYXRhOjxicj5CVUY6IGNudDoyIHRvdGFsOjIgYToweDgwYWQ2ZjggbGVuOjI0IGE6 MHg4MGFkNzMwIGxlbjoxMjggPGJyPqCgoKCgoKAgQlVGOqAgI3JlZ3M6MqCgIHN0YXJ0IGJsa25v OjB4MaCgIGxlbjoxoKAgYm1hcCBzaXplOjGgoCBmbGFnczoweDA8YnI+oKCgoKCgoCBBR0YgQnVm ZmVyOiAoWEFHRik8YnI+QlVGOiBjbnQ6MiB0b3RhbDoyIGE6MHg4MGFkN2I4IGxlbjoyOCBhOjB4 ODBhZGEyMCBsZW46MTI4IDxicj4KoKCgoKCgoCBCVUY6oCAjcmVnczoyoKAgc3RhcnQgYmxrbm86 MHgxMKCgIGxlbjo4oKAgYm1hcCBzaXplOjKgoCBmbGFnczoweDA8YnI+oKCgoKCgoCBCVUYgREFU QTxicj5CVUY6IGNudDoyIHRvdGFsOjIgYToweDgwYjVjMjggbGVuOjI4IGE6MHg4MGI1ZDM4IGxl bjoxMjggPGJyPqCgoKCgoKAgQlVGOqAgI3JlZ3M6MqCgIHN0YXJ0IGJsa25vOjB4OKCgIGxlbjo4 oKAgYm1hcCBzaXplOjKgoCBmbGFnczoweDA8YnI+CqCgoKCgoKAgQlVGIERBVEE8YnI+QlVGOiBj bnQ6MiB0b3RhbDoyIGE6MHg4MGI1ZDE4IGxlbjoyNCBhOjB4ODBiNWRjMCBsZW46MTI4IDxicj6g oKCgoKCgIEJVRjqgICNyZWdzOjKgoCBzdGFydCBibGtubzoweDCgoCBsZW46MaCgIGJtYXAgc2l6 ZToxoKAgZmxhZ3M6MHgwPGJyPqCgoKCgoKAgU1VQRVIgQmxvY2sgQnVmZmVyOjxicj49PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PGJyPgpUUkFOUzogdGlkOjB4ODYzYzUwMDCgIHR5cGU6U1RSQVRfV1JJVEWg ICNpdGVtczo1oCB0cmFuczoweDCgIHE6MHg4MGI1Y2Y4PGJyPklOTzogY250OjMgdG90YWw6MyBh OjB4ODBhZGI4OCBsZW46NTYgYToweDgwYWRiMjAgbGVuOjk2IGE6MHg4MGFkYmU4IGxlbjoxNiA8 YnI+oKCgoKCgoCBJTk9ERTogI3JlZ3M6M6CgIGlubzoweDg1oCBmbGFnczoweDWgoCBkc2l6ZTox Njxicj6goKCgoKCgIENPUkUgaW5vZGU6PGJyPgqgoKCgoKCgoKCgoKCgoKAgREFUQSBGT1JLIEVY VEVOVFMgaW5vZGUgZGF0YTo8YnI+QlVGOiBjbnQ6MiB0b3RhbDoyIGE6MHg4MGFkYmM4IGxlbjoy NCBhOjB4ODBhZDczMCBsZW46MTI4IDxicj6goKCgoKCgIEJVRjqgICNyZWdzOjKgoCBzdGFydCBi bGtubzoweDGgoCBsZW46MaCgIGJtYXAgc2l6ZToxoKAgZmxhZ3M6MHgwPGJyPqCgoKCgoKAgQUdG IEJ1ZmZlcjogKFhBR0YpPGJyPkJVRjogY250OjIgdG90YWw6MiBhOjB4ODBhZGFlOCBsZW46Mjgg YToweDgwYWRhMjAgbGVuOjEyOCA8YnI+CqCgoKCgoKAgQlVGOqAgI3JlZ3M6MqCgIHN0YXJ0IGJs a25vOjB4MTCgoCBsZW46OKCgIGJtYXAgc2l6ZToyoKAgZmxhZ3M6MHgwPGJyPqCgoKCgoKAgQlVG IERBVEE8YnI+QlVGOiBjbnQ6MiB0b3RhbDoyIGE6MHg4MGI1YzA4IGxlbjoyOCBhOjB4ODBiNWQz OCBsZW46MTI4IDxicj6goKCgoKCgIEJVRjqgICNyZWdzOjKgoCBzdGFydCBibGtubzoweDigoCBs ZW46OKCgIGJtYXAgc2l6ZToyoKAgZmxhZ3M6MHgwPGJyPgqgoKCgoKCgIEJVRiBEQVRBPGJyPkJV RjogY250OjIgdG90YWw6MiBhOjB4ODBiNWM2OCBsZW46MjQgYToweDgwYjVkYzAgbGVuOjEyOCA8 YnI+oKCgoKCgoCBCVUY6oCAjcmVnczoyoKAgc3RhcnQgYmxrbm86MHgwoKAgbGVuOjGgoCBibWFw IHNpemU6MaCgIGZsYWdzOjB4MDxicj6goKCgoKCgIFNVUEVSIEJsb2NrIEJ1ZmZlcjo8YnI+PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PTxicj4KVFJBTlM6IHRpZDoweDg2M2M1MDAwoCB0eXBlOlNUUkFUX1dS SVRFoCAjaXRlbXM6NaAgdHJhbnM6MHgwoCBxOjB4ODBiNWM0ODxicj5JTk86IGNudDozIHRvdGFs OjMgYToweDgwYWRiODggbGVuOjU2IGE6MHg4MGFkYjIwIGxlbjo5NiBhOjB4ODBiNWM4OCBsZW46 MTYgPGJyPqCgoKCgoKAgSU5PREU6ICNyZWdzOjOgoCBpbm86MHg4NaAgZmxhZ3M6MHg1oKAgZHNp emU6MTY8YnI+oKCgoKCgoCBDT1JFIGlub2RlOjxicj4KoKCgoKCgoKCgoKCgoKCgIERBVEEgRk9S SyBFWFRFTlRTIGlub2RlIGRhdGE6PGJyPkJVRjogY250OjIgdG90YWw6MiBhOjB4ODBhZDZmOCBs ZW46MjQgYToweDgwYWQ3MzAgbGVuOjEyOCA8YnI+oKCgoKCgoCBCVUY6oCAjcmVnczoyoKAgc3Rh cnQgYmxrbm86MHgxoKAgbGVuOjGgoCBibWFwIHNpemU6MaCgIGZsYWdzOjB4MDxicj6goKCgoKCg IEFHRiBCdWZmZXI6IChYQUdGKTxicj5CVUY6IGNudDoyIHRvdGFsOjIgYToweDgwYWQ3YjggbGVu OjI4IGE6MHg4MGFkYTIwIGxlbjoxMjggPGJyPgqgoKCgoKCgIEJVRjqgICNyZWdzOjKgoCBzdGFy dCBibGtubzoweDEwoKAgbGVuOjigoCBibWFwIHNpemU6MqCgIGZsYWdzOjB4MDxicj6goKCgoKCg IEJVRiBEQVRBPGJyPkJVRjogY250OjIgdG90YWw6MiBhOjB4ODBiNWMyOCBsZW46MjggYToweDgw YjVkMzggbGVuOjEyOCA8YnI+oKCgoKCgoCBCVUY6oCAjcmVnczoyoKAgc3RhcnQgYmxrbm86MHg4 oKAgbGVuOjigoCBibWFwIHNpemU6MqCgIGZsYWdzOjB4MDxicj4KoKCgoKCgoCBCVUYgREFUQTxi cj5CVUY6IGNudDoyIHRvdGFsOjIgYToweDgwYjVjZjggbGVuOjI0IGE6MHg4MGI1ZGMwIGxlbjox MjggPGJyPqCgoKCgoKAgQlVGOqAgI3JlZ3M6MqCgIHN0YXJ0IGJsa25vOjB4MKCgIGxlbjoxoKAg Ym1hcCBzaXplOjGgoCBmbGFnczoweDA8YnI+oKCgoKCgoCBTVVBFUiBCbG9jayBCdWZmZXI6PGJy Pj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT08YnI+ClRSQU5TOiB0aWQ6MHg4NjNjNTAwMKAgdHlwZTpTVFJB VF9XUklURaAgI2l0ZW1zOjWgIHRyYW5zOjB4MKAgcToweDgwYjVkMTg8YnI+SU5POiBjbnQ6MyB0 b3RhbDozIGE6MHg4MGFkYjg4IGxlbjo1NiBhOjB4ODBhZGIyMCBsZW46OTYgYToweDgwYWRiZTgg bGVuOjE2IDxicj6goKCgoKCgIElOT0RFOiAjcmVnczozoKAgaW5vOjB4ODWgIGZsYWdzOjB4NaCg IGRzaXplOjE2PGJyPqCgoKCgoKAgQ09SRSBpbm9kZTo8YnI+CqCgoKCgoKCgoKCgoKCgoCBEQVRB IEZPUksgRVhURU5UUyBpbm9kZSBkYXRhOjxicj5CVUY6IGNudDoyIHRvdGFsOjIgYToweDgwYWRi YzggbGVuOjI0IGE6MHg4MGFkNzMwIGxlbjoxMjggPGJyPqCgoKCgoKAgQlVGOqAgI3JlZ3M6MqCg IHN0YXJ0IGJsa25vOjB4MaCgIGxlbjoxoKAgYm1hcCBzaXplOjGgoCBmbGFnczoweDA8YnI+oKCg oKCgoCBBR0YgQnVmZmVyOiAoWEFHRik8YnI+QlVGOiBjbnQ6MiB0b3RhbDoyIGE6MHg4MGFkYWU4 IGxlbjoyOCBhOjB4ODBhZGEyMCBsZW46MTI4IDxicj4KoKCgoKCgoCBCVUY6oCAjcmVnczoyoKAg c3RhcnQgYmxrbm86MHgxMKCgIGxlbjo4oKAgYm1hcCBzaXplOjKgoCBmbGFnczoweDA8YnI+oKCg oKCgoCBCVUYgREFUQTxicj5CVUY6IGNudDoyIHRvdGFsOjIgYToweDgwYjVjMDggbGVuOjI4IGE6 MHg4MGI1ZDM4IGxlbjoxMjggPGJyPqCgoKCgoKAgQlVGOqAgI3JlZ3M6MqCgIHN0YXJ0IGJsa25v OjB4OKCgIGxlbjo4oKAgYm1hcCBzaXplOjKgoCBmbGFnczoweDA8YnI+CqCgoKCgoKAgQlVGIERB VEE8YnI+QlVGOiBjbnQ6MiB0b3RhbDoyIGE6MHg4MGI1YzQ4IGxlbjoyNCBhOjB4ODBiNWRjMCBs ZW46MTI4IDxicj6goKCgoKCgIEJVRjqgICNyZWdzOjKgoCBzdGFydCBibGtubzoweDCgoCBsZW46 MaCgIGJtYXAgc2l6ZToxoKAgZmxhZ3M6MHgwPGJyPqCgoKCgoKAgU1VQRVIgQmxvY2sgQnVmZmVy Ojxicj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PGJyPgpUUkFOUzogdGlkOjB4ODYzYzUwMDCgIHR5cGU6 U1RSQVRfV1JJVEWgICNpdGVtczo1oCB0cmFuczoweDCgIHE6MHg4MGI1YzY4PGJyPklOTzogY250 OjMgdG90YWw6MyBhOjB4ODBhZGI4OCBsZW46NTYgYToweDgwYWRiMjAgbGVuOjk2IGE6MHg4MGI1 Yzg4IGxlbjoxNiA8YnI+oKCgoKCgoCBJTk9ERTogI3JlZ3M6M6CgIGlubzoweDg1oCBmbGFnczow eDWgoCBkc2l6ZToxNjxicj6goKCgoKCgIENPUkUgaW5vZGU6PGJyPgqgoKCgoKCgoKCgoKCgoKAg REFUQSBGT1JLIEVYVEVOVFMgaW5vZGUgZGF0YTo8YnI+QlVGOiBjbnQ6MiB0b3RhbDoyIGE6MHg4 MGFkNmY4IGxlbjoyNCBhOjB4ODBhZDczMCBsZW46MTI4IDxicj6goKCgoKCgIEJVRjqgICNyZWdz OjKgoCBzdGFydCBibGtubzoweDGgoCBsZW46MaCgIGJtYXAgc2l6ZToxoKAgZmxhZ3M6MHgwPGJy PqCgoKCgoKAgQUdGIEJ1ZmZlcjogKFhBR0YpPGJyPkJVRjogY250OjIgdG90YWw6MiBhOjB4ODBh ZDdiOCBsZW46MjggYToweDgwYWRhMjAgbGVuOjEyOCA8YnI+CqCgoKCgoKAgQlVGOqAgI3JlZ3M6 MqCgIHN0YXJ0IGJsa25vOjB4MTCgoCBsZW46OKCgIGJtYXAgc2l6ZToyoKAgZmxhZ3M6MHgwPGJy PqCgoKCgoKAgQlVGIERBVEE8YnI+QlVGOiBjbnQ6MiB0b3RhbDoyIGE6MHg4MGI1YzI4IGxlbjoy OCBhOjB4ODBiNWQzOCBsZW46MTI4IDxicj6goKCgoKCgIEJVRjqgICNyZWdzOjKgoCBzdGFydCBi bGtubzoweDigoCBsZW46OKCgIGJtYXAgc2l6ZToyoKAgZmxhZ3M6MHgwPGJyPgqgoKCgoKCgIEJV RiBEQVRBPGJyPkJVRjogY250OjIgdG90YWw6MiBhOjB4ODBiNWQxOCBsZW46MjQgYToweDgwYjVk YzAgbGVuOjEyOCA8YnI+oKCgoKCgoCBCVUY6oCAjcmVnczoyoKAgc3RhcnQgYmxrbm86MHgwoKAg bGVuOjGgoCBibWFwIHNpemU6MaCgIGZsYWdzOjB4MDxicj6goKCgoKCgIFNVUEVSIEJsb2NrIEJ1 ZmZlcjo8YnI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4KVFJBTlM6IHRpZDoweDg2M2M1MDAwoCB0 eXBlOlNUUkFUX1dSSVRFoCAjaXRlbXM6NaAgdHJhbnM6MHgwoCBxOjB4ODBiNWNmODxicj5JTk86 IGNudDozIHRvdGFsOjMgYToweDgwYWRiODggbGVuOjU2IGE6MHg4MGFkYjIwIGxlbjo5NiBhOjB4 ODBhZGJlOCBsZW46MTYgPGJyPqCgoKCgoKAgSU5PREU6ICNyZWdzOjOgoCBpbm86MHg4NaAgZmxh Z3M6MHg1oKAgZHNpemU6MTY8YnI+oKCgoKCgoCBDT1JFIGlub2RlOjxicj4KoKCgoKCgoKCgoKCg oKCgIERBVEEgRk9SSyBFWFRFTlRTIGlub2RlIGRhdGE6PGJyPkJVRjogY250OjIgdG90YWw6MiBh OjB4ODBhZGJjOCBsZW46MjQgYToweDgwYWQ3MzAgbGVuOjEyOCA8YnI+oKCgoKCgoCBCVUY6oCAj cmVnczoyoKAgc3RhcnQgYmxrbm86MHgxoKAgbGVuOjGgoCBibWFwIHNpemU6MaCgIGZsYWdzOjB4 MDxicj6goKCgoKCgIEFHRiBCdWZmZXI6IChYQUdGKTxicj5CVUY6IGNudDoyIHRvdGFsOjIgYTow eDgwYWRhZTggbGVuOjI4IGE6MHg4MGFkYTIwIGxlbjoxMjggPGJyPgqgoKCgoKCgIEJVRjqgICNy ZWdzOjKgoCBzdGFydCBibGtubzoweDEwoKAgbGVuOjigoCBibWFwIHNpemU6MqCgIGZsYWdzOjB4 MDxicj6goKCgoKCgIEJVRiBEQVRBPGJyPkJVRjogY250OjIgdG90YWw6MiBhOjB4ODBiNWMwOCBs ZW46MjggYToweDgwYjVkMzggbGVuOjEyOCA8YnI+oKCgoKCgoCBCVUY6oCAjcmVnczoyoKAgc3Rh cnQgYmxrbm86MHg4oKAgbGVuOjigoCBibWFwIHNpemU6MqCgIGZsYWdzOjB4MDxicj4KoKCgoKCg oCBCVUYgREFUQTxicj5CVUY6IGNudDoyIHRvdGFsOjIgYToweDgwYjVjNjggbGVuOjI0IGE6MHg4 MGI1ZGMwIGxlbjoxMjggPGJyPqCgoKCgoKAgQlVGOqAgI3JlZ3M6MqCgIHN0YXJ0IGJsa25vOjB4 MKCgIGxlbjoxoKAgYm1hcCBzaXplOjGgoCBmbGFnczoweDA8YnI+oKCgoKCgoCBTVVBFUiBCbG9j ayBCdWZmZXI6PGJyPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+ClRSQU5TOiB0aWQ6MHg4NjNjNTAw MKAgdHlwZTpTVFJBVF9XUklURaAgI2l0ZW1zOjWgIHRyYW5zOjB4MKAgcToweDgwYjVjNDg8YnI+ SU5POiBjbnQ6MyB0b3RhbDozIGE6MHg4MGFkYjg4IGxlbjo1NiBhOjB4ODBhZGIyMCBsZW46OTYg YToweDgwYjVjODggbGVuOjE2IDxicj6goKCgoKCgIElOT0RFOiAjcmVnczozoKAgaW5vOjB4ODWg IGZsYWdzOjB4NaCgIGRzaXplOjE2PGJyPqCgoKCgoKAgQ09SRSBpbm9kZTo8YnI+CqCgoKCgoKCg oKCgoKCgoCBEQVRBIEZPUksgRVhURU5UUyBpbm9kZSBkYXRhOjxicj5CVUY6IGNudDoyIHRvdGFs OjIgYToweDgwYWQ2ZjggbGVuOjI0IGE6MHg4MGFkNzMwIGxlbjoxMjggPGJyPqCgoKCgoKAgQlVG OqAgI3JlZ3M6MqCgIHN0YXJ0IGJsa25vOjB4MaCgIGxlbjoxoKAgYm1hcCBzaXplOjGgoCBmbGFn czoweDA8YnI+oKCgoKCgoCBBR0YgQnVmZmVyOiAoWEFHRik8YnI+QlVGOiBjbnQ6MiB0b3RhbDoy IGE6MHg4MGFkN2I4IGxlbjoyOCBhOjB4ODBhZGEyMCBsZW46MTI4IDxicj4KoKCgoKCgoCBCVUY6 oCAjcmVnczoyoKAgc3RhcnQgYmxrbm86MHgxMKCgIGxlbjo4oKAgYm1hcCBzaXplOjKgoCBmbGFn czoweDA8YnI+oKCgoKCgoCBCVUYgREFUQTxicj5CVUY6IGNudDoyIHRvdGFsOjIgYToweDgwYjVj MjggbGVuOjI4IGE6MHg4MGI1ZDM4IGxlbjoxMjggPGJyPqCgoKCgoKAgQlVGOqAgI3JlZ3M6MqCg IHN0YXJ0IGJsa25vOjB4OKCgIGxlbjo4oKAgYm1hcCBzaXplOjKgoCBmbGFnczoweDA8YnI+CqCg oKCgoKAgQlVGIERBVEE8YnI+QlVGOiBjbnQ6MiB0b3RhbDoyIGE6MHg4MGI1Y2Y4IGxlbjoyNCBh OjB4ODBiNWRjMCBsZW46MTI4IDxicj6goKCgoKCgIEJVRjqgICNyZWdzOjKgoCBzdGFydCBibGtu bzoweDCgoCBsZW46MaCgIGJtYXAgc2l6ZToxoKAgZmxhZ3M6MHgwPGJyPqCgoKCgoKAgU1VQRVIg QmxvY2sgQnVmZmVyOjxicj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPgpUUkFOUzogdGlkOjB4ODYz YzUwMDCgIHR5cGU6U1RSQVRfV1JJVEWgICNpdGVtczo1oCB0cmFuczoweDCgIHE6MHg4MGI1ZDE4 PGJyPklOTzogY250OjMgdG90YWw6MyBhOjB4ODBhZGI4OCBsZW46NTYgYToweDgwYWRiMjAgbGVu Ojk2IGE6MHg4MGFkYmU4IGxlbjoxNiA8YnI+oKCgoKCgoCBJTk9ERTogI3JlZ3M6M6CgIGlubzow eDg1oCBmbGFnczoweDWgoCBkc2l6ZToxNjxicj6goKCgoKCgIENPUkUgaW5vZGU6PGJyPgqgoKCg oKCgoKCgoKCgoKAgREFUQSBGT1JLIEVYVEVOVFMgaW5vZGUgZGF0YTo8YnI+QlVGOiBjbnQ6MiB0 b3RhbDoyIGE6MHg4MGFkYmM4IGxlbjoyNCBhOjB4ODBhZDczMCBsZW46MTI4IDxicj6goKCgoKCg IEJVRjqgICNyZWdzOjKgoCBzdGFydCBibGtubzoweDGgoCBsZW46MaCgIGJtYXAgc2l6ZToxoKAg ZmxhZ3M6MHgwPGJyPqCgoKCgoKAgQUdGIEJ1ZmZlcjogKFhBR0YpPGJyPkJVRjogY250OjIgdG90 YWw6MiBhOjB4ODBhZGFlOCBsZW46MjggYToweDgwYWRhMjAgbGVuOjEyOCA8YnI+CqCgoKCgoKAg QlVGOqAgI3JlZ3M6MqCgIHN0YXJ0IGJsa25vOjB4MTCgoCBsZW46OKCgIGJtYXAgc2l6ZToyoKAg ZmxhZ3M6MHgwPGJyPqCgoKCgoKAgQlVGIERBVEE8YnI+QlVGOiBjbnQ6MiB0b3RhbDoyIGE6MHg4 MGI1YzA4IGxlbjoyOCBhOjB4ODBiNWQzOCBsZW46MTI4IDxicj6goKCgoKCgIEJVRjqgICNyZWdz OjKgoCBzdGFydCBibGtubzoweDigoCBsZW46OKCgIGJtYXAgc2l6ZToyoKAgZmxhZ3M6MHgwPGJy PgqgoKCgoKCgIEJVRiBEQVRBPGJyPkJVRjogY250OjIgdG90YWw6MiBhOjB4ODBiNWM0OCBsZW46 MjQgYToweDgwYjVkYzAgbGVuOjEyOCA8YnI+oKCgoKCgoCBCVUY6oCAjcmVnczoyoKAgc3RhcnQg Ymxrbm86MHgwoKAgbGVuOjGgoCBibWFwIHNpemU6MaCgIGZsYWdzOjB4MDxicj6goKCgoKCgIFNV UEVSIEJsb2NrIEJ1ZmZlcjo8YnI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4KVFJBTlM6IHRpZDow eDg2M2M1MDAwoCB0eXBlOlNUUkFUX1dSSVRFoCAjaXRlbXM6NaAgdHJhbnM6MHgwoCBxOjB4ODBi NWM2ODxicj5JTk86IGNudDozIHRvdGFsOjMgYToweDgwYWRiODggbGVuOjU2IGE6MHg4MGFkYjIw IGxlbjo5NiBhOjB4ODBiNWM4OCBsZW46MTYgPGJyPqCgoKCgoKAgSU5PREU6ICNyZWdzOjOgoCBp bm86MHg4NaAgZmxhZ3M6MHg1oKAgZHNpemU6MTY8YnI+oKCgoKCgoCBDT1JFIGlub2RlOjxicj4K oKCgoKCgoKCgoKCgoKCgIERBVEEgRk9SSyBFWFRFTlRTIGlub2RlIGRhdGE6PGJyPkJVRjogY250 OjIgdG90YWw6MiBhOjB4ODBhZDZmOCBsZW46MjQgYToweDgwYWQ3MzAgbGVuOjEyOCA8YnI+oKCg oKCgoCBCVUY6oCAjcmVnczoyoKAgc3RhcnQgYmxrbm86MHgxoKAgbGVuOjGgoCBibWFwIHNpemU6 MaCgIGZsYWdzOjB4MDxicj6goKCgoKCgIEFHRiBCdWZmZXI6IChYQUdGKTxicj5CVUY6IGNudDoy IHRvdGFsOjIgYToweDgwYWQ3YjggbGVuOjI4IGE6MHg4MGFkYTIwIGxlbjoxMjggPGJyPgqgoKCg oKCgIEJVRjqgICNyZWdzOjKgoCBzdGFydCBibGtubzoweDEwoKAgbGVuOjigoCBibWFwIHNpemU6 MqCgIGZsYWdzOjB4MDxicj6goKCgoKCgIEJVRiBEQVRBPGJyPkJVRjogY250OjIgdG90YWw6MiBh OjB4ODBiNWMyOCBsZW46MjggYToweDgwYjVkMzggbGVuOjEyOCA8YnI+oKCgoKCgoCBCVUY6oCAj cmVnczoyoKAgc3RhcnQgYmxrbm86MHg4oKAgbGVuOjigoCBibWFwIHNpemU6MqCgIGZsYWdzOjB4 MDxicj4KoKCgoKCgoCBCVUYgREFUQTxicj5CVUY6IGNudDoyIHRvdGFsOjIgYToweDgwYjVkMTgg bGVuOjI0IGE6MHg4MGI1ZGMwIGxlbjoxMjggPGJyPqCgoKCgoKAgQlVGOqAgI3JlZ3M6MqCgIHN0 YXJ0IGJsa25vOjB4MKCgIGxlbjoxoKAgYm1hcCBzaXplOjGgoCBmbGFnczoweDA8YnI+oKCgoKCg oCBTVVBFUiBCbG9jayBCdWZmZXI6PGJyPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+ClRSQU5TOiB0 aWQ6MHg4NjNjNTAwMKAgdHlwZTpTVFJBVF9XUklURaAgI2l0ZW1zOjWgIHRyYW5zOjB4MKAgcTow eDgwYjVjZjg8YnI+SU5POiBjbnQ6MyB0b3RhbDozIGE6MHg4MGFkYjg4IGxlbjo1NiBhOjB4ODBh ZGIyMCBsZW46OTYgYToweDgwYWRiZTggbGVuOjE2IDxicj6goKCgoKCgIElOT0RFOiAjcmVnczoz oKAgaW5vOjB4ODWgIGZsYWdzOjB4NaCgIGRzaXplOjE2PGJyPqCgoKCgoKAgQ09SRSBpbm9kZTo8 YnI+CqCgoKCgoKCgoKCgoKCgoCBEQVRBIEZPUksgRVhURU5UUyBpbm9kZSBkYXRhOjxicj5CVUY6 IGNudDoyIHRvdGFsOjIgYToweDgwYWRiYzggbGVuOjI0IGE6MHg4MGFkNzMwIGxlbjoxMjggPGJy PqCgoKCgoKAgQlVGOqAgI3JlZ3M6MqCgIHN0YXJ0IGJsa25vOjB4MaCgIGxlbjoxoKAgYm1hcCBz aXplOjGgoCBmbGFnczoweDA8YnI+oKCgoKCgoCBBR0YgQnVmZmVyOiAoWEFHRik8YnI+QlVGOiBj bnQ6MiB0b3RhbDoyIGE6MHg4MGFkYWU4IGxlbjoyOCBhOjB4ODBhZGEyMCBsZW46MTI4IDxicj4K oKCgoKCgoCBCVUY6oCAjcmVnczoyoKAgc3RhcnQgYmxrbm86MHgxMKCgIGxlbjo4oKAgYm1hcCBz aXplOjKgoCBmbGFnczoweDA8YnI+oKCgoKCgoCBCVUYgREFUQTxicj5CVUY6IGNudDoyIHRvdGFs OjIgYToweDgwYjVjMDggbGVuOjI4IGE6MHg4MGI1ZDM4IGxlbjoxMjggPGJyPqCgoKCgoKAgQlVG OqAgI3JlZ3M6MqCgIHN0YXJ0IGJsa25vOjB4OKCgIGxlbjo4oKAgYm1hcCBzaXplOjKgoCBmbGFn czoweDA8YnI+CqCgoKCgoKAgQlVGIERBVEE8YnI+QlVGOiBjbnQ6MiB0b3RhbDoyIGE6MHg4MGI1 YzY4IGxlbjoyNCBhOjB4ODBiNWRjMCBsZW46MTI4IDxicj6goKCgoKCgIEJVRjqgICNyZWdzOjKg oCBzdGFydCBibGtubzoweDCgoCBsZW46MaCgIGJtYXAgc2l6ZToxoKAgZmxhZ3M6MHgwPGJyPqCg oKCgoKAgU1VQRVIgQmxvY2sgQnVmZmVyOjxicj49PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPgpUUkFO UzogdGlkOjB4ODYzYzUwMDCgIHR5cGU6U1RSQVRfV1JJVEWgICNpdGVtczo1oCB0cmFuczoweDCg IHE6MHg4MGI1YzQ4PGJyPklOTzogY250OjMgdG90YWw6MyBhOjB4ODBhZGI4OCBsZW46NTYgYTow eDgwYWRiMjAgbGVuOjk2IGE6MHg4MGI1Yzg4IGxlbjoxNiA8YnI+oKCgoKCgoCBJTk9ERTogI3Jl Z3M6M6CgIGlubzoweDg1oCBmbGFnczoweDWgoCBkc2l6ZToxNjxicj6goKCgoKCgIENPUkUgaW5v ZGU6PGJyPgqgoKCgoKCgoKCgoKCgoKAgREFUQSBGT1JLIEVYVEVOVFMgaW5vZGUgZGF0YTo8YnI+ QlVGOiBjbnQ6MiB0b3RhbDoyIGE6MHg4MGFkNmY4IGxlbjoyNCBhOjB4ODBhZDczMCBsZW46MTI4 IDxicj6goKCgoKCgIEJVRjqgICNyZWdzOjKgoCBzdGFydCBibGtubzoweDGgoCBsZW46MaCgIGJt YXAgc2l6ZToxoKAgZmxhZ3M6MHgwPGJyPqCgoKCgoKAgQUdGIEJ1ZmZlcjogKFhBR0YpPGJyPkJV RjogY250OjIgdG90YWw6MiBhOjB4ODBhZDdiOCBsZW46MjggYToweDgwYWRhMjAgbGVuOjEyOCA8 YnI+CqCgoKCgoKAgQlVGOqAgI3JlZ3M6MqCgIHN0YXJ0IGJsa25vOjB4MTCgoCBsZW46OKCgIGJt YXAgc2l6ZToyoKAgZmxhZ3M6MHgwPGJyPqCgoKCgoKAgQlVGIERBVEE8YnI+QlVGOiBjbnQ6MiB0 b3RhbDoyIGE6MHg4MGI1YzI4IGxlbjoyOCBhOjB4ODBiNWQzOCBsZW46MTI4IDxicj6goKCgoKCg IEJVRjqgICNyZWdzOjKgoCBzdGFydCBibGtubzoweDigoCBsZW46OKCgIGJtYXAgc2l6ZToyoKAg ZmxhZ3M6MHgwPGJyPgqgoKCgoKCgIEJVRiBEQVRBPGJyPkJVRjogY250OjIgdG90YWw6MiBhOjB4 ODBiNWNmOCBsZW46MjQgYToweDgwYjVkYzAgbGVuOjEyOCA8YnI+oKCgoKCgoCBCVUY6oCAjcmVn czoyoKAgc3RhcnQgYmxrbm86MHgwoKAgbGVuOjGgoCBibWFwIHNpemU6MaCgIGZsYWdzOjB4MDxi cj6goKCgoKCgIFNVUEVSIEJsb2NrIEJ1ZmZlcjo8YnI+PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4K VFJBTlM6IHRpZDoweDg2M2M1MDAwoCB0eXBlOlNUUkFUX1dSSVRFoCAjaXRlbXM6NaAgdHJhbnM6 MHgwoCBxOjB4ODBiNWQxODxicj5JTk86IGNudDozIHRvdGFsOjMgYToweDgwYWRiODggbGVuOjU2 IGE6MHg4MGFkYjIwIGxlbjo5NiBhOjB4ODBhZGJlOCBsZW46MTYgPGJyPqCgoKCgoKAgSU5PREU6 ICNyZWdzOjOgoCBpbm86MHg4NaAgZmxhZ3M6MHg1oKAgZHNpemU6MTY8YnI+oKCgoKCgoCBDT1JF IGlub2RlOjxicj4KoKCgoKCgoKCgoKCgoKCgIERBVEEgRk9SSyBFWFRFTlRTIGlub2RlIGRhdGE6 PGJyPkJVRjogY250OjIgdG90YWw6MiBhOjB4ODBhZGJjOCBsZW46MjQgYToweDgwYWQ3MzAgbGVu OjEyOCA8YnI+oKCgoKCgoCBCVUY6oCAjcmVnczoyoKAgc3RhcnQgYmxrbm86MHgxoKAgbGVuOjGg oCBibWFwIHNpemU6MaCgIGZsYWdzOjB4MDxicj6goKCgoKCgIEFHRiBCdWZmZXI6IChYQUdGKTxi cj5CVUY6IGNudDoyIHRvdGFsOjIgYToweDgwYWRhZTggbGVuOjI4IGE6MHg4MGFkYTIwIGxlbjox MjggPGJyPgqgoKCgoKCgIEJVRjqgICNyZWdzOjKgoCBzdGFydCBibGtubzoweDEwoKAgbGVuOjig oCBibWFwIHNpemU6MqCgIGZsYWdzOjB4MDxicj6goKCgoKCgIEJVRiBEQVRBPGJyPkJVRjogY250 OjIgdG90YWw6MiBhOjB4ODBiNWMwOCBsZW46MjggYToweDgwYjVkMzggbGVuOjEyOCA8YnI+oKCg oKCgoCBCVUY6oCAjcmVnczoyoKAgc3RhcnQgYmxrbm86MHg4oKAgbGVuOjigoCBibWFwIHNpemU6 MqCgIGZsYWdzOjB4MDxicj4KoKCgoKCgoCBCVUYgREFUQTxicj5CVUY6IGNudDoyIHRvdGFsOjIg YToweDgwYjVjNDggbGVuOjI0IGE6MHg4MGI1ZGMwIGxlbjoxMjggPGJyPqCgoKCgoKAgQlVGOqAg I3JlZ3M6MqCgIHN0YXJ0IGJsa25vOjB4MKCgIGxlbjoxoKAgYm1hcCBzaXplOjGgoCBmbGFnczow eDA8YnI+oKCgoKCgoCBTVVBFUiBCbG9jayBCdWZmZXI6PGJyPj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08 YnI+ClRSQU5TOiB0aWQ6MHg4NjNjNTAwMKAgdHlwZTpTVFJBVF9XUklURaAgI2l0ZW1zOjWgIHRy YW5zOjB4MKAgcToweDgwYjVjNjg8YnI+SU5POiBjbnQ6MyB0b3RhbDozIGE6MHg4MGFkYjg4IGxl bjo1NiBhOjB4ODBhZGIyMCBsZW46OTYgYToweDgwYjVjODggbGVuOjE2IDxicj6goKCgoKCgIElO T0RFOiAjcmVnczozoKAgaW5vOjB4ODWgIGZsYWdzOjB4NaCgIGRzaXplOjE2PGJyPqCgoKCgoKAg Q09SRSBpbm9kZTo8YnI+CqCgoKCgoKCgoKCgoKCgoCBEQVRBIEZPUksgRVhURU5UUyBpbm9kZSBk YXRhOjxicj5CVUY6IGNudDoyIHRvdGFsOjIgYToweDgwYWQ2ZjggbGVuOjI0IGE6MHg4MGFkNzMw IGxlbjoxMjggPGJyPqCgoKCgoKAgQlVGOqAgI3JlZ3M6MqCgIHN0YXJ0IGJsa25vOjB4MaCgIGxl bjoxoKAgYm1hcCBzaXplOjGgoCBmbGFnczoweDA8YnI+oKCgoKCgoCBBR0YgQnVmZmVyOiAoWEFH Rik8YnI+QlVGOiBjbnQ6MiB0b3RhbDoyIGE6MHg4MGFkN2I4IGxlbjoyOCBhOjB4ODBhZGEyMCBs ZW46MTI4IDxicj4KoKCgoKCgoCBCVUY6oCAjcmVnczoyoKAgc3RhcnQgYmxrbm86MHgxMKCgIGxl bjo4oKAgYm1hcCBzaXplOjKgoCBmbGFnczoweDA8YnI+oKCgoKCgoCBCVUYgREFUQTxicj5CVUY6 IGNudDoyIHRvdGFsOjIgYToweDgwYjVjMjggbGVuOjI4IGE6MHg4MGI1ZDM4IGxlbjoxMjggPGJy PqCgoKCgoKAgQlVGOqAgI3JlZ3M6MqCgIHN0YXJ0IGJsa25vOjB4OKCgIGxlbjo4oKAgYm1hcCBz aXplOjKgoCBmbGFnczoweDA8YnI+CqCgoKCgoKAgQlVGIERBVEE8YnI+QlVGOiBjbnQ6MiB0b3Rh bDoyIGE6MHg4MGI1ZDE4IGxlbjoyNCBhOjB4ODBiNWRjMCBsZW46MTI4IDxicj6goKCgoKCgIEJV RjqgICNyZWdzOjKgoCBzdGFydCBibGtubzoweDCgoCBsZW46MaCgIGJtYXAgc2l6ZToxoKAgZmxh Z3M6MHgwPGJyPqCgoKCgoKAgU1VQRVIgQmxvY2sgQnVmZmVyOjxicj49PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PGJyPgpUUkFOUzogdGlkOjB4ODYzYzUwMDCgIHR5cGU6U1RSQVRfV1JJVEWgICNpdGVtczo1 oCB0cmFuczoweDCgIHE6MHg4MGI1Y2Y4PGJyPklOTzogY250OjMgdG90YWw6MyBhOjB4ODBhZGI4 OCBsZW46NTYgYToweDgwYWRiMjAgbGVuOjk2IGE6MHg4MGFkYmU4IGxlbjoxNiA8YnI+oKCgoKCg oCBJTk9ERTogI3JlZ3M6M6CgIGlubzoweDg1oCBmbGFnczoweDWgoCBkc2l6ZToxNjxicj6goKCg oKCgIENPUkUgaW5vZGU6PGJyPgqgoKCgoKCgoKCgoKCgoKAgREFUQSBGT1JLIEVYVEVOVFMgaW5v ZGUgZGF0YTo8YnI+QlVGOiBjbnQ6MiB0b3RhbDoyIGE6MHg4MGFkYmM4IGxlbjoyNCBhOjB4ODBh ZDczMCBsZW46MTI4IDxicj6goKCgoKCgIEJVRjqgICNyZWdzOjKgoCBzdGFydCBibGtubzoweDGg oCBsZW46MaCgIGJtYXAgc2l6ZToxoKAgZmxhZ3M6MHgwPGJyPqCgoKCgoKAgQUdGIEJ1ZmZlcjog KFhBR0YpPGJyPkJVRjogY250OjIgdG90YWw6MiBhOjB4ODBhZGFlOCBsZW46MjggYToweDgwYWRh MjAgbGVuOjEyOCA8YnI+CqCgoKCgoKAgQlVGOqAgI3JlZ3M6MqCgIHN0YXJ0IGJsa25vOjB4MTCg oCBsZW46OKCgIGJtYXAgc2l6ZToyoKAgZmxhZ3M6MHgwPGJyPqCgoKCgoKAgQlVGIERBVEE8YnI+ QlVGOiBjbnQ6MiB0b3RhbDoyIGE6MHg4MGI1YzA4IGxlbjoyOCBhOjB4ODBiNWQzOCBsZW46MTI4 IDxicj6goKCgoKCgIEJVRjqgICNyZWdzOjKgoCBzdGFydCBibGtubzoweDigoCBsZW46OKCgIGJt YXAgc2l6ZToyoKAgZmxhZ3M6MHgwPGJyPgqgoKCgoKCgIEJVRiBEQVRBPGJyPkJVRjogY250OjIg dG90YWw6MiBhOjB4ODBiNWM2OCBsZW46MjQgYToweDgwYjVkYzAgbGVuOjEyOCA8YnI+oKCgoKCg oCBCVUY6oCAjcmVnczoyoKAgc3RhcnQgYmxrbm86MHgwoKAgbGVuOjGgoCBibWFwIHNpemU6MaCg IGZsYWdzOjB4MDxicj6goKCgoKCgIFNVUEVSIEJsb2NrIEJ1ZmZlcjo8YnI+PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PTxicj4KVFJBTlM6IHRpZDoweDg2M2M1MDAwoCB0eXBlOlNUUkFUX1dSSVRFoCAjaXRl bXM6NaAgdHJhbnM6MHgwoCBxOjB4ODBiNWM0ODxicj5JTk86IGNudDozIHRvdGFsOjMgYToweDgw YWRiODggbGVuOjU2IGE6MHg4MGFkYjIwIGxlbjo5NiBhOjB4ODBiNWM4OCBsZW46MTYgPGJyPqCg oKCgoKAgSU5PREU6ICNyZWdzOjOgoCBpbm86MHg4NaAgZmxhZ3M6MHg1oKAgZHNpemU6MTY8YnI+ oKCgoKCgoCBDT1JFIGlub2RlOjxicj4KoKCgoKCgoKCgoKCgoKCgIERBVEEgRk9SSyBFWFRFTlRT IGlub2RlIGRhdGE6PGJyPkJVRjogY250OjIgdG90YWw6MiBhOjB4ODBhZDZmOCBsZW46MjQgYTow eDgwYWQ3MzAgbGVuOjEyOCA8YnI+oKCgoKCgoCBCVUY6oCAjcmVnczoyoKAgc3RhcnQgYmxrbm86 MHgxoKAgbGVuOjGgoCBibWFwIHNpemU6MaCgIGZsYWdzOjB4MDxicj6goKCgoKCgIEFHRiBCdWZm ZXI6IChYQUdGKTxicj5CVUY6IGNudDoyIHRvdGFsOjIgYToweDgwYWQ3YjggbGVuOjI4IGE6MHg4 MGFkYTIwIGxlbjoxMjggPGJyPgqgoKCgoKCgIEJVRjqgICNyZWdzOjKgoCBzdGFydCBibGtubzow eDEwoKAgbGVuOjigoCBibWFwIHNpemU6MqCgIGZsYWdzOjB4MDxicj6goKCgoKCgIEJVRiBEQVRB PGJyPkJVRjogY250OjIgdG90YWw6MiBhOjB4ODBiNWMyOCBsZW46MjggYToweDgwYjVkMzggbGVu OjEyOCA8YnI+oKCgoKCgoCBCVUY6oCAjcmVnczoyoKAgc3RhcnQgYmxrbm86MHg4oKAgbGVuOjig oCBibWFwIHNpemU6MqCgIGZsYWdzOjB4MDxicj4KoKCgoKCgoCBCVUYgREFUQTxicj5CVUY6IGNu dDoyIHRvdGFsOjIgYToweDgwYjVjZjggbGVuOjI0IGE6MHg4MGI1ZGMwIGxlbjoxMjggPGJyPqCg oKCgoKAgQlVGOqAgI3JlZ3M6MqCgIHN0YXJ0IGJsa25vOjB4MKCgIGxlbjoxoKAgYm1hcCBzaXpl OjGgoCBmbGFnczoweDA8YnI+oKCgoKCgoCBTVVBFUiBCbG9jayBCdWZmZXI6PGJyPj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT08YnI+ClRSQU5TOiB0aWQ6MHg4NjNjNTAwMKAgdHlwZTpTVFJBVF9XUklURaAg I2l0ZW1zOjWgIHRyYW5zOjB4MKAgcToweDgwYjVkMTg8YnI+SU5POiBjbnQ6MyB0b3RhbDozIGE6 MHg4MGFkYjg4IGxlbjo1NiBhOjB4ODBhZGIyMCBsZW46OTYgYToweDgwYWRiZTggbGVuOjE2IDxi cj6goKCgoKCgIElOT0RFOiAjcmVnczozoKAgaW5vOjB4ODWgIGZsYWdzOjB4NaCgIGRzaXplOjE2 PGJyPqCgoKCgoKAgQ09SRSBpbm9kZTo8YnI+CqCgoKCgoKCgoKCgoKCgoCBEQVRBIEZPUksgRVhU RU5UUyBpbm9kZSBkYXRhOjxicj5CVUY6IGNudDoyIHRvdGFsOjIgYToweDgwYWRiYzggbGVuOjI0 IGE6MHg4MGFkNzMwIGxlbjoxMjggPGJyPqCgoKCgoKAgQlVGOqAgI3JlZ3M6MqCgIHN0YXJ0IGJs a25vOjB4MaCgIGxlbjoxoKAgYm1hcCBzaXplOjGgoCBmbGFnczoweDA8YnI+oKCgoKCgoCBBR0Yg QnVmZmVyOiAoWEFHRik8YnI+QlVGOiBjbnQ6MiB0b3RhbDoyIGE6MHg4MGFkYWU4IGxlbjoyOCBh OjB4ODBhZGEyMCBsZW46MTI4IDxicj4KoKCgoKCgoCBCVUY6oCAjcmVnczoyoKAgc3RhcnQgYmxr bm86MHgxMKCgIGxlbjo4oKAgYm1hcCBzaXplOjKgoCBmbGFnczoweDA8YnI+oKCgoKCgoCBCVUYg REFUQTxicj5CVUY6IGNudDoyIHRvdGFsOjIgYToweDgwYjVjMDggbGVuOjI4IGE6MHg4MGI1ZDM4 IGxlbjoxMjggPGJyPqCgoKCgoKAgQlVGOqAgI3JlZ3M6MqCgIHN0YXJ0IGJsa25vOjB4OKCgIGxl bjo4oKAgYm1hcCBzaXplOjKgoCBmbGFnczoweDA8YnI+CqCgoKCgoKAgQlVGIERBVEE8YnI+QlVG OiBjbnQ6MiB0b3RhbDoyIGE6MHg4MGI1YzQ4IGxlbjoyNCBhOjB4ODBiNWRjMCBsZW46MTI4IDxi cj6goKCgoKCgIEJVRjqgICNyZWdzOjKgoCBzdGFydCBibGtubzoweDCgoCBsZW46MaCgIGJtYXAg c2l6ZToxoKAgZmxhZ3M6MHgwPGJyPqCgoKCgoKAgU1VQRVIgQmxvY2sgQnVmZmVyOjxicj49PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PGJyPgpUUkFOUzogdGlkOjB4ODYzYzUwMDCgIHR5cGU6U1RSQVRfV1JJ VEWgICNpdGVtczo1oCB0cmFuczoweDCgIHE6MHg4MGI1YzY4PGJyPklOTzogY250OjMgdG90YWw6 MyBhOjB4ODBhZGI4OCBsZW46NTYgYToweDgwYWRiMjAgbGVuOjk2IGE6MHg4MGI1Yzg4IGxlbjox NiA8YnI+oKCgoKCgoCBJTk9ERTogI3JlZ3M6M6CgIGlubzoweDg1oCBmbGFnczoweDWgoCBkc2l6 ZToxNjxicj6goKCgoKCgIENPUkUgaW5vZGU6PGJyPgqgoKCgoKCgoKCgoKCgoKAgREFUQSBGT1JL IEVYVEVOVFMgaW5vZGUgZGF0YTo8YnI+QlVGOiBjbnQ6MiB0b3RhbDoyIGE6MHg4MGFkNmY4IGxl bjoyNCBhOjB4ODBhZDczMCBsZW46MTI4IDxicj6goKCgoKCgIEJVRjqgICNyZWdzOjKgoCBzdGFy dCBibGtubzoweDGgoCBsZW46MaCgIGJtYXAgc2l6ZToxoKAgZmxhZ3M6MHgwPGJyPqCgoKCgoKAg QUdGIEJ1ZmZlcjogKFhBR0YpPGJyPkJVRjogY250OjIgdG90YWw6MiBhOjB4ODBhZDdiOCBsZW46 MjggYToweDgwYWRhMjAgbGVuOjEyOCA8YnI+CqCgoKCgoKAgQlVGOqAgI3JlZ3M6MqCgIHN0YXJ0 IGJsa25vOjB4MTCgoCBsZW46OKCgIGJtYXAgc2l6ZToyoKAgZmxhZ3M6MHgwPGJyPqCgoKCgoKAg QlVGIERBVEE8YnI+QlVGOiBjbnQ6MiB0b3RhbDoyIGE6MHg4MGI1YzI4IGxlbjoyOCBhOjB4ODBi NWQzOCBsZW46MTI4IDxicj6goKCgoKCgIEJVRjqgICNyZWdzOjKgoCBzdGFydCBibGtubzoweDig oCBsZW46OKCgIGJtYXAgc2l6ZToyoKAgZmxhZ3M6MHgwPGJyPgqgoKCgoKCgIEJVRiBEQVRBPGJy PkJVRjogY250OjIgdG90YWw6MiBhOjB4ODBiNWQxOCBsZW46MjQgYToweDgwYjVkYzAgbGVuOjEy OCA8YnI+oKCgoKCgoCBCVUY6oCAjcmVnczoyoKAgc3RhcnQgYmxrbm86MHgwoKAgbGVuOjGgoCBi bWFwIHNpemU6MaCgIGZsYWdzOjB4MDxicj6goKCgoKCgIFNVUEVSIEJsb2NrIEJ1ZmZlcjo8YnI+ PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PTxicj4KVFJBTlM6IHRpZDoweDg2M2M1MDAwoCB0eXBlOlNUUkFU X1dSSVRFoCAjaXRlbXM6NaAgdHJhbnM6MHgwoCBxOjB4ODBiNWNmODxicj5JTk86IGNudDozIHRv dGFsOjMgYToweDgwYWRiODggbGVuOjU2IGE6MHg4MGFkYjIwIGxlbjo5NiBhOjB4ODBhZGJlOCBs ZW46MTYgPGJyPqCgoKCgoKAgSU5PREU6ICNyZWdzOjOgoCBpbm86MHg4NaAgZmxhZ3M6MHg1oKAg ZHNpemU6MTY8YnI+oKCgoKCgoCBDT1JFIGlub2RlOjxicj4KoKCgoKCgoKCgoKCgoKCgIERBVEEg Rk9SSyBFWFRFTlRTIGlub2RlIGRhdGE6PGJyPkJVRjogY250OjIgdG90YWw6MiBhOjB4ODBhZGJj OCBsZW46MjQgYToweDgwYWQ3MzAgbGVuOjEyOCA8YnI+oKCgoKCgoCBCVUY6oCAjcmVnczoyoKAg c3RhcnQgYmxrbm86MHgxoKAgbGVuOjGgoCBibWFwIHNpemU6MaCgIGZsYWdzOjB4MDxicj6goKCg oKCgIEFHRiBCdWZmZXI6IChYQUdGKTxicj5CVUY6IGNudDoyIHRvdGFsOjIgYToweDgwYWRhZTgg bGVuOjI4IGE6MHg4MGFkYTIwIGxlbjoxMjggPGJyPgqgoKCgoKCgIEJVRjqgICNyZWdzOjKgoCBz dGFydCBibGtubzoweDEwoKAgbGVuOjigoCBibWFwIHNpemU6MqCgIGZsYWdzOjB4MDxicj6goKCg oKCgIEJVRiBEQVRBPGJyPkJVRjogY250OjIgdG90YWw6MiBhOjB4ODBiNWMwOCBsZW46MjggYTow eDgwYjVkMzggbGVuOjEyOCA8YnI+oKCgoKCgoCBCVUY6oCAjcmVnczoyoKAgc3RhcnQgYmxrbm86 MHg4oKAgbGVuOjigoCBibWFwIHNpemU6MqCgIGZsYWdzOjB4MDxicj4KoKCgoKCgoCBCVUYgREFU QTxicj5CVUY6IGNudDoyIHRvdGFsOjIgYToweDgwYjVjNjggbGVuOjI0IGE6MHg4MGI1ZGMwIGxl bjoxMjggPGJyPqCgoKCgoKAgQlVGOqAgI3JlZ3M6MqCgIHN0YXJ0IGJsa25vOjB4MKCgIGxlbjox oKAgYm1hcCBzaXplOjGgoCBmbGFnczoweDA8YnI+oKCgoKCgoCBTVVBFUiBCbG9jayBCdWZmZXI6 PGJyPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT08YnI+ClRSQU5TOiB0aWQ6MHg4NjNjNTAwMKAgdHlwZTpT VFJBVF9XUklURaAgI2l0ZW1zOjWgIHRyYW5zOjB4MKAgcToweDgwYjVjNDg8YnI+SU5POiBjbnQ6 MyB0b3RhbDozIGE6MHg4MGFkYjg4IGxlbjo1NiBhOjB4ODBhZGIyMCBsZW46OTYgYToweDgwYjVj ODggbGVuOjE2IDxicj6goKCgoKCgIElOT0RFOiAjcmVnczozoKAgaW5vOjB4ODWgIGZsYWdzOjB4 NaCgIGRzaXplOjE2PGJyPqCgoKCgoKAgQ09SRSBpbm9kZTo8YnI+CqCgoKCgoKCgoKCgoKCgoCBE QVRBIEZPUksgRVhURU5UUyBpbm9kZSBkYXRhOjxicj5CVUY6IGNudDoyIHRvdGFsOjIgYToweDgw YWQ2ZjggbGVuOjI0IGE6MHg4MGFkNzMwIGxlbjoxMjggPGJyPqCgoKCgoKAgQlVGOqAgI3JlZ3M6 MqCgIHN0YXJ0IGJsa25vOjB4MaCgIGxlbjoxoKAgYm1hcCBzaXplOjGgoCBmbGFnczoweDA8YnI+ oKCgoKCgoCBBR0YgQnVmZmVyOiAoWEFHRik8YnI+QlVGOiBjbnQ6MiB0b3RhbDoyIGE6MHg4MGFk N2I4IGxlbjoyOCBhOjB4ODBhZGEyMCBsZW46MTI4IDxicj4KoKCgoKCgoCBCVUY6oCAjcmVnczoy oKAgc3RhcnQgYmxrbm86MHgxMKCgIGxlbjo4oKAgYm1hcCBzaXplOjKgoCBmbGFnczoweDA8YnI+ oKCgoKCgoCBCVUYgREFUQTxicj5CVUY6IGNudDoyIHRvdGFsOjIgYToweDgwYjVjMjggbGVuOjI4 IGE6MHg4MGI1ZDM4IGxlbjoxMjggPGJyPqCgoKCgoKAgQlVGOqAgI3JlZ3M6MqCgIHN0YXJ0IGJs a25vOjB4OKCgIGxlbjo4oKAgYm1hcCBzaXplOjKgoCBmbGFnczoweDA8YnI+CqCgoKCgoKAgQlVG IERBVEE8YnI+QlVGOiBjbnQ6MiB0b3RhbDoyIGE6MHg4MGI1Y2Y4IGxlbjoyNCBhOjB4ODBiNWRj MCBsZW46MTI4IDxicj6goKCgoKCgIEJVRjqgICNyZWdzOjKgoCBzdGFydCBibGtubzoweDCgoCBs ZW46MaCgIGJtYXAgc2l6ZToxoKAgZmxhZ3M6MHgwPGJyPqCgoKCgoKAgU1VQRVIgQmxvY2sgQnVm ZmVyOjxicj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPgpUUkFOUzogdGlkOjB4ODYzYzUwMDCgIHR5 cGU6U1RSQVRfV1JJVEWgICNpdGVtczo1oCB0cmFuczoweDCgIHE6MHg4MGI1ZDE4PGJyPklOTzog Y250OjMgdG90YWw6MyBhOjB4ODBhZGI4OCBsZW46NTYgYToweDgwYWRiMjAgbGVuOjk2IGE6MHg4 MGFkYmU4IGxlbjoxNiA8YnI+oKCgoKCgoCBJTk9ERTogI3JlZ3M6M6CgIGlubzoweDg1oCBmbGFn czoweDWgoCBkc2l6ZToxNjxicj6goKCgoKCgIENPUkUgaW5vZGU6PGJyPgqgoKCgoKCgoKCgoKCg oKAgREFUQSBGT1JLIEVYVEVOVFMgaW5vZGUgZGF0YTo8YnI+QlVGOiBjbnQ6MiB0b3RhbDoyIGE6 MHg4MGFkYmM4IGxlbjoyNCBhOjB4ODBhZDczMCBsZW46MTI4IDxicj6goKCgoKCgIEJVRjqgICNy ZWdzOjKgoCBzdGFydCBibGtubzoweDGgoCBsZW46MaCgIGJtYXAgc2l6ZToxoKAgZmxhZ3M6MHgw PGJyPqCgoKCgoKAgQUdGIEJ1ZmZlcjogKFhBR0YpPGJyPkJVRjogY250OjIgdG90YWw6MiBhOjB4 ODBhZGFlOCBsZW46MjggYToweDgwYWRhMjAgbGVuOjEyOCA8YnI+CqCgoKCgoKAgQlVGOqAgI3Jl Z3M6MqCgIHN0YXJ0IGJsa25vOjB4MTCgoCBsZW46OKCgIGJtYXAgc2l6ZToyoKAgZmxhZ3M6MHgw PGJyPqCgoKCgoKAgQlVGIERBVEE8YnI+QlVGOiBjbnQ6MiB0b3RhbDoyIGE6MHg4MGI1YzA4IGxl bjoyOCBhOjB4ODBiNWQzOCBsZW46MTI4IDxicj6goKCgoKCgIEJVRjqgICNyZWdzOjKgoCBzdGFy dCBibGtubzoweDigoCBsZW46OKCgIGJtYXAgc2l6ZToyoKAgZmxhZ3M6MHgwPGJyPgqgoKCgoKCg IEJVRiBEQVRBPGJyPkJVRjogY250OjIgdG90YWw6MiBhOjB4ODBiNWM0OCBsZW46MjQgYToweDgw YjVkYzAgbGVuOjEyOCA8YnI+oKCgoKCgoCBCVUY6oCAjcmVnczoyoKAgc3RhcnQgYmxrbm86MHgw oKAgbGVuOjGgoCBibWFwIHNpemU6MaCgIGZsYWdzOjB4MDxicj6goKCgoKCgIFNVUEVSIEJsb2Nr IEJ1ZmZlcjo8YnI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4KVFJBTlM6IHRpZDoweDg2M2M1MDAw oCB0eXBlOlNUUkFUX1dSSVRFoCAjaXRlbXM6NaAgdHJhbnM6MHgwoCBxOjB4ODBiNWM2ODxicj5J Tk86IGNudDozIHRvdGFsOjMgYToweDgwYWRiODggbGVuOjU2IGE6MHg4MGFkYjIwIGxlbjo5NiBh OjB4ODBiNWM4OCBsZW46MTYgPGJyPqCgoKCgoKAgSU5PREU6ICNyZWdzOjOgoCBpbm86MHg4NaAg ZmxhZ3M6MHg1oKAgZHNpemU6MTY8YnI+oKCgoKCgoCBDT1JFIGlub2RlOjxicj4KoKCgoKCgoKCg oKCgoKCgIERBVEEgRk9SSyBFWFRFTlRTIGlub2RlIGRhdGE6PGJyPkJVRjogY250OjIgdG90YWw6 MiBhOjB4ODBhZDZmOCBsZW46MjQgYToweDgwYWQ3MzAgbGVuOjEyOCA8YnI+oKCgoKCgoCBCVUY6 oCAjcmVnczoyoKAgc3RhcnQgYmxrbm86MHgxoKAgbGVuOjGgoCBibWFwIHNpemU6MaCgIGZsYWdz OjB4MDxicj6goKCgoKCgIEFHRiBCdWZmZXI6IChYQUdGKTxicj5CVUY6IGNudDoyIHRvdGFsOjIg YToweDgwYWQ3YjggbGVuOjI4IGE6MHg4MGFkYTIwIGxlbjoxMjggPGJyPgqgoKCgoKCgIEJVRjqg ICNyZWdzOjKgoCBzdGFydCBibGtubzoweDEwoKAgbGVuOjigoCBibWFwIHNpemU6MqCgIGZsYWdz OjB4MDxicj6goKCgoKCgIEJVRiBEQVRBPGJyPkJVRjogY250OjIgdG90YWw6MiBhOjB4ODBiNWMy OCBsZW46MjggYToweDgwYjVkMzggbGVuOjEyOCA8YnI+oKCgoKCgoCBCVUY6oCAjcmVnczoyoKAg c3RhcnQgYmxrbm86MHg4oKAgbGVuOjigoCBibWFwIHNpemU6MqCgIGZsYWdzOjB4MDxicj4KoKCg oKCgoCBCVUYgREFUQTxicj5CVUY6IGNudDoyIHRvdGFsOjIgYToweDgwYjVkMTggbGVuOjI0IGE6 MHg4MGI1ZGMwIGxlbjoxMjggPGJyPqCgoKCgoKAgQlVGOqAgI3JlZ3M6MqCgIHN0YXJ0IGJsa25v OjB4MKCgIGxlbjoxoKAgYm1hcCBzaXplOjGgoCBmbGFnczoweDA8YnI+oKCgoKCgoCBTVVBFUiBC bG9jayBCdWZmZXI6PGJyPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+ClRSQU5TOiB0aWQ6MHg4NjNj NTAwMKAgdHlwZTpTVFJBVF9XUklURaAgI2l0ZW1zOjWgIHRyYW5zOjB4MKAgcToweDgwYjVjZjg8 YnI+SU5POiBjbnQ6MyB0b3RhbDozIGE6MHg4MGFkYjg4IGxlbjo1NiBhOjB4ODBhZGIyMCBsZW46 OTYgYToweDgwYWRiZTggbGVuOjE2IDxicj6goKCgoKCgIElOT0RFOiAjcmVnczozoKAgaW5vOjB4 ODWgIGZsYWdzOjB4NaCgIGRzaXplOjE2PGJyPqCgoKCgoKAgQ09SRSBpbm9kZTo8YnI+CqCgoKCg oKCgoKCgoKCgoCBEQVRBIEZPUksgRVhURU5UUyBpbm9kZSBkYXRhOjxicj5CVUY6IGNudDoyIHRv dGFsOjIgYToweDgwYWRiYzggbGVuOjI0IGE6MHg4MGFkNzMwIGxlbjoxMjggPGJyPqCgoKCgoKAg QlVGOqAgI3JlZ3M6MqCgIHN0YXJ0IGJsa25vOjB4MaCgIGxlbjoxoKAgYm1hcCBzaXplOjGgoCBm bGFnczoweDA8YnI+oKCgoKCgoCBBR0YgQnVmZmVyOiAoWEFHRik8YnI+QlVGOiBjbnQ6MiB0b3Rh bDoyIGE6MHg4MGFkYWU4IGxlbjoyOCBhOjB4ODBhZGEyMCBsZW46MTI4IDxicj4KoKCgoKCgoCBC VUY6oCAjcmVnczoyoKAgc3RhcnQgYmxrbm86MHgxMKCgIGxlbjo4oKAgYm1hcCBzaXplOjKgoCBm bGFnczoweDA8YnI+oKCgoKCgoCBCVUYgREFUQTxicj5CVUY6IGNudDoyIHRvdGFsOjIgYToweDgw YjVjMDggbGVuOjI4IGE6MHg4MGI1ZDM4IGxlbjoxMjggPGJyPqCgoKCgoKAgQlVGOqAgI3JlZ3M6 MqCgIHN0YXJ0IGJsa25vOjB4OKCgIGxlbjo4oKAgYm1hcCBzaXplOjKgoCBmbGFnczoweDA8YnI+ CqCgoKCgoKAgQlVGIERBVEE8YnI+QlVGOiBjbnQ6MiB0b3RhbDoyIGE6MHg4MGI1YzY4IGxlbjoy NCBhOjB4ODBiNWRjMCBsZW46MTI4IDxicj6goKCgoKCgIEJVRjqgICNyZWdzOjKgoCBzdGFydCBi bGtubzoweDCgoCBsZW46MaCgIGJtYXAgc2l6ZToxoKAgZmxhZ3M6MHgwPGJyPqCgoKCgoKAgU1VQ RVIgQmxvY2sgQnVmZmVyOjxicj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPgpUUkFOUzogdGlkOjB4 ODYzYzUwMDCgIHR5cGU6U1RSQVRfV1JJVEWgICNpdGVtczo1oCB0cmFuczoweDCgIHE6MHg4MGI1 YzQ4PGJyPklOTzogY250OjMgdG90YWw6MyBhOjB4ODBhZGI4OCBsZW46NTYgYToweDgwYWRiMjAg bGVuOjk2IGE6MHg4MGI1Yzg4IGxlbjoxNiA8YnI+oKCgoKCgoCBJTk9ERTogI3JlZ3M6M6CgIGlu bzoweDg1oCBmbGFnczoweDWgoCBkc2l6ZToxNjxicj6goKCgoKCgIENPUkUgaW5vZGU6PGJyPgqg oKCgoKCgoKCgoKCgoKAgREFUQSBGT1JLIEVYVEVOVFMgaW5vZGUgZGF0YTo8YnI+QlVGOiBjbnQ6 MiB0b3RhbDoyIGE6MHg4MGFkNmY4IGxlbjoyNCBhOjB4ODBhZDczMCBsZW46MTI4IDxicj6goKCg oKCgIEJVRjqgICNyZWdzOjKgoCBzdGFydCBibGtubzoweDGgoCBsZW46MaCgIGJtYXAgc2l6ZTox oKAgZmxhZ3M6MHgwPGJyPqCgoKCgoKAgQUdGIEJ1ZmZlcjogKFhBR0YpPGJyPkJVRjogY250OjIg dG90YWw6MiBhOjB4ODBhZDdiOCBsZW46MjggYToweDgwYWRhMjAgbGVuOjEyOCA8YnI+CqCgoKCg oKAgQlVGOqAgI3JlZ3M6MqCgIHN0YXJ0IGJsa25vOjB4MTCgoCBsZW46OKCgIGJtYXAgc2l6ZToy oKAgZmxhZ3M6MHgwPGJyPqCgoKCgoKAgQlVGIERBVEE8YnI+QlVGOiBjbnQ6MiB0b3RhbDoyIGE6 MHg4MGI1YzI4IGxlbjoyOCBhOjB4ODBiNWQzOCBsZW46MTI4IDxicj6goKCgoKCgIEJVRjqgICNy ZWdzOjKgoCBzdGFydCBibGtubzoweDigoCBsZW46OKCgIGJtYXAgc2l6ZToyoKAgZmxhZ3M6MHgw PGJyPgqgoKCgoKCgIEJVRiBEQVRBPGJyPkJVRjogY250OjIgdG90YWw6MiBhOjB4ODBiNWNmOCBs ZW46MjQgYToweDgwYjVkYzAgbGVuOjEyOCA8YnI+oKCgoKCgoCBCVUY6oCAjcmVnczoyoKAgc3Rh cnQgYmxrbm86MHgwoKAgbGVuOjGgoCBibWFwIHNpemU6MaCgIGZsYWdzOjB4MDxicj6goKCgoKCg IFNVUEVSIEJsb2NrIEJ1ZmZlcjo8YnI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4KVFJBTlM6IHRp ZDoweDg2M2M1MDAwoCB0eXBlOlNUUkFUX1dSSVRFoCAjaXRlbXM6NaAgdHJhbnM6MHgwoCBxOjB4 ODBiNWQxODxicj5JTk86IGNudDozIHRvdGFsOjMgYToweDgwYWRiODggbGVuOjU2IGE6MHg4MGFk YjIwIGxlbjo5NiBhOjB4ODBhZGJlOCBsZW46MTYgPGJyPqCgoKCgoKAgSU5PREU6ICNyZWdzOjOg oCBpbm86MHg4NaAgZmxhZ3M6MHg1oKAgZHNpemU6MTY8YnI+oKCgoKCgoCBDT1JFIGlub2RlOjxi cj4KoKCgoKCgoKCgoKCgoKCgIERBVEEgRk9SSyBFWFRFTlRTIGlub2RlIGRhdGE6PGJyPkJVRjog Y250OjIgdG90YWw6MiBhOjB4ODBhZGJjOCBsZW46MjQgYToweDgwYWQ3MzAgbGVuOjEyOCA8YnI+ oKCgoKCgoCBCVUY6oCAjcmVnczoyoKAgc3RhcnQgYmxrbm86MHgxoKAgbGVuOjGgoCBibWFwIHNp emU6MaCgIGZsYWdzOjB4MDxicj6goKCgoKCgIEFHRiBCdWZmZXI6IChYQUdGKTxicj5CVUY6IGNu dDoyIHRvdGFsOjIgYToweDgwYWRhZTggbGVuOjI4IGE6MHg4MGFkYTIwIGxlbjoxMjggPGJyPgqg oKCgoKCgIEJVRjqgICNyZWdzOjKgoCBzdGFydCBibGtubzoweDEwoKAgbGVuOjigoCBibWFwIHNp emU6MqCgIGZsYWdzOjB4MDxicj6goKCgoKCgIEJVRiBEQVRBPGJyPkJVRjogY250OjIgdG90YWw6 MiBhOjB4ODBiNWMwOCBsZW46MjggYToweDgwYjVkMzggbGVuOjEyOCA8YnI+oKCgoKCgoCBCVUY6 oCAjcmVnczoyoKAgc3RhcnQgYmxrbm86MHg4oKAgbGVuOjigoCBibWFwIHNpemU6MqCgIGZsYWdz OjB4MDxicj4KoKCgoKCgoCBCVUYgREFUQTxicj5CVUY6IGNudDoyIHRvdGFsOjIgYToweDgwYjVj NDggbGVuOjI0IGE6MHg4MGI1ZGMwIGxlbjoxMjggPGJyPqCgoKCgoKAgQlVGOqAgI3JlZ3M6MqCg IHN0YXJ0IGJsa25vOjB4MKCgIGxlbjoxoKAgYm1hcCBzaXplOjGgoCBmbGFnczoweDA8YnI+oKCg oKCgoCBTVVBFUiBCbG9jayBCdWZmZXI6PGJyPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+ClRSQU5T OiB0aWQ6MHg4NjNjNTAwMKAgdHlwZTpTVFJBVF9XUklURaAgI2l0ZW1zOjWgIHRyYW5zOjB4MKAg cToweDgwYjVjNjg8YnI+SU5POiBjbnQ6MyB0b3RhbDozIGE6MHg4MGFkYjg4IGxlbjo1NiBhOjB4 ODBhZGIyMCBsZW46OTYgYToweDgwYjVjODggbGVuOjE2IDxicj6goKCgoKCgIElOT0RFOiAjcmVn czozoKAgaW5vOjB4ODWgIGZsYWdzOjB4NaCgIGRzaXplOjE2PGJyPqCgoKCgoKAgQ09SRSBpbm9k ZTo8YnI+CqCgoKCgoKCgoKCgoKCgoCBEQVRBIEZPUksgRVhURU5UUyBpbm9kZSBkYXRhOjxicj5C VUY6IGNudDoyIHRvdGFsOjIgYToweDgwYWQ2ZjggbGVuOjI0IGE6MHg4MGFkNzMwIGxlbjoxMjgg PGJyPqCgoKCgoKAgQlVGOqAgI3JlZ3M6MqCgIHN0YXJ0IGJsa25vOjB4MaCgIGxlbjoxoKAgYm1h cCBzaXplOjGgoCBmbGFnczoweDA8YnI+oKCgoKCgoCBBR0YgQnVmZmVyOiAoWEFHRik8YnI+QlVG OiBjbnQ6MiB0b3RhbDoyIGE6MHg4MGFkN2I4IGxlbjoyOCBhOjB4ODBhZGEyMCBsZW46MTI4IDxi cj4KoKCgoKCgoCBCVUY6oCAjcmVnczoyoKAgc3RhcnQgYmxrbm86MHgxMKCgIGxlbjo4oKAgYm1h cCBzaXplOjKgoCBmbGFnczoweDA8YnI+oKCgoKCgoCBCVUYgREFUQTxicj5CVUY6IGNudDoyIHRv dGFsOjIgYToweDgwYjVjMjggbGVuOjI4IGE6MHg4MGI1ZDM4IGxlbjoxMjggPGJyPqCgoKCgoKAg QlVGOqAgI3JlZ3M6MqCgIHN0YXJ0IGJsa25vOjB4OKCgIGxlbjo4oKAgYm1hcCBzaXplOjKgoCBm bGFnczoweDA8YnI+CqCgoKCgoKAgQlVGIERBVEE8YnI+QlVGOiBjbnQ6MiB0b3RhbDoyIGE6MHg4 MGI1ZDE4IGxlbjoyNCBhOjB4ODBiNWRjMCBsZW46MTI4IDxicj6goKCgoKCgIEJVRjqgICNyZWdz OjKgoCBzdGFydCBibGtubzoweDCgoCBsZW46MaCgIGJtYXAgc2l6ZToxoKAgZmxhZ3M6MHgwPGJy PqCgoKCgoKAgU1VQRVIgQmxvY2sgQnVmZmVyOjxicj49PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPgpU UkFOUzogdGlkOjB4ODYzYzUwMDCgIHR5cGU6U1RSQVRfV1JJVEWgICNpdGVtczo1oCB0cmFuczow eDCgIHE6MHg4MGI1Y2Y4PGJyPklOTzogY250OjMgdG90YWw6MyBhOjB4ODBhZGI4OCBsZW46NTYg YToweDgwYWRiMjAgbGVuOjk2IGE6MHg4MGFkYmU4IGxlbjoxNiA8YnI+oKCgoKCgoCBJTk9ERTog I3JlZ3M6M6CgIGlubzoweDg1oCBmbGFnczoweDWgoCBkc2l6ZToxNjxicj6goKCgoKCgIENPUkUg aW5vZGU6PGJyPgqgoKCgoKCgoKCgoKCgoKAgREFUQSBGT1JLIEVYVEVOVFMgaW5vZGUgZGF0YTo8 YnI+QlVGOiBjbnQ6MiB0b3RhbDoyIGE6MHg4MGFkYmM4IGxlbjoyNCBhOjB4ODBhZDczMCBsZW46 MTI4IDxicj6goKCgoKCgIEJVRjqgICNyZWdzOjKgoCBzdGFydCBibGtubzoweDGgoCBsZW46MaCg IGJtYXAgc2l6ZToxoKAgZmxhZ3M6MHgwPGJyPqCgoKCgoKAgQUdGIEJ1ZmZlcjogKFhBR0YpPGJy PkJVRjogY250OjIgdG90YWw6MiBhOjB4ODBhZGFlOCBsZW46MjggYToweDgwYWRhMjAgbGVuOjEy OCA8YnI+CqCgoKCgoKAgQlVGOqAgI3JlZ3M6MqCgIHN0YXJ0IGJsa25vOjB4MTCgoCBsZW46OKCg IGJtYXAgc2l6ZToyoKAgZmxhZ3M6MHgwPGJyPqCgoKCgoKAgQlVGIERBVEE8YnI+QlVGOiBjbnQ6 MiB0b3RhbDoyIGE6MHg4MGI1YzA4IGxlbjoyOCBhOjB4ODBiNWQzOCBsZW46MTI4IDxicj6goKCg oKCgIEJVRjqgICNyZWdzOjKgoCBzdGFydCBibGtubzoweDigoCBsZW46OKCgIGJtYXAgc2l6ZToy oKAgZmxhZ3M6MHgwPGJyPgqgoKCgoKCgIEJVRiBEQVRBPGJyPkJVRjogY250OjIgdG90YWw6MiBh OjB4ODBiNWM2OCBsZW46MjQgYToweDgwYjVkYzAgbGVuOjEyOCA8YnI+oKCgoKCgoCBCVUY6oCAj cmVnczoyoKAgc3RhcnQgYmxrbm86MHgwoKAgbGVuOjGgoCBibWFwIHNpemU6MaCgIGZsYWdzOjB4 MDxicj6goKCgoKCgIFNVUEVSIEJsb2NrIEJ1ZmZlcjo8YnI+PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxi cj4KVFJBTlM6IHRpZDoweDg2M2M1MDAwoCB0eXBlOlNUUkFUX1dSSVRFoCAjaXRlbXM6NaAgdHJh bnM6MHgwoCBxOjB4ODBiNWM0ODxicj5JTk86IGNudDozIHRvdGFsOjMgYToweDgwYWRiODggbGVu OjU2IGE6MHg4MGFkYjIwIGxlbjo5NiBhOjB4ODBiNWM4OCBsZW46MTYgPGJyPqCgoKCgoKAgSU5P REU6ICNyZWdzOjOgoCBpbm86MHg4NaAgZmxhZ3M6MHg1oKAgZHNpemU6MTY8YnI+oKCgoKCgoCBD T1JFIGlub2RlOjxicj4KoKCgoKCgoKCgoKCgoKCgIERBVEEgRk9SSyBFWFRFTlRTIGlub2RlIGRh dGE6PGJyPkJVRjogY250OjIgdG90YWw6MiBhOjB4ODBhZDZmOCBsZW46MjQgYToweDgwYWQ3MzAg bGVuOjEyOCA8YnI+oKCgoKCgoCBCVUY6oCAjcmVnczoyoKAgc3RhcnQgYmxrbm86MHgxoKAgbGVu OjGgoCBibWFwIHNpemU6MaCgIGZsYWdzOjB4MDxicj6goKCgoKCgIEFHRiBCdWZmZXI6IChYQUdG KTxicj5CVUY6IGNudDoyIHRvdGFsOjIgYToweDgwYWQ3YjggbGVuOjI4IGE6MHg4MGFkYTIwIGxl bjoxMjggPGJyPgqgoKCgoKCgIEJVRjqgICNyZWdzOjKgoCBzdGFydCBibGtubzoweDEwoKAgbGVu OjigoCBibWFwIHNpemU6MqCgIGZsYWdzOjB4MDxicj6goKCgoKCgIEJVRiBEQVRBPGJyPkJVRjog Y250OjIgdG90YWw6MiBhOjB4ODBiNWMyOCBsZW46MjggYToweDgwYjVkMzggbGVuOjEyOCA8YnI+ oKCgoKCgoCBCVUY6oCAjcmVnczoyoKAgc3RhcnQgYmxrbm86MHg4oKAgbGVuOjigoCBibWFwIHNp emU6MqCgIGZsYWdzOjB4MDxicj4KoKCgoKCgoCBCVUYgREFUQTxicj5CVUY6IGNudDoyIHRvdGFs OjIgYToweDgwYjVjZjggbGVuOjI0IGE6MHg4MGI1ZGMwIGxlbjoxMjggPGJyPqCgoKCgoKAgQlVG OqAgI3JlZ3M6MqCgIHN0YXJ0IGJsa25vOjB4MKCgIGxlbjoxoKAgYm1hcCBzaXplOjGgoCBmbGFn czoweDA8YnI+oKCgoKCgoCBTVVBFUiBCbG9jayBCdWZmZXI6PGJyPqA8YnI+TE9HIFJFQyBBVCBM U04gY3ljbGUgMSBibG9jayAzNDggKDB4MSwgMHgxNWMpPGJyPgpYRlM6IHhsb2dfcmVjb3Zlcl9w cm9jZXNzX2RhdGE6IGJhZCB0cmFuc2FjdGlvbjxicj54ZnNfbG9ncHJpbnQ6IGZhaWxlZCBpbiB4 ZnNfZG9fcmVjb3ZlcnlfcGFzcywgZXJyb3I6IDU8YnI+PC9kaXY+Cg== --0015175cb71a246c770496541099-- From eflorac@intellique.com Wed Dec 1 01:40:52 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB17eqs0185491 for ; Wed, 1 Dec 2010 01:40:52 -0600 X-ASG-Debug-ID: 1291189352-7bc302ac0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6E5BB1C85510 for ; Tue, 30 Nov 2010 23:42:33 -0800 (PST) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by cuda.sgi.com with ESMTP id 1aYLDzNT5Ll8140k for ; Tue, 30 Nov 2010 23:42:33 -0800 (PST) Received: from galadriel.home (unknown [82.235.234.79]) by smtp3-g21.free.fr (Postfix) with ESMTP id 72181A6257; Wed, 1 Dec 2010 08:42:28 +0100 (CET) Date: Wed, 1 Dec 2010 08:42:25 +0100 From: Emmanuel Florac To: naveen yadav Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: issue with unmount of XFS partation Subject: Re: issue with unmount of XFS partation Message-ID: <20101201084225.7e47a2ff@galadriel.home> In-Reply-To: References: Organization: Intellique X-Mailer: Claws Mail 3.7.3 (GTK+ 2.20.1; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: smtp3-g21.free.fr[212.27.42.3] X-Barracuda-Start-Time: 1291189355 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48145 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Le Wed, 1 Dec 2010 10:13:57 +0530 vous =E9criviez: > FAT got unmounted every time, but XFS does not, >=20 > /dev/sda2 on /dtv/usb/sda2 type xfs (rw,relatime,nouuid,attr2,noquota) > /dev/sdb2 on /dtv/usb/sdb2 type xfs (rw,relatime,nouuid,attr2,noquota) >=20 > If I do sync on Shell I got below error. I don't get it, do you unmount the FS before unplugging USB? It looks like you simply pulled the cable. FAT is an extremely primitive filesystem that remains coherent when there isn't any data in cache or disk activity; xfs (and all other modern filesystems) simply doesn't work that way. You must "umount" it before unplugging, else you'll break it. --=20 ------------------------------------------------------------------------ Emmanuel Florac | Direction technique | Intellique | | +33 1 78 94 84 02 ------------------------------------------------------------------------ From MAILER-DAEMON@oss.sgi.com Wed Dec 1 05:47:56 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_20,MISSING_MIME_HB_SEP, T_MIME_NO_TEXT,T_TVD_MIME_NO_HEADERS autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB1Blubd204291 for ; Wed, 1 Dec 2010 05:47:56 -0600 X-ASG-Debug-ID: 1291204179-457e01330000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail7.fastdnsnetwork.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 784071B9DA6 for ; Wed, 1 Dec 2010 03:49:39 -0800 (PST) Received: from mail7.fastdnsnetwork.com (mail7.fastdnsnetwork.com [174.133.162.186]) by cuda.sgi.com with ESMTP id bKiaCfBu3sXMLbfj for ; Wed, 01 Dec 2010 03:49:39 -0800 (PST) Received: (qmail 21039 invoked for bounce); 1 Dec 2010 11:48:15 -0000 Date: 1 Dec 2010 11:48:15 -0000 From: MAILER-DAEMON@mail7.fastdnsnetwork.com To: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1291204095mail7.fastdnsnetwork.com33097008" X-ASG-Orig-Subj: failure notice Subject: failure notice X-Barracuda-Connect: mail7.fastdnsnetwork.com[174.133.162.186] X-Barracuda-Start-Time: 1291204179 Message-Id: <20101201114939.784071B9DA6@cuda.sgi.com> X-Barracuda-Bayes: INNOCENT GLOBAL 0.1645 1.0000 -1.0202 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.68 X-Barracuda-Spam-Status: No, SCORE=-0.68 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=ANY_BOUNCE_MESSAGE, BOUNCE_MESSAGE, BSF_SC0_MISSING_MID, BSF_SC0_SA590, NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48160 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name 0.14 BSF_SC0_MISSING_MID BODY: Custom Rule BSF_SC0_MISSING_MID 0.20 BSF_SC0_SA590 Custom Rule SA590 0.00 BOUNCE_MESSAGE MTA bounce message 0.00 ANY_BOUNCE_MESSAGE Message is some kind of bounce message X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --1291204095mail7.fastdnsnetwork.com33097008 Hi. This is the qmail-send program at mail7.fastdnsnetwork.com. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. : mail is looping --- Enclosed are the original headers of the message. --1291204095mail7.fastdnsnetwork.com33097008 Content-Type: message/rfc822 Return-Path: Received: (qmail 20900 invoked by uid 399); 1 Dec 2010 11:48:09 -0000 Delivered-To: bennorayan@goodleather.net Received: (qmail 20786 invoked by uid 399); 1 Dec 2010 11:48:04 -0000 Message-ID: <20101201114804.20785.qmail@mail7.fastdnsnetwork.com> Delivered-To: goodledr@goodleather.net Received: (qmail 20708 invoked by uid 399); 1 Dec 2010 11:47:59 -0000 Received: from unknown (HELO oss.sgi.com) (122.166.114.232) by mail7.fastdnsnetwork.com with ESMTP; 1 Dec 2010 11:47:59 -0000 X-Originating-IP: 122.166.114.232 Received-SPF: none (mail7.fastdnsnetwork.com: domain at oss.sgi.com does not designate permitted sender hosts) identity=mailfrom; client-ip=122.166.114.232; envelope-from=; From: xfs@oss.sgi.com To: goodledr@goodleather.net Subject: MESSAGE COULD NOT BE DELIVERED Date: Wed, 1 Dec 2010 17:18:21 +0530 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0008_074DE884.2DD529BA" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 (Body supressed) ------=_NextPart_000_0008_074DE884.2DD529BA-- --1291204095mail7.fastdnsnetwork.com33097008-- From BATV+3217d6c06e4d83826047+2656+infradead.org+hch@bombadil.srs.infradead.org Wed Dec 1 06:28:53 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB1CSpQm206746 for ; Wed, 1 Dec 2010 06:28:53 -0600 X-ASG-Debug-ID: 1291206634-4f7d01390000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B34621BA206 for ; Wed, 1 Dec 2010 04:30:34 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id l8bysXQsBmqld5ap for ; Wed, 01 Dec 2010 04:30:34 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PNlpQ-0008Sn-PM; Wed, 01 Dec 2010 12:30:32 +0000 Date: Wed, 1 Dec 2010 07:30:32 -0500 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 02/14] xfs: clean up log space grant functions Subject: Re: [PATCH 02/14] xfs: clean up log space grant functions Message-ID: <20101201123032.GA20378@infradead.org> References: <1290994712-21376-1-git-send-email-david@fromorbit.com> <1290994712-21376-3-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1290994712-21376-3-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291206634 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mon, Nov 29, 2010 at 12:38:20PM +1100, Dave Chinner wrote: > From: Dave Chinner > > xlog_grant_log_space and xlog_regrant_log_write_space both have very > similar structure. Both have a "wait on non-empty queue" section at > the start, followed by a "wait for space" loop of which the contents > are almost identical to the initial non-empty queue section. > > In both cases, the non-empty queue wait can be folded into the wait > for space loop, simply by entering the loop if the queue is not > empty and the current ticket is not on the queue. If we trigger the > non-empty queue case, we always add ourselves to the queue, and > hence the second and subsequent loops are always driven by the "wait > for space" test. > > IOWs, both wait conditions can be folded into the one loop, removing > a bunch of duplicated code and making it simpler to modify in > future patches. I don't really like this patch. The new conditions are overly complicated because of the desire to only go through the loop once for the queue not empty case. In addition there's some behaviour changes: - in xlog_grant_log_space we previously didn't call xlog_grant_push_ail for the queue not empty case, and now we do. - in xlog_regrant_write_log_space the old version of the queue not empty case would loop over all waiting tickets, and if we could wake up all of them we'll skip the first wait, and given enough free space also the second wait, while the new code always adds it to the writeq, although it will still skip the actualy wait later. My recommendation would be to skip this patch for now and revisit the area later. For example the superflous xlog_grant_push_ail actually is rather harmless these days with the xfsaild threshold, so not skipping it for the first case probably is fine in the end. Then again the whole add to the queue just in case if it's non-empty doesn't make much sense to me to start with. As soon as xfs_log_move_tail makes space in the log it wakes up all tickets waiting for it anyway, so adding us to the queue just in case seems rather inefficient, and not overl helpful. From BATV+3217d6c06e4d83826047+2656+infradead.org+hch@bombadil.srs.infradead.org Wed Dec 1 06:33:11 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB1CXBuw206973 for ; Wed, 1 Dec 2010 06:33:11 -0600 X-ASG-Debug-ID: 1291206894-4f7d014d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E4CE01BA235 for ; Wed, 1 Dec 2010 04:34:54 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id h6qe7ggXkOvHDQtY for ; Wed, 01 Dec 2010 04:34:54 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PNlte-0000BE-DI; Wed, 01 Dec 2010 12:34:54 +0000 Date: Wed, 1 Dec 2010 07:34:54 -0500 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 04/14] xfs: use wait queues directly for log grant queues Subject: Re: [PATCH 04/14] xfs: use wait queues directly for log grant queues Message-ID: <20101201123454.GA612@infradead.org> References: <1290994712-21376-1-git-send-email-david@fromorbit.com> <1290994712-21376-5-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1290994712-21376-5-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291206894 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mon, Nov 29, 2010 at 12:38:22PM +1100, Dave Chinner wrote: > From: Dave Chinner > > The log grant queues are one of the few places left using sv_t > constructs for waiting. Convert them to use wait queues directly > while we are cleaning up the code to move one step closer to remove > the sv_t type from the XFS codebase. Doing this one separately from the other sv_t removal seems a bit pointless. From BATV+3217d6c06e4d83826047+2656+infradead.org+hch@bombadil.srs.infradead.org Wed Dec 1 06:40:52 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB1Cep1V207442 for ; Wed, 1 Dec 2010 06:40:52 -0600 X-ASG-Debug-ID: 1291207355-4f7d018a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 69D751BA274 for ; Wed, 1 Dec 2010 04:42:35 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id m2zCzzLfuPlb0TYe for ; Wed, 01 Dec 2010 04:42:35 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PNm15-0001eE-1t; Wed, 01 Dec 2010 12:42:35 +0000 Date: Wed, 1 Dec 2010 07:42:35 -0500 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 03/14] xfs: convert log grant heads to LSN notation Subject: Re: [PATCH 03/14] xfs: convert log grant heads to LSN notation Message-ID: <20101201124234.GB612@infradead.org> References: <1290994712-21376-1-git-send-email-david@fromorbit.com> <1290994712-21376-4-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1290994712-21376-4-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291207355 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean The patch looks good to me, but I really hate overloading the lsn types and helpers. Just add duplicated of CYCLE_LSN/BLOCK_LSN and xlog_assign_lsn for a new type as use them. From BATV+3217d6c06e4d83826047+2656+infradead.org+hch@bombadil.srs.infradead.org Wed Dec 1 06:43:57 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB1ChvZp207784 for ; Wed, 1 Dec 2010 06:43:57 -0600 X-ASG-Debug-ID: 1291207540-083e00540000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1E4EF140434D for ; Wed, 1 Dec 2010 04:45:40 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id Iy0vDivUZzxRXprn for ; Wed, 01 Dec 2010 04:45:40 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PNm44-0002PD-Bl; Wed, 01 Dec 2010 12:45:40 +0000 Date: Wed, 1 Dec 2010 07:45:40 -0500 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 05/14] xfs: make AIL tail pushing independent of the grant lock Subject: Re: [PATCH 05/14] xfs: make AIL tail pushing independent of the grant lock Message-ID: <20101201124540.GC612@infradead.org> References: <1290994712-21376-1-git-send-email-david@fromorbit.com> <1290994712-21376-6-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1290994712-21376-6-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291207541 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Once l_tail_lsn and l_last_sync_lsn are converted to atomic64_ts later in the series passing them in separately becomes pointless again. Maybe scale the patch back a bit and require the caller to hold l_grant_lock for now, until the atomic64_t conversion happens. From BATV+3217d6c06e4d83826047+2656+infradead.org+hch@bombadil.srs.infradead.org Wed Dec 1 06:53:01 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB1Cr0E4208341 for ; Wed, 1 Dec 2010 06:53:01 -0600 X-ASG-Debug-ID: 1291208083-0bf8006a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id EC8231404474 for ; Wed, 1 Dec 2010 04:54:43 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id cUkp1cjKU1cRCXnc for ; Wed, 01 Dec 2010 04:54:43 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PNmCp-0003HE-A4; Wed, 01 Dec 2010 12:54:43 +0000 Date: Wed, 1 Dec 2010 07:54:43 -0500 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 06/14] xfs: convert l_last_sync_lsn to an atomic variable Subject: Re: [PATCH 06/14] xfs: convert l_last_sync_lsn to an atomic variable Message-ID: <20101201125443.GD612@infradead.org> References: <1290994712-21376-1-git-send-email-david@fromorbit.com> <1290994712-21376-7-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1290994712-21376-7-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291208083 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Looks good, Reviewed-by: Christoph Hellwig From BATV+3217d6c06e4d83826047+2656+infradead.org+hch@bombadil.srs.infradead.org Wed Dec 1 06:54:22 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB1CsLBR208436 for ; Wed, 1 Dec 2010 06:54:22 -0600 X-ASG-Debug-ID: 1291208165-6d22013d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 90AC41C85F8B for ; Wed, 1 Dec 2010 04:56:05 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id jeLh54POaroeDZg7 for ; Wed, 01 Dec 2010 04:56:05 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PNmE8-0003xK-V8; Wed, 01 Dec 2010 12:56:05 +0000 Date: Wed, 1 Dec 2010 07:56:04 -0500 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 07/14] xfs: convert l_tail_lsn to an atomic variable. Subject: Re: [PATCH 07/14] xfs: convert l_tail_lsn to an atomic variable. Message-ID: <20101201125604.GE612@infradead.org> References: <1290994712-21376-1-git-send-email-david@fromorbit.com> <1290994712-21376-8-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1290994712-21376-8-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291208165 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Looks good, Reviewed-by: Christoph Hellwig From BATV+3217d6c06e4d83826047+2656+infradead.org+hch@bombadil.srs.infradead.org Wed Dec 1 06:57:37 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB1Cvb2g208651 for ; Wed, 1 Dec 2010 06:57:37 -0600 X-ASG-Debug-ID: 1291208361-6d2f01630000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 37FE11C86905 for ; Wed, 1 Dec 2010 04:59:21 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id GxLMksyaNx2cGes2 for ; Wed, 01 Dec 2010 04:59:21 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PNmHI-00044q-PM; Wed, 01 Dec 2010 12:59:20 +0000 Date: Wed, 1 Dec 2010 07:59:20 -0500 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 08/14] xfs: convert log grant heads to atomic variables Subject: Re: [PATCH 08/14] xfs: convert log grant heads to atomic variables Message-ID: <20101201125920.GF612@infradead.org> References: <1290994712-21376-1-git-send-email-david@fromorbit.com> <1290994712-21376-9-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1290994712-21376-9-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291208361 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mon, Nov 29, 2010 at 12:38:26PM +1100, Dave Chinner wrote: > From: Dave Chinner > > Convert the log grant heads to atomic64_t types in preparation for > converting the accounting algorithms to atomic operations. his patch > just converts the variables; the algorithmic changes are in a > separate patch for clarity. > > Signed-off-by: Dave Chinner > --- > fs/xfs/linux-2.6/xfs_trace.h | 18 +++++++------ > fs/xfs/xfs_log.c | 54 +++++++++++++++++++++-------------------- > fs/xfs/xfs_log_priv.h | 4 +- > fs/xfs/xfs_log_recover.c | 8 +++--- > 4 files changed, 44 insertions(+), 40 deletions(-) > > diff --git a/fs/xfs/linux-2.6/xfs_trace.h b/fs/xfs/linux-2.6/xfs_trace.h > index d2cdc85..68c3bdd 100644 > --- a/fs/xfs/linux-2.6/xfs_trace.h > +++ b/fs/xfs/linux-2.6/xfs_trace.h > @@ -768,8 +768,8 @@ DECLARE_EVENT_CLASS(xfs_loggrant_class, > __field(unsigned int, flags) > __field(void *, reserveq) > __field(void *, writeq) > - __field(xfs_lsn_t, grant_reserve_lsn) > - __field(xfs_lsn_t, grant_write_lsn) > + __field(xfs_lsn_t, grant_reserve_head) > + __field(xfs_lsn_t, grant_write_head) What about just naming them _head from the beginning? That would be a tad cleaner. Same for the actual variables in the log, even if they change the type here. Otherwise looks good, Reviewed-by: Christoph Hellwig From BATV+3217d6c06e4d83826047+2656+infradead.org+hch@bombadil.srs.infradead.org Wed Dec 1 07:03:21 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB1D3LIk209024 for ; Wed, 1 Dec 2010 07:03:21 -0600 X-ASG-Debug-ID: 1291208705-643102040000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3D92C1C8695E for ; Wed, 1 Dec 2010 05:05:05 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 6so5STpUVC4BwNKR for ; Wed, 01 Dec 2010 05:05:05 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PNmMq-0005WZ-PB; Wed, 01 Dec 2010 13:05:04 +0000 Date: Wed, 1 Dec 2010 08:05:04 -0500 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 03/14] xfs: convert log grant heads to LSN notation Subject: Re: [PATCH 03/14] xfs: convert log grant heads to LSN notation Message-ID: <20101201130504.GA18379@infradead.org> References: <1290994712-21376-1-git-send-email-david@fromorbit.com> <1290994712-21376-4-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1290994712-21376-4-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291208705 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean > -STATIC int xlog_space_left(xlog_t *log, int cycle, int bytes); > +STATIC int xlog_space_left(int logsize, xfs_lsn_t tail_lsn, > + xfs_lsn_t head); Looking further through the series I have to say I really hate passing in the logsize instead of the log structure. Passing the log pointer from higher level functions just makes a lot more sense. Also in this case passing the tail_lsn explicitly doesn't make any sense - it becomes atomic later and thus there is no locking requirement for it. > -xlog_grant_sub_space(struct log *log, int bytes) > +__xlog_grant_sub_space( > + xfs_lsn_t *head, > + int bytes, > + int logsize) Same thing here - the calling convention would be a lot more regular by still passing the log as first argument. After the factoring I also think we could cut down on the amount of wrappers in this area. Just rename __xlog_grant_sub_space and __xlog_grant_add_space to not have the __ prefix, and kill the wrappers around it - they only have one or two callers, and just having two helpers and passing the heads we're interested in is a lot simpler and cleaner. From BATV+3217d6c06e4d83826047+2656+infradead.org+hch@bombadil.srs.infradead.org Wed Dec 1 07:10:25 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_00,SUBJ_TICKET autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB1DAPuD209478 for ; Wed, 1 Dec 2010 07:10:25 -0600 X-ASG-Debug-ID: 1291209129-406703180000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 44C391BA3EC for ; Wed, 1 Dec 2010 05:12:09 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id q64kedN01J7Mzlkm for ; Wed, 01 Dec 2010 05:12:09 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PNmTg-0006aZ-Sr; Wed, 01 Dec 2010 13:12:08 +0000 Date: Wed, 1 Dec 2010 08:12:08 -0500 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 09/14] xfs: introduce new locks for the log grant ticket wait queues Subject: Re: [PATCH 09/14] xfs: introduce new locks for the log grant ticket wait queues Message-ID: <20101201131208.GA22455@infradead.org> References: <1290994712-21376-1-git-send-email-david@fromorbit.com> <1290994712-21376-10-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1290994712-21376-10-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291209129 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean > + /* co-ordinate with xfs_log_force_shutdown */ > + if (XLOG_FORCED_SHUTDOWN(log)) { > + spin_unlock(&log->l_grant_reserve_lock); > + goto error_return; > + } Where is this coming from? Otherwise the patch looks good to me. From BATV+3217d6c06e4d83826047+2656+infradead.org+hch@bombadil.srs.infradead.org Wed Dec 1 07:13:30 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB1DDUNu209979 for ; Wed, 1 Dec 2010 07:13:30 -0600 X-ASG-Debug-ID: 1291209313-406e031d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C2A491BA432 for ; Wed, 1 Dec 2010 05:15:13 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id lDIHVfukgERkqxYG for ; Wed, 01 Dec 2010 05:15:13 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PNmWf-0007XD-BO; Wed, 01 Dec 2010 13:15:13 +0000 Date: Wed, 1 Dec 2010 08:15:13 -0500 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 10/14] xfs: convert grant head manipulations to lockless algorithm Subject: Re: [PATCH 10/14] xfs: convert grant head manipulations to lockless algorithm Message-ID: <20101201131513.GB22455@infradead.org> References: <1290994712-21376-1-git-send-email-david@fromorbit.com> <1290994712-21376-11-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1290994712-21376-11-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291209313 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mon, Nov 29, 2010 at 12:38:28PM +1100, Dave Chinner wrote: > From: Dave Chinner > > The only thing that the grant lock remains to protect is the grant head > manipulations when adding or removing space from the log. These calculations > are already based on atomic variables, so we can already update them safely > without locks. However, the grant head manpulations require atomic multi-step > calculations to be executed, which the algorithms currently don't allow. > > To make these multi-step calculations atomic, convert the algorithms to > compare-and-exchange loops on the atomic variables. That is, we sample the old > value, perform the calculation and use atomic64_cmpxchg() to attempt to update > the head with the new value. If the head has not changed since we sampled it, > it will succeed and we are done. Otherwise, we rerun the calculation again from > a new sample of the head. > > This allows us to remove the grant lock from around all the grant head space > manipulations, and that effectively removes the grant lock from the log > completely. > > Signed-off-by: Dave Chinner > --- > fs/xfs/xfs_log.c | 133 ++++++++++++++++++++++++++++++------------------------ > 1 files changed, 74 insertions(+), 59 deletions(-) > > diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c > index 8365496..50cf6af 100644 > --- a/fs/xfs/xfs_log.c > +++ b/fs/xfs/xfs_log.c > @@ -111,6 +111,13 @@ STATIC int xlog_iclogs_empty(xlog_t *log); > * is the byte offset into the log for the marker. Unlike the xfs_lsn_t, this > * is held in bytes rather than basic blocks, even though it uses the > * BLOCK_LSN() macro to extract it. > + * > + * We use a lock-free compare and exchange algorithm to atomically update > + * the grant head. That is, we sample the current head, crack it, perform the > + * calculation, recombine it into a new value, and then conditionally set the > + * value back into the atomic variable only if it hasn't changed since we first > + * sampled it. This provides atomic updates of the head, even though we do > + * non-atomic, multi-step calculation to arrive at the new value. > */ > static void > __xlog_grant_sub_space( > @@ -119,16 +126,23 @@ __xlog_grant_sub_space( > int logsize) > { > xfs_lsn_t head_lsn = atomic64_read(head); > - int cycle, space; > + xfs_lsn_t old, new; > > - cycle = CYCLE_LSN(head_lsn); > - space = BLOCK_LSN(head_lsn); > - space -= bytes; > - if (space < 0) { > - cycle--; > - space += logsize; > - } > - atomic64_set(head, xlog_assign_lsn(cycle, space)); > + do { > + int cycle, space; > + > + cycle = CYCLE_LSN(head_lsn); > + space = BLOCK_LSN(head_lsn); > + space -= bytes; > + if (space < 0) { > + cycle--; > + space += logsize; > + } > + > + old = head_lsn; > + new = xlog_assign_lsn(cycle, space); > + head_lsn = atomic64_cmpxchg(head, old, new); > + } while (head_lsn != old); > } > > static void > @@ -138,18 +152,25 @@ __xlog_grant_add_space( > int logsize) > { > xfs_lsn_t head_lsn = atomic64_read(head); > - int cycle, space, tmp; > + xfs_lsn_t old, new; > > - cycle = CYCLE_LSN(head_lsn); > - space = BLOCK_LSN(head_lsn); > - tmp = logsize - space; > - if (tmp > bytes) > - space += bytes; > - else { > - cycle++; > - space = bytes - tmp; > - } > - atomic64_set(head, xlog_assign_lsn(cycle, space)); > + do { > + int cycle, space, tmp; > + > + cycle = CYCLE_LSN(head_lsn); > + space = BLOCK_LSN(head_lsn); > + tmp = logsize - space; > + if (tmp > bytes) > + space += bytes; > + else { > + cycle++; > + space = bytes - tmp; > + } > + > + old = head_lsn; > + new = xlog_assign_lsn(cycle, space); > + head_lsn = atomic64_cmpxchg(head, old, new); > + } while (head_lsn != old); > } > > static inline void > @@ -360,11 +381,9 @@ xfs_log_reserve( > > trace_xfs_log_reserve(log, internal_ticket); > > - spin_lock(&log->l_grant_lock); > xlog_grant_push_ail(log, atomic64_read(&log->l_tail_lsn), > atomic64_read(&log->l_last_sync_lsn), > internal_ticket->t_unit_res); > - spin_unlock(&log->l_grant_lock); > retval = xlog_regrant_write_log_space(log, internal_ticket); > } else { > /* may sleep if need to allocate more tickets */ > @@ -378,12 +397,10 @@ xfs_log_reserve( > > trace_xfs_log_reserve(log, internal_ticket); > > - spin_lock(&log->l_grant_lock); > xlog_grant_push_ail(log, atomic64_read(&log->l_tail_lsn), > atomic64_read(&log->l_last_sync_lsn), > (internal_ticket->t_unit_res * > internal_ticket->t_cnt)); > - spin_unlock(&log->l_grant_lock); > retval = xlog_grant_log_space(log, internal_ticket); > } > > @@ -1376,9 +1393,7 @@ xlog_sync(xlog_t *log, > roundoff < BBTOB(1))); > > /* move grant heads by roundoff in sync */ > - spin_lock(&log->l_grant_lock); > xlog_grant_add_space(log, roundoff); > - spin_unlock(&log->l_grant_lock); > > /* put cycle number in every block */ > xlog_pack_data(log, iclog, roundoff); > @@ -2618,13 +2633,11 @@ redo: > } > > /* we've got enough space */ > - spin_lock(&log->l_grant_lock); > xlog_grant_add_space(log, need_bytes); > > trace_xfs_log_grant_exit(log, tic); > xlog_verify_grant_tail(log); > xlog_verify_grant_head(log, 1); > - spin_unlock(&log->l_grant_lock); > return 0; > > error_return: > @@ -2752,13 +2765,11 @@ redo: > } > > /* we've got enough space */ > - spin_lock(&log->l_grant_lock); > xlog_grant_add_space_write(log, need_bytes); > > trace_xfs_log_regrant_write_exit(log, tic); > xlog_verify_grant_tail(log); > xlog_verify_grant_head(log, 1); > - spin_unlock(&log->l_grant_lock); > return 0; > > > @@ -2779,23 +2790,23 @@ redo: > } > > > -/* The first cnt-1 times through here we don't need to > - * move the grant write head because the permanent > - * reservation has reserved cnt times the unit amount. > - * Release part of current permanent unit reservation and > - * reset current reservation to be one units worth. Also > - * move grant reservation head forward. > +/* > + * The first cnt-1 times through here we don't need to move the grant write > + * head because the permanent reservation has reserved cnt times the unit > + * amount. Release part of current permanent unit reservation and reset > + * current reservation to be one units worth. Also move grant reservation head > + * forward. > */ > STATIC void > -xlog_regrant_reserve_log_space(xlog_t *log, > - xlog_ticket_t *ticket) > +xlog_regrant_reserve_log_space( > + struct log *log, > + struct xlog_ticket *ticket) > { > trace_xfs_log_regrant_reserve_enter(log, ticket); > > if (ticket->t_cnt > 0) > ticket->t_cnt--; > > - spin_lock(&log->l_grant_lock); > xlog_grant_sub_space(log, ticket->t_curr_res); > ticket->t_curr_res = ticket->t_unit_res; > xlog_tic_reset_res(ticket); > @@ -2805,20 +2816,17 @@ xlog_regrant_reserve_log_space(xlog_t *log, > xlog_verify_grant_head(log, 1); > > /* just return if we still have some of the pre-reserved space */ > - if (ticket->t_cnt > 0) { > - spin_unlock(&log->l_grant_lock); > + if (ticket->t_cnt > 0) > return; > - } > > xlog_grant_add_space_reserve(log, ticket->t_unit_res); > > trace_xfs_log_regrant_reserve_exit(log, ticket); > > xlog_verify_grant_head(log, 0); > - spin_unlock(&log->l_grant_lock); > ticket->t_curr_res = ticket->t_unit_res; > xlog_tic_reset_res(ticket); > -} /* xlog_regrant_reserve_log_space */ > +} > > > /* > @@ -2836,34 +2844,33 @@ xlog_regrant_reserve_log_space(xlog_t *log, > * in the current reservation field. > */ > STATIC void > -xlog_ungrant_log_space(xlog_t *log, > - xlog_ticket_t *ticket) > +xlog_ungrant_log_space( > + struct log *log, > + struct xlog_ticket *ticket) > { > - if (ticket->t_cnt > 0) > - ticket->t_cnt--; > + int space; > > - spin_lock(&log->l_grant_lock); > trace_xfs_log_ungrant_enter(log, ticket); > + if (ticket->t_cnt > 0) > + ticket->t_cnt--; > > - xlog_grant_sub_space(log, ticket->t_curr_res); > - > - trace_xfs_log_ungrant_sub(log, ticket); > - > - /* If this is a permanent reservation ticket, we may be able to free > + /* > + * If this is a permanent reservation ticket, we may be able to free > * up more space based on the remaining count. > */ > + space = ticket->t_curr_res; > if (ticket->t_cnt > 0) { > ASSERT(ticket->t_flags & XLOG_TIC_PERM_RESERV); > - xlog_grant_sub_space(log, ticket->t_unit_res*ticket->t_cnt); > + space += ticket->t_unit_res * ticket->t_cnt; > } > + trace_xfs_log_ungrant_sub(log, ticket); > + xlog_grant_sub_space(log, space); > > trace_xfs_log_ungrant_exit(log, ticket); > - > xlog_verify_grant_head(log, 1); > - spin_unlock(&log->l_grant_lock); > - xfs_log_move_tail(log->l_mp, 1); > -} /* xlog_ungrant_log_space */ > > + xfs_log_move_tail(log->l_mp, 1); > +} > > /* > * Flush iclog to disk if this is the last reference to the given iclog and > @@ -3478,11 +3485,18 @@ xlog_verify_dest_ptr( > xlog_panic("xlog_verify_dest_ptr: invalid ptr"); > } > > +/* > + * XXX: because we cannot atomically sample both the reserve and write heads, > + * we cannot verify them reliably as they may be sampled in the middle of > + * racing modifications. Hence just taking snapshots of the heads can give an > + * incorrect view of the state of log. Hence just disable this check for now. > + */ > STATIC void > xlog_verify_grant_head( I can't see any way to keep this check with the atomic reserve/write heads, so we might as well remove it entirely. Otherwise the patch looks good, Reviewed-by: Christoph Hellwig From BATV+3217d6c06e4d83826047+2656+infradead.org+hch@bombadil.srs.infradead.org Wed Dec 1 07:13:52 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB1DDqo3210027 for ; Wed, 1 Dec 2010 07:13:52 -0600 X-ASG-Debug-ID: 1291209336-6d0001a00000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 58D331C869F1 for ; Wed, 1 Dec 2010 05:15:36 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id S7zSNh5l0XEAoBAF for ; Wed, 01 Dec 2010 05:15:36 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PNmX1-0007Y0-Ve; Wed, 01 Dec 2010 13:15:36 +0000 Date: Wed, 1 Dec 2010 08:15:35 -0500 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 11/14] xfs: remove log grant lock Subject: Re: [PATCH 11/14] xfs: remove log grant lock Message-ID: <20101201131535.GC22455@infradead.org> References: <1290994712-21376-1-git-send-email-david@fromorbit.com> <1290994712-21376-12-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1290994712-21376-12-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291209336 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mon, Nov 29, 2010 at 12:38:29PM +1100, Dave Chinner wrote: > From: Dave Chinner > > The log grant lock no longer protects anything, so remove the remaining > initialisation and teardown code that still exists. Looks good, although I would fold it into the previous patch. Reviewed-by: Christoph Hellwig From BATV+3217d6c06e4d83826047+2656+infradead.org+hch@bombadil.srs.infradead.org Wed Dec 1 07:17:25 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB1DHOo0210298 for ; Wed, 1 Dec 2010 07:17:25 -0600 X-ASG-Debug-ID: 1291209548-6d1b01ab0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 72EBD1C86806 for ; Wed, 1 Dec 2010 05:19:08 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id Q1vZbIKBGpPtOIVN for ; Wed, 01 Dec 2010 05:19:08 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PNmaS-0007ui-0p; Wed, 01 Dec 2010 13:19:08 +0000 Date: Wed, 1 Dec 2010 08:19:08 -0500 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 12/14] xfs: kill useless spinlock_destroy macro Subject: Re: [PATCH 12/14] xfs: kill useless spinlock_destroy macro Message-ID: <20101201131907.GD22455@infradead.org> References: <1290994712-21376-1-git-send-email-david@fromorbit.com> <1290994712-21376-13-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1290994712-21376-13-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291209548 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mon, Nov 29, 2010 at 12:38:30PM +1100, Dave Chinner wrote: > From: Dave Chinner > > It is only used in 2 places in the log code, and is an empty macro, > so get rid of it. yeah, time to kill it. Reviewed-by: Christoph Hellwig From BATV+3217d6c06e4d83826047+2656+infradead.org+hch@bombadil.srs.infradead.org Wed Dec 1 07:18:23 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB1DINuJ210361 for ; Wed, 1 Dec 2010 07:18:23 -0600 X-ASG-Debug-ID: 1291209606-21fa002b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 282551404539 for ; Wed, 1 Dec 2010 05:20:06 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 21ms22AqSnJd31Es for ; Wed, 01 Dec 2010 05:20:06 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PNmbO-00006c-FJ; Wed, 01 Dec 2010 13:20:06 +0000 Date: Wed, 1 Dec 2010 08:20:06 -0500 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 13/14] xfs: replace use of sv_t with waitqueues in the log Subject: Re: [PATCH 13/14] xfs: replace use of sv_t with waitqueues in the log Message-ID: <20101201132006.GE22455@infradead.org> References: <1290994712-21376-1-git-send-email-david@fromorbit.com> <1290994712-21376-14-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1290994712-21376-14-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291209607 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mon, Nov 29, 2010 at 12:38:31PM +1100, Dave Chinner wrote: > From: Dave Chinner > > Only the log still uses the old Irix wait queue interface. The log > grant lock scaling series killed one of the users, so convert > the remaining users of sv_t to plain wait queues so the sv_t wrapper can > be removed. Looks good, but as said before I'd prefer it to be merged with the introduction of xlog_wait and the first sv_t removal. Reviewed-by: Christoph Hellwig From BATV+3217d6c06e4d83826047+2656+infradead.org+hch@bombadil.srs.infradead.org Wed Dec 1 07:18:47 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB1DIlWX210409 for ; Wed, 1 Dec 2010 07:18:47 -0600 X-ASG-Debug-ID: 1291209630-457f02ea0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C7FB31B9FF8 for ; Wed, 1 Dec 2010 05:20:30 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id riqg9mCF0KoDhXhx for ; Wed, 01 Dec 2010 05:20:30 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PNmbm-00007D-Bx; Wed, 01 Dec 2010 13:20:30 +0000 Date: Wed, 1 Dec 2010 08:20:30 -0500 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 14/14] xfs: remove sv wrappers Subject: Re: [PATCH 14/14] xfs: remove sv wrappers Message-ID: <20101201132030.GF22455@infradead.org> References: <1290994712-21376-1-git-send-email-david@fromorbit.com> <1290994712-21376-15-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1290994712-21376-15-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291209630 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mon, Nov 29, 2010 at 12:38:32PM +1100, Dave Chinner wrote: > From: Dave Chinner > > The sv_t type is no longer used in XFS. Remove the header file defining the > wrapper and the fragments that still reference it. Looks good, although I'd suggest merging it into the previous patch. Reviewed-by: Christoph Hellwig From sandeen@sandeen.net Wed Dec 1 08:53:23 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB1ErMMD217074 for ; Wed, 1 Dec 2010 08:53:23 -0600 X-ASG-Debug-ID: 1291215304-21fa02150000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id F22CB16071C5 for ; Wed, 1 Dec 2010 06:55:04 -0800 (PST) Received: from mail.sandeen.net (64-131-28-21.usfamily.net [64.131.28.21]) by cuda.sgi.com with ESMTP id 9kPCTeEBnCjprria for ; Wed, 01 Dec 2010 06:55:04 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sandeen.net (Postfix) with ESMTP id 1EA054817D73; Wed, 1 Dec 2010 08:55:04 -0600 (CST) Message-ID: <4CF661C7.2020103@sandeen.net> Date: Wed, 01 Dec 2010 08:55:03 -0600 From: Eric Sandeen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Amit Sahrawat CC: xfs@oss.sgi.com, sandeen-xfs@sandeen.net X-ASG-Orig-Subj: Re: XFS file system corruption(Return Bad Transaction) kernel - 2.6.34 Subject: Re: XFS file system corruption(Return Bad Transaction) kernel - 2.6.34 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: 64-131-28-21.usfamily.net[64.131.28.21] X-Barracuda-Start-Time: 1291215305 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48174 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 12/1/10 1:14 AM, Amit Sahrawat wrote: > Dear Member, > > I am getting following corruption on XFS formatted disk during a simple copy operation: > sd 9:0:0:0: Attached scsi removable disk sdc > sd 9:0:0:0: Attached scsi generic sg2 type 0 > XFS mounting filesystem sdc2 > Starting XFS recovery on filesystem: sdc2 (logdev: internal) > XFS: xlog_recover_process_data: bad transaction > XFS: log mount/recovery failed: error 5 > XFS: log mount failed hm, that's not a simple copy operation, that is a mount failing; your log appears to be corrupted. offhand I'm going to blame it on having a write cache enabled on your drive, and having barriers either off, or not working properly. -Eric From aelder@sgi.com Wed Dec 1 14:28:36 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from relay.sgi.com (relay1.corp.sgi.com [137.38.102.111]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB1KSaFd232389 for ; Wed, 1 Dec 2010 14:28:36 -0600 Received: from cf--amer001e--3.americas.sgi.com (cf--amer001e--3.americas.sgi.com [137.38.100.5]) by relay1.corp.sgi.com (Postfix) with ESMTP id E9D858F8094; Wed, 1 Dec 2010 12:30:16 -0800 (PST) Received: from [127.0.0.1] ([198.149.20.12]) by cf--amer001e--3.americas.sgi.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Dec 2010 14:29:40 -0600 Subject: xfstests 065 failures From: Alex Elder Reply-To: aelder@sgi.com To: dchinner@redhat.com Cc: Bill Kendall , XFS Mailing List Content-Type: text/plain; charset="UTF-8" Date: Wed, 01 Dec 2010 14:29:39 -0600 Message-ID: <1291235379.2556.28.camel@doink> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Dec 2010 20:29:40.0145 (UTC) FILETIME=[7ACB3210:01CB9196] X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Dave, you were asking on IRC about test 065 failures. I asked Bill Kendall about it and he bisected to find that the commit below seems to be where the problems started. I believe the problem is that one of the times is not updated properly when renaming the file "addedfile4". Here are the commands that might affect that file in test 065: mv addeddir4/addedfile5 addeddir4/addedfile4 mv addeddir4 addeddir6 I glanced at the commit and saw nothing obviously wrong, but at the moment I can't really dig into it any deeper so I thought I'd report what Bill found so others could look. -Alex >From dcd79a1423f64ee0184629874805c3ac40f3a2c5 Mon Sep 17 00:00:00 2001 From: Dave Chinner Date: Tue, 28 Sep 2010 12:27:25 +1000 Subject: [PATCH] xfs: don't use vfs writeback for pure metadata modifications Under heavy multi-way parallel create workloads, the VFS struggles to write back all the inodes that have been changed in age order. The bdi flusher thread becomes CPU bound, spending 85% of it's time in the VFS code, mostly traversing the superblock dirty inode list to separate dirty inodes old enough to flush. We already keep an index of all metadata changes in age order - in the AIL - and continued log pressure will do age ordered writeback without any extra overhead at all. If there is no pressure on the log, the xfssyncd will periodically write back metadata in ascending disk address offset order so will be very efficient. Hence we can stop marking VFS inodes dirty during transaction commit or when changing timestamps during transactions. This will keep the inodes in the superblock dirty list to those containing data or unlogged metadata changes. However, the timstamp changes are slightly more complex than this - there are a couple of places that do unlogged updates of the timestamps, and the VFS need to be informed of these. Hence add a new function xfs_trans_ichgtime() for transactional changes, and leave xfs_ichgtime() for the non-transactional changes. Signed-off-by: Dave Chinner Reviewed-by: Alex Elder Reviewed-by: Christoph Hellwig From aelder@oss.sgi.com Wed Dec 1 14:54:03 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB1Ks3DV233550 for ; Wed, 1 Dec 2010 14:54:03 -0600 Received: (from aelder@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id oB1Ks0NA233500; Wed, 1 Dec 2010 14:54:00 -0600 Date: Wed, 1 Dec 2010 14:54:00 -0600 Message-Id: <201012012054.oB1Ks0NA233500@oss.sgi.com> From: xfs@oss.sgi.com To: xfs@oss.sgi.com Subject: [XFS updates] XFS development tree branch, master, updated. v2.6.36-rc8-11223-gc76febe X-Git-Refname: refs/heads/master X-Git-Reftype: branch X-Git-Oldrev: ece413f59f257682de4a2e2e42af33b016af53f3 X-Git-Newrev: c76febef574fd86566bbdf1a73a547a439115c25 This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "XFS development tree". The branch, master has been updated c76febe xfs: only run xfs_error_test if error injection is active de25c18 xfs: avoid moving stale inodes in the AIL 309c848 xfs: delayed alloc blocks beyond EOF are valid after writeback 90810b9 xfs: push stale, pinned buffers on trylock failures c726de4 xfs: fix failed write truncation handling. from ece413f59f257682de4a2e2e42af33b016af53f3 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit c76febef574fd86566bbdf1a73a547a439115c25 Author: Dave Chinner Date: Tue Nov 30 15:15:31 2010 +1100 xfs: only run xfs_error_test if error injection is active Recent tests writing lots of small files showed the flusher thread being CPU bound and taking a long time to do allocations on a debug kernel. perf showed this as the prime reason: samples pcnt function DSO _______ _____ ___________________________ _________________ 224648.00 36.8% xfs_error_test [kernel.kallsyms] 86045.00 14.1% xfs_btree_check_sblock [kernel.kallsyms] 39778.00 6.5% prandom32 [kernel.kallsyms] 37436.00 6.1% xfs_btree_increment [kernel.kallsyms] 29278.00 4.8% xfs_btree_get_rec [kernel.kallsyms] 27717.00 4.5% random32 [kernel.kallsyms] Walking btree blocks during allocation checking them requires each block (a cache hit, so no I/O) call xfs_error_test(), which then does a random32() call as the first operation. IOWs, ~50% of the CPU is being consumed just testing whether we need to inject an error, even though error injection is not active. Kill this overhead when error injection is not active by adding a global counter of active error traps and only calling into xfs_error_test when fault injection is active. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig commit de25c1818c44f580ff556cb9e0f7a1c687ed870b Author: Dave Chinner Date: Tue Nov 30 15:15:46 2010 +1100 xfs: avoid moving stale inodes in the AIL When an inode has been marked stale because the cluster is being freed, we don't want to (re-)insert this inode into the AIL. There is a race condition where the cluster buffer may be unpinned before the inode is inserted into the AIL during transaction committed processing. If the buffer is unpinned before the inode item has been committed and inserted, then it is possible for the buffer to be released and hence processthe stale inode callbacks before the inode is inserted into the AIL. In this case, we then insert a clean, stale inode into the AIL which will never get removed by an IO completion. It will, however, get reclaimed and that triggers an assert in xfs_inode_free() complaining about freeing an inode still in the AIL. This race can be avoided by not moving stale inodes forward in the AIL during transaction commit completion processing. This closes the race condition by ensuring we never insert clean stale inodes into the AIL. It is safe to do this because a dirty stale inode, by definition, must already be in the AIL. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig commit 309c848002052edbec650075a1eb098b17c17f35 Author: Dave Chinner Date: Tue Nov 30 15:16:02 2010 +1100 xfs: delayed alloc blocks beyond EOF are valid after writeback There is an assumption in the parts of XFS that flushing a dirty file will make all the delayed allocation blocks disappear from an inode. That is, that after calling xfs_flush_pages() then ip->i_delayed_blks will be zero. This is an invalid assumption as we may have specualtive preallocation beyond EOF and they are recorded in ip->i_delayed_blks. A flush of the dirty pages of an inode will not change the state of these blocks beyond EOF, so a non-zero deeelalloc block count after a flush is valid. The bmap code has an invalid ASSERT() that needs to be removed, and the swapext code has a bug in that while it swaps the data forks around, it fails to swap the i_delayed_blks counter associated with the fork and hence can get the block accounting wrong. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig commit 90810b9e82a36c3c57c1aeb8b2918b242a130b26 Author: Dave Chinner Date: Tue Nov 30 15:16:16 2010 +1100 xfs: push stale, pinned buffers on trylock failures As reported by Nick Piggin, XFS is suffering from long pauses under highly concurrent workloads when hosted on ramdisks. The problem is that an inode buffer is stuck in the pinned state in memory and as a result either the inode buffer or one of the inodes within the buffer is stopping the tail of the log from being moved forward. The system remains in this state until a periodic log force issued by xfssyncd causes the buffer to be unpinned. The main problem is that these are stale buffers, and are hence held locked until the transaction/checkpoint that marked them state has been committed to disk. When the filesystem gets into this state, only the xfssyncd can cause the async transactions to be committed to disk and hence unpin the inode buffer. This problem was encountered when scaling the busy extent list, but only the blocking lock interface was fixed to solve the problem. Extend the same fix to the buffer trylock operations - if we fail to lock a pinned, stale buffer, then force the log immediately so that when the next attempt to lock it comes around, it will have been unpinned. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig commit c726de4409a8d3a03877b1ef4342bfe8a15f5e5e Author: Dave Chinner Date: Tue Nov 30 15:14:39 2010 +1100 xfs: fix failed write truncation handling. Since the move to the new truncate sequence we call xfs_setattr to truncate down excessively instanciated blocks. As shown by the testcase in kernel.org BZ #22452 that doesn't work too well. Due to the confusion of the internal inode size, and the VFS inode i_size it zeroes data that it shouldn't. But full blown truncate seems like overkill here. We only instanciate delayed allocations in the write path, and given that we never released the iolock we can't have converted them to real allocations yet either. The only nasty case is pre-existing preallocation which we need to skip. We already do this for page discard during writeback, so make the delayed allocation block punching a generic function and call it from the failed write path as well as xfs_aops_discard_page. The callers are responsible for ensuring that partial blocks are not truncated away, and that they hold the ilock. Based on a fix originally from Christoph Hellwig. This version used filesystem blocks as the range unit. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig ----------------------------------------------------------------------- Summary of changes: fs/xfs/linux-2.6/xfs_aops.c | 94 ++++++++++++++++++------------------------ fs/xfs/linux-2.6/xfs_buf.c | 35 +++++++--------- fs/xfs/xfs_bmap.c | 85 ++++++++++++++++++++++++++++++++++++++- fs/xfs/xfs_bmap.h | 5 ++ fs/xfs/xfs_dfrag.c | 13 ++++++ fs/xfs/xfs_error.c | 3 + fs/xfs/xfs_error.h | 5 +- fs/xfs/xfs_inode_item.c | 31 +++++++++++--- 8 files changed, 188 insertions(+), 83 deletions(-) hooks/post-receive -- XFS development tree From aelder@oss.sgi.com Wed Dec 1 14:54:11 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB1KsBnB233672 for ; Wed, 1 Dec 2010 14:54:11 -0600 Received: (from aelder@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id oB1Ks9h4233622; Wed, 1 Dec 2010 14:54:09 -0600 Date: Wed, 1 Dec 2010 14:54:09 -0600 Message-Id: <201012012054.oB1Ks9h4233622@oss.sgi.com> From: xfs@oss.sgi.com To: xfs@oss.sgi.com Subject: [XFS updates] XFS development tree branch, for-linus, updated. v2.6.36-rc8-11223-gc76febe X-Git-Refname: refs/heads/for-linus X-Git-Reftype: branch X-Git-Oldrev: ece413f59f257682de4a2e2e42af33b016af53f3 X-Git-Newrev: c76febef574fd86566bbdf1a73a547a439115c25 This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "XFS development tree". The branch, for-linus has been updated c76febe xfs: only run xfs_error_test if error injection is active de25c18 xfs: avoid moving stale inodes in the AIL 309c848 xfs: delayed alloc blocks beyond EOF are valid after writeback 90810b9 xfs: push stale, pinned buffers on trylock failures c726de4 xfs: fix failed write truncation handling. from ece413f59f257682de4a2e2e42af33b016af53f3 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit c76febef574fd86566bbdf1a73a547a439115c25 Author: Dave Chinner Date: Tue Nov 30 15:15:31 2010 +1100 xfs: only run xfs_error_test if error injection is active Recent tests writing lots of small files showed the flusher thread being CPU bound and taking a long time to do allocations on a debug kernel. perf showed this as the prime reason: samples pcnt function DSO _______ _____ ___________________________ _________________ 224648.00 36.8% xfs_error_test [kernel.kallsyms] 86045.00 14.1% xfs_btree_check_sblock [kernel.kallsyms] 39778.00 6.5% prandom32 [kernel.kallsyms] 37436.00 6.1% xfs_btree_increment [kernel.kallsyms] 29278.00 4.8% xfs_btree_get_rec [kernel.kallsyms] 27717.00 4.5% random32 [kernel.kallsyms] Walking btree blocks during allocation checking them requires each block (a cache hit, so no I/O) call xfs_error_test(), which then does a random32() call as the first operation. IOWs, ~50% of the CPU is being consumed just testing whether we need to inject an error, even though error injection is not active. Kill this overhead when error injection is not active by adding a global counter of active error traps and only calling into xfs_error_test when fault injection is active. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig commit de25c1818c44f580ff556cb9e0f7a1c687ed870b Author: Dave Chinner Date: Tue Nov 30 15:15:46 2010 +1100 xfs: avoid moving stale inodes in the AIL When an inode has been marked stale because the cluster is being freed, we don't want to (re-)insert this inode into the AIL. There is a race condition where the cluster buffer may be unpinned before the inode is inserted into the AIL during transaction committed processing. If the buffer is unpinned before the inode item has been committed and inserted, then it is possible for the buffer to be released and hence processthe stale inode callbacks before the inode is inserted into the AIL. In this case, we then insert a clean, stale inode into the AIL which will never get removed by an IO completion. It will, however, get reclaimed and that triggers an assert in xfs_inode_free() complaining about freeing an inode still in the AIL. This race can be avoided by not moving stale inodes forward in the AIL during transaction commit completion processing. This closes the race condition by ensuring we never insert clean stale inodes into the AIL. It is safe to do this because a dirty stale inode, by definition, must already be in the AIL. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig commit 309c848002052edbec650075a1eb098b17c17f35 Author: Dave Chinner Date: Tue Nov 30 15:16:02 2010 +1100 xfs: delayed alloc blocks beyond EOF are valid after writeback There is an assumption in the parts of XFS that flushing a dirty file will make all the delayed allocation blocks disappear from an inode. That is, that after calling xfs_flush_pages() then ip->i_delayed_blks will be zero. This is an invalid assumption as we may have specualtive preallocation beyond EOF and they are recorded in ip->i_delayed_blks. A flush of the dirty pages of an inode will not change the state of these blocks beyond EOF, so a non-zero deeelalloc block count after a flush is valid. The bmap code has an invalid ASSERT() that needs to be removed, and the swapext code has a bug in that while it swaps the data forks around, it fails to swap the i_delayed_blks counter associated with the fork and hence can get the block accounting wrong. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig commit 90810b9e82a36c3c57c1aeb8b2918b242a130b26 Author: Dave Chinner Date: Tue Nov 30 15:16:16 2010 +1100 xfs: push stale, pinned buffers on trylock failures As reported by Nick Piggin, XFS is suffering from long pauses under highly concurrent workloads when hosted on ramdisks. The problem is that an inode buffer is stuck in the pinned state in memory and as a result either the inode buffer or one of the inodes within the buffer is stopping the tail of the log from being moved forward. The system remains in this state until a periodic log force issued by xfssyncd causes the buffer to be unpinned. The main problem is that these are stale buffers, and are hence held locked until the transaction/checkpoint that marked them state has been committed to disk. When the filesystem gets into this state, only the xfssyncd can cause the async transactions to be committed to disk and hence unpin the inode buffer. This problem was encountered when scaling the busy extent list, but only the blocking lock interface was fixed to solve the problem. Extend the same fix to the buffer trylock operations - if we fail to lock a pinned, stale buffer, then force the log immediately so that when the next attempt to lock it comes around, it will have been unpinned. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig commit c726de4409a8d3a03877b1ef4342bfe8a15f5e5e Author: Dave Chinner Date: Tue Nov 30 15:14:39 2010 +1100 xfs: fix failed write truncation handling. Since the move to the new truncate sequence we call xfs_setattr to truncate down excessively instanciated blocks. As shown by the testcase in kernel.org BZ #22452 that doesn't work too well. Due to the confusion of the internal inode size, and the VFS inode i_size it zeroes data that it shouldn't. But full blown truncate seems like overkill here. We only instanciate delayed allocations in the write path, and given that we never released the iolock we can't have converted them to real allocations yet either. The only nasty case is pre-existing preallocation which we need to skip. We already do this for page discard during writeback, so make the delayed allocation block punching a generic function and call it from the failed write path as well as xfs_aops_discard_page. The callers are responsible for ensuring that partial blocks are not truncated away, and that they hold the ilock. Based on a fix originally from Christoph Hellwig. This version used filesystem blocks as the range unit. Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig ----------------------------------------------------------------------- Summary of changes: fs/xfs/linux-2.6/xfs_aops.c | 94 ++++++++++++++++++------------------------ fs/xfs/linux-2.6/xfs_buf.c | 35 +++++++--------- fs/xfs/xfs_bmap.c | 85 ++++++++++++++++++++++++++++++++++++++- fs/xfs/xfs_bmap.h | 5 ++ fs/xfs/xfs_dfrag.c | 13 ++++++ fs/xfs/xfs_error.c | 3 + fs/xfs/xfs_error.h | 5 +- fs/xfs/xfs_inode_item.c | 31 +++++++++++--- 8 files changed, 188 insertions(+), 83 deletions(-) hooks/post-receive -- XFS development tree From aelder@sgi.com Wed Dec 1 16:04:29 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB1M4T16236283 for ; Wed, 1 Dec 2010 16:04:29 -0600 Received: from cf--amer001e--3.americas.sgi.com (cf--amer001e--3.americas.sgi.com [137.38.100.5]) by relay3.corp.sgi.com (Postfix) with ESMTP id 4D2F3AC006; Wed, 1 Dec 2010 14:06:10 -0800 (PST) Received: from [127.0.0.1] ([198.149.20.12]) by cf--amer001e--3.americas.sgi.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Dec 2010 16:05:59 -0600 Subject: Re: [XFS updates] XFS development tree branch, master, updated. v2.6.36-rc8-11223-gc76febe From: Alex Elder Reply-To: aelder@sgi.com To: xfs@oss.sgi.com Cc: Dave Chinner In-Reply-To: <201012012054.oB1Ks0NA233500@oss.sgi.com> References: <201012012054.oB1Ks0NA233500@oss.sgi.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 01 Dec 2010 16:05:58 -0600 Message-ID: <1291241158.2556.54.camel@doink> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Dec 2010 22:05:59.0494 (UTC) FILETIME=[EF8DDE60:01CB91A3] X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Wed, 2010-12-01 at 14:54 -0600, xfs@oss.sgi.com wrote: > This is an automated email from the git hooks/post-receive script. It was > generated because a ref change was pushed to the repository containing > the project "XFS development tree". > > The branch, master has been updated > c76febe xfs: only run xfs_error_test if error injection is active > de25c18 xfs: avoid moving stale inodes in the AIL > 309c848 xfs: delayed alloc blocks beyond EOF are valid after writeback > 90810b9 xfs: push stale, pinned buffers on trylock failures > c726de4 xfs: fix failed write truncation handling. > from ece413f59f257682de4a2e2e42af33b016af53f3 (commit) > > Those revisions listed above that are new to this repository have > not appeared on any other notification email; so we list those > revisions in full, below. . . . I have updated the XFS master branch to be based on 6.2.37-rc4. The only commits that were rebased were those I just took in from Dave Chinner's xfsdev tree, so unless you have work based on that branch you should not need to do anything special to update your local repository. -Alex From BATV+3217d6c06e4d83826047+2656+infradead.org+hch@bombadil.srs.infradead.org Wed Dec 1 16:05:30 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_65 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB1M5RAC236334 for ; Wed, 1 Dec 2010 16:05:29 -0600 X-ASG-Debug-ID: 1291241231-3479026e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A9F824F05FE for ; Wed, 1 Dec 2010 14:07:11 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id UinowJwox2Ql2NWa for ; Wed, 01 Dec 2010 14:07:11 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PNupS-0007mj-2r for xfs@oss.sgi.com; Wed, 01 Dec 2010 22:07:10 +0000 Message-Id: <20101201220710.042656730@bombadil.infradead.org> User-Agent: quilt/0.48-1 Date: Wed, 01 Dec 2010 17:06:21 -0500 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 1/4] xfs: remove leftovers of old buffer log items in recovery code Subject: [PATCH 1/4] xfs: remove leftovers of old buffer log items in recovery code References: <20101201220620.340188389@bombadil.infradead.org> Content-Disposition: inline; filename=xfs-remove-blf_type-switches X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291241231 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean XFS used to support different types of buffer log items long time ago. Remove the switch statements checking the log item type in various buffer recovery helpers that were left over from those days and the rather useless xlog_recover_do_buffer_pass2 wrapper. Signed-off-by: Christoph Hellwig Index: xfs/fs/xfs/xfs_log_recover.c =================================================================== --- xfs.orig/fs/xfs/xfs_log_recover.c 2010-11-29 15:06:43.921010269 +0100 +++ xfs/fs/xfs/xfs_log_recover.c 2010-11-29 16:33:20.495004054 +0100 @@ -1614,22 +1614,13 @@ xlog_recover_do_buffer_pass1( xfs_buf_cancel_t *nextp; xfs_buf_cancel_t *prevp; xfs_buf_cancel_t **bucket; - xfs_daddr_t blkno = 0; - uint len = 0; - ushort flags = 0; - - switch (buf_f->blf_type) { - case XFS_LI_BUF: - blkno = buf_f->blf_blkno; - len = buf_f->blf_len; - flags = buf_f->blf_flags; - break; - } + xfs_daddr_t blkno = buf_f->blf_blkno; + uint len = buf_f->blf_len; /* * If this isn't a cancel buffer item, then just return. */ - if (!(flags & XFS_BLF_CANCEL)) { + if (!(buf_f->blf_flags & XFS_BLF_CANCEL)) { trace_xfs_log_recover_buf_not_cancel(log, buf_f); return; } @@ -1767,77 +1758,38 @@ xlog_check_buffer_cancelled( return 0; } -STATIC int -xlog_recover_do_buffer_pass2( - xlog_t *log, - xfs_buf_log_format_t *buf_f) -{ - xfs_daddr_t blkno = 0; - ushort flags = 0; - uint len = 0; - - switch (buf_f->blf_type) { - case XFS_LI_BUF: - blkno = buf_f->blf_blkno; - flags = buf_f->blf_flags; - len = buf_f->blf_len; - break; - } - - return xlog_check_buffer_cancelled(log, blkno, len, flags); -} - /* - * Perform recovery for a buffer full of inodes. In these buffers, - * the only data which should be recovered is that which corresponds - * to the di_next_unlinked pointers in the on disk inode structures. - * The rest of the data for the inodes is always logged through the - * inodes themselves rather than the inode buffer and is recovered - * in xlog_recover_do_inode_trans(). + * Perform recovery for a buffer full of inodes. In these buffers, the only + * data which should be recovered is that which corresponds to the + * di_next_unlinked pointers in the on disk inode structures. The rest of the + * data for the inodes is always logged through the inodes themselves rather + * than the inode buffer and is recovered in xlog_recover_inode_pass2(). * - * The only time when buffers full of inodes are fully recovered is - * when the buffer is full of newly allocated inodes. In this case - * the buffer will not be marked as an inode buffer and so will be - * sent to xlog_recover_do_reg_buffer() below during recovery. + * The only time when buffers full of inodes are fully recovered is when the + * buffer is full of newly allocated inodes. In this case the buffer will + * not be marked as an inode buffer and so will be sent to + * xlog_recover_do_reg_buffer() below during recovery. */ STATIC int xlog_recover_do_inode_buffer( - xfs_mount_t *mp, + struct xfs_mount *mp, xlog_recover_item_t *item, - xfs_buf_t *bp, + struct xfs_buf *bp, xfs_buf_log_format_t *buf_f) { int i; - int item_index; - int bit; - int nbits; - int reg_buf_offset; - int reg_buf_bytes; + int item_index = 0; + int bit = 0; + int nbits = 0; + int reg_buf_offset = 0; + int reg_buf_bytes = 0; int next_unlinked_offset; int inodes_per_buf; xfs_agino_t *logged_nextp; xfs_agino_t *buffer_nextp; - unsigned int *data_map = NULL; - unsigned int map_size = 0; trace_xfs_log_recover_buf_inode_buf(mp->m_log, buf_f); - switch (buf_f->blf_type) { - case XFS_LI_BUF: - data_map = buf_f->blf_data_map; - map_size = buf_f->blf_map_size; - break; - } - /* - * Set the variables corresponding to the current region to - * 0 so that we'll initialize them on the first pass through - * the loop. - */ - reg_buf_offset = 0; - reg_buf_bytes = 0; - bit = 0; - nbits = 0; - item_index = 0; inodes_per_buf = XFS_BUF_COUNT(bp) >> mp->m_sb.sb_inodelog; for (i = 0; i < inodes_per_buf; i++) { next_unlinked_offset = (i * mp->m_sb.sb_inodesize) + @@ -1852,18 +1804,18 @@ xlog_recover_do_inode_buffer( * the current di_next_unlinked field. */ bit += nbits; - bit = xfs_next_bit(data_map, map_size, bit); + bit = xfs_next_bit(buf_f->blf_data_map, + buf_f->blf_map_size, bit); /* * If there are no more logged regions in the * buffer, then we're done. */ - if (bit == -1) { + if (bit == -1) return 0; - } - nbits = xfs_contig_bits(data_map, map_size, - bit); + nbits = xfs_contig_bits(buf_f->blf_data_map, + buf_f->blf_map_size, bit); ASSERT(nbits > 0); reg_buf_offset = bit << XFS_BLF_SHIFT; reg_buf_bytes = nbits << XFS_BLF_SHIFT; @@ -1875,9 +1827,8 @@ xlog_recover_do_inode_buffer( * di_next_unlinked field, then move on to the next * di_next_unlinked field. */ - if (next_unlinked_offset < reg_buf_offset) { + if (next_unlinked_offset < reg_buf_offset) continue; - } ASSERT(item->ri_buf[item_index].i_addr != NULL); ASSERT((item->ri_buf[item_index].i_len % XFS_BLF_CHUNK) == 0); @@ -1913,36 +1864,29 @@ xlog_recover_do_inode_buffer( * given buffer. The bitmap in the buf log format structure indicates * where to place the logged data. */ -/*ARGSUSED*/ STATIC void xlog_recover_do_reg_buffer( struct xfs_mount *mp, xlog_recover_item_t *item, - xfs_buf_t *bp, + struct xfs_buf *bp, xfs_buf_log_format_t *buf_f) { int i; int bit; int nbits; - unsigned int *data_map = NULL; - unsigned int map_size = 0; int error; trace_xfs_log_recover_buf_reg_buf(mp->m_log, buf_f); - switch (buf_f->blf_type) { - case XFS_LI_BUF: - data_map = buf_f->blf_data_map; - map_size = buf_f->blf_map_size; - break; - } bit = 0; i = 1; /* 0 is the buf format structure */ while (1) { - bit = xfs_next_bit(data_map, map_size, bit); + bit = xfs_next_bit(buf_f->blf_data_map, + buf_f->blf_map_size, bit); if (bit == -1) break; - nbits = xfs_contig_bits(data_map, map_size, bit); + nbits = xfs_contig_bits(buf_f->blf_data_map, + buf_f->blf_map_size, bit); ASSERT(nbits > 0); ASSERT(item->ri_buf[i].i_addr != NULL); ASSERT(item->ri_buf[i].i_len % XFS_BLF_CHUNK == 0); @@ -2182,13 +2126,9 @@ xlog_recover_do_buffer_trans( int pass) { xfs_buf_log_format_t *buf_f = item->ri_buf[0].i_addr; - xfs_mount_t *mp; + xfs_mount_t *mp = log->l_mp; xfs_buf_t *bp; int error; - int cancel; - xfs_daddr_t blkno; - int len; - ushort flags; uint buf_flags; if (pass == XLOG_RECOVER_PASS1) { @@ -2206,47 +2146,32 @@ xlog_recover_do_buffer_trans( * we call here will tell us whether or not to * continue with the replay of this buffer. */ - cancel = xlog_recover_do_buffer_pass2(log, buf_f); - if (cancel) { + if (xlog_check_buffer_cancelled(log, buf_f->blf_blkno, + buf_f->blf_len, buf_f->blf_flags)) { trace_xfs_log_recover_buf_cancel(log, buf_f); return 0; } } trace_xfs_log_recover_buf_recover(log, buf_f); - switch (buf_f->blf_type) { - case XFS_LI_BUF: - blkno = buf_f->blf_blkno; - len = buf_f->blf_len; - flags = buf_f->blf_flags; - break; - default: - xfs_fs_cmn_err(CE_ALERT, log->l_mp, - "xfs_log_recover: unknown buffer type 0x%x, logdev %s", - buf_f->blf_type, log->l_mp->m_logname ? - log->l_mp->m_logname : "internal"); - XFS_ERROR_REPORT("xlog_recover_do_buffer_trans", - XFS_ERRLEVEL_LOW, log->l_mp); - return XFS_ERROR(EFSCORRUPTED); - } - mp = log->l_mp; buf_flags = XBF_LOCK; - if (!(flags & XFS_BLF_INODE_BUF)) + if (!(buf_f->blf_flags & XFS_BLF_INODE_BUF)) buf_flags |= XBF_MAPPED; - bp = xfs_buf_read(mp->m_ddev_targp, blkno, len, buf_flags); + bp = xfs_buf_read(mp->m_ddev_targp, buf_f->blf_blkno, buf_f->blf_len, + buf_flags); if (XFS_BUF_ISERROR(bp)) { - xfs_ioerror_alert("xlog_recover_do..(read#1)", log->l_mp, - bp, blkno); + xfs_ioerror_alert("xlog_recover_do..(read#1)", mp, + bp, buf_f->blf_blkno); error = XFS_BUF_GETERROR(bp); xfs_buf_relse(bp); return error; } error = 0; - if (flags & XFS_BLF_INODE_BUF) { + if (buf_f->blf_flags & XFS_BLF_INODE_BUF) { error = xlog_recover_do_inode_buffer(mp, item, bp, buf_f); - } else if (flags & + } else if (buf_f->blf_flags & (XFS_BLF_UDQUOT_BUF|XFS_BLF_PDQUOT_BUF|XFS_BLF_GDQUOT_BUF)) { xlog_recover_do_dquot_buffer(mp, log, item, bp, buf_f); } else { From BATV+3217d6c06e4d83826047+2656+infradead.org+hch@bombadil.srs.infradead.org Wed Dec 1 16:05:30 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB1M5Su1236341 for ; Wed, 1 Dec 2010 16:05:30 -0600 X-ASG-Debug-ID: 1291241232-4a1903160000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6C7E91609CBA for ; Wed, 1 Dec 2010 14:07:12 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id MJc2InuiI1XHceIf for ; Wed, 01 Dec 2010 14:07:12 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PNupS-0007nl-GC for xfs@oss.sgi.com; Wed, 01 Dec 2010 22:07:10 +0000 Message-Id: <20101201220710.454838485@bombadil.infradead.org> User-Agent: quilt/0.48-1 Date: Wed, 01 Dec 2010 17:06:23 -0500 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 3/4] xfs: refactor xlog_recover_commit_trans Subject: [PATCH 3/4] xfs: refactor xlog_recover_commit_trans References: <20101201220620.340188389@bombadil.infradead.org> Content-Disposition: inline; filename=xfs-cleanup-xlog_recover_commit_trans X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291241232 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Merge the call to xlog_recover_reorder_trans and the loop over the recovery items from xlog_recover_do_trans into xlog_recover_commit_trans, and keep the switch statement over the log item types as a separate helper. Signed-off-by: Christoph Hellwig Index: xfs/fs/xfs/xfs_log_recover.c =================================================================== --- xfs.orig/fs/xfs/xfs_log_recover.c 2010-11-29 15:15:58.174005517 +0100 +++ xfs/fs/xfs/xfs_log_recover.c 2010-11-29 15:27:26.298253879 +0100 @@ -2674,71 +2674,13 @@ xlog_recover_do_efd_trans( } /* - * Perform the transaction - * - * If the transaction modifies a buffer or inode, do it now. Otherwise, - * EFIs and EFDs get queued up by adding entries into the AIL for them. - */ -STATIC int -xlog_recover_do_trans( - xlog_t *log, - xlog_recover_t *trans, - int pass) -{ - int error = 0; - xlog_recover_item_t *item; - - error = xlog_recover_reorder_trans(log, trans, pass); - if (error) - return error; - - list_for_each_entry(item, &trans->r_itemq, ri_list) { - trace_xfs_log_recover_item_recover(log, trans, item, pass); - switch (ITEM_TYPE(item)) { - case XFS_LI_BUF: - error = xlog_recover_do_buffer_trans(log, item, pass); - break; - case XFS_LI_INODE: - error = xlog_recover_do_inode_trans(log, item, pass); - break; - case XFS_LI_EFI: - error = xlog_recover_do_efi_trans(log, item, - trans->r_lsn, pass); - break; - case XFS_LI_EFD: - xlog_recover_do_efd_trans(log, item, pass); - error = 0; - break; - case XFS_LI_DQUOT: - error = xlog_recover_do_dquot_trans(log, item, pass); - break; - case XFS_LI_QUOTAOFF: - error = xlog_recover_do_quotaoff_trans(log, item, - pass); - break; - default: - xlog_warn( - "XFS: invalid item type (%d) xlog_recover_do_trans", ITEM_TYPE(item)); - ASSERT(0); - error = XFS_ERROR(EIO); - break; - } - - if (error) - return error; - } - - return 0; -} - -/* * Free up any resources allocated by the transaction * * Remember that EFIs, EFDs, and IUNLINKs are handled later. */ STATIC void xlog_recover_free_trans( - xlog_recover_t *trans) + struct xlog_recover *trans) { xlog_recover_item_t *item, *n; int i; @@ -2757,17 +2699,65 @@ xlog_recover_free_trans( } STATIC int +xlog_recover_commit_item( + struct log *log, + struct xlog_recover *trans, + xlog_recover_item_t *item, + int pass) +{ + trace_xfs_log_recover_item_recover(log, trans, item, pass); + + switch (ITEM_TYPE(item)) { + case XFS_LI_BUF: + return xlog_recover_do_buffer_trans(log, item, pass); + break; + case XFS_LI_INODE: + return xlog_recover_do_inode_trans(log, item, pass); + case XFS_LI_EFI: + return xlog_recover_do_efi_trans(log, item, trans->r_lsn, pass); + case XFS_LI_EFD: + xlog_recover_do_efd_trans(log, item, pass); + return 0; + case XFS_LI_DQUOT: + return xlog_recover_do_dquot_trans(log, item, pass); + case XFS_LI_QUOTAOFF: + return xlog_recover_do_quotaoff_trans(log, item, pass); + default: + xlog_warn( + "XFS: invalid item type (%d) xlog_recover_do_trans", ITEM_TYPE(item)); + ASSERT(0); + return XFS_ERROR(EIO); + } +} + +/* + * Perform the transaction. + * + * If the transaction modifies a buffer or inode, do it now. Otherwise, + * EFIs and EFDs get queued up by adding entries into the AIL for them. + */ +STATIC int xlog_recover_commit_trans( - xlog_t *log, - xlog_recover_t *trans, + struct log *log, + struct xlog_recover *trans, int pass) { - int error; + int error = 0; + xlog_recover_item_t *item; hlist_del(&trans->r_list); - if ((error = xlog_recover_do_trans(log, trans, pass))) + + error = xlog_recover_reorder_trans(log, trans, pass); + if (error) return error; - xlog_recover_free_trans(trans); /* no error */ + + list_for_each_entry(item, &trans->r_itemq, ri_list) { + error = xlog_recover_commit_item(log, trans, item, pass); + if (error) + return error; + } + + xlog_recover_free_trans(trans); return 0; } From BATV+3217d6c06e4d83826047+2656+infradead.org+hch@bombadil.srs.infradead.org Wed Dec 1 16:05:30 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,J_CHICKENPOX_65, J_CHICKENPOX_66 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB1M5SwK236339 for ; Wed, 1 Dec 2010 16:05:30 -0600 X-ASG-Debug-ID: 1291241230-734701b40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E14C91609CBA for ; Wed, 1 Dec 2010 14:07:11 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id HARdAZMiDfS4nfQr for ; Wed, 01 Dec 2010 14:07:11 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PNupS-0007nF-9h for xfs@oss.sgi.com; Wed, 01 Dec 2010 22:07:10 +0000 Message-Id: <20101201220710.254521341@bombadil.infradead.org> User-Agent: quilt/0.48-1 Date: Wed, 01 Dec 2010 17:06:22 -0500 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 2/4] xfs: use struct list_head for the buf cancel table Subject: [PATCH 2/4] xfs: use struct list_head for the buf cancel table References: <20101201220620.340188389@bombadil.infradead.org> Content-Disposition: inline; filename=xfs-buf-cancel-list_head X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291241231 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Signed-off-by: Christoph Hellwig Index: xfs/fs/xfs/xfs_buf_item.h =================================================================== --- xfs.orig/fs/xfs/xfs_buf_item.h 2010-11-29 16:33:20.473005032 +0100 +++ xfs/fs/xfs/xfs_buf_item.h 2010-11-29 17:26:52.384003914 +0100 @@ -105,17 +105,6 @@ typedef struct xfs_buf_log_item { xfs_buf_log_format_t bli_format; /* in-log header */ } xfs_buf_log_item_t; -/* - * This structure is used during recovery to record the buf log - * items which have been canceled and should not be replayed. - */ -typedef struct xfs_buf_cancel { - xfs_daddr_t bc_blkno; - uint bc_len; - int bc_refcount; - struct xfs_buf_cancel *bc_next; -} xfs_buf_cancel_t; - void xfs_buf_item_init(struct xfs_buf *, struct xfs_mount *); void xfs_buf_item_relse(struct xfs_buf *); void xfs_buf_item_log(xfs_buf_log_item_t *, uint, uint); Index: xfs/fs/xfs/xfs_log_priv.h =================================================================== --- xfs.orig/fs/xfs/xfs_log_priv.h 2010-11-29 16:33:20.486010899 +0100 +++ xfs/fs/xfs/xfs_log_priv.h 2010-11-29 17:26:52.385003145 +0100 @@ -21,7 +21,6 @@ struct xfs_buf; struct log; struct xlog_ticket; -struct xfs_buf_cancel; struct xfs_mount; /* @@ -491,7 +490,7 @@ typedef struct log { struct xfs_buftarg *l_targ; /* buftarg of log */ uint l_flags; uint l_quotaoffs_flag; /* XFS_DQ_*, for QUOTAOFFs */ - struct xfs_buf_cancel **l_buf_cancel_table; + struct list_head *l_buf_cancel_table; int l_iclog_hsize; /* size of iclog header */ int l_iclog_heads; /* # of iclog header sectors */ uint l_sectBBsize; /* sector size in BBs (2^n) */ @@ -534,6 +533,9 @@ typedef struct log { } xlog_t; +#define XLOG_BUF_CANCEL_BUCKET(log, blkno) \ + ((log)->l_buf_cancel_table + ((__uint64_t)blkno % XLOG_BC_TABLE_SIZE)) + #define XLOG_FORCED_SHUTDOWN(log) ((log)->l_flags & XLOG_IO_ERROR) /* common routines */ Index: xfs/fs/xfs/xfs_log_recover.c =================================================================== --- xfs.orig/fs/xfs/xfs_log_recover.c 2010-11-29 16:33:20.495004054 +0100 +++ xfs/fs/xfs/xfs_log_recover.c 2010-11-29 17:31:12.135004894 +0100 @@ -53,6 +53,17 @@ STATIC void xlog_recover_check_summary(x #endif /* + * This structure is used during recovery to record the buf log items which + * have been canceled and should not be replayed. + */ +struct xfs_buf_cancel { + xfs_daddr_t bc_blkno; + uint bc_len; + int bc_refcount; + struct list_head bc_list; +}; + +/* * Sector aligned buffer routines for buffer create/read/write/access */ @@ -1607,15 +1618,11 @@ xlog_recover_reorder_trans( */ STATIC void xlog_recover_do_buffer_pass1( - xlog_t *log, + struct log *log, xfs_buf_log_format_t *buf_f) { - xfs_buf_cancel_t *bcp; - xfs_buf_cancel_t *nextp; - xfs_buf_cancel_t *prevp; - xfs_buf_cancel_t **bucket; - xfs_daddr_t blkno = buf_f->blf_blkno; - uint len = buf_f->blf_len; + struct list_head *bucket; + struct xfs_buf_cancel *bcp; /* * If this isn't a cancel buffer item, then just return. @@ -1626,51 +1633,25 @@ xlog_recover_do_buffer_pass1( } /* - * Insert an xfs_buf_cancel record into the hash table of - * them. If there is already an identical record, bump - * its reference count. - */ - bucket = &log->l_buf_cancel_table[(__uint64_t)blkno % - XLOG_BC_TABLE_SIZE]; - /* - * If the hash bucket is empty then just insert a new record into - * the bucket. - */ - if (*bucket == NULL) { - bcp = (xfs_buf_cancel_t *)kmem_alloc(sizeof(xfs_buf_cancel_t), - KM_SLEEP); - bcp->bc_blkno = blkno; - bcp->bc_len = len; - bcp->bc_refcount = 1; - bcp->bc_next = NULL; - *bucket = bcp; - return; - } - - /* - * The hash bucket is not empty, so search for duplicates of our - * record. If we find one them just bump its refcount. If not - * then add us at the end of the list. - */ - prevp = NULL; - nextp = *bucket; - while (nextp != NULL) { - if (nextp->bc_blkno == blkno && nextp->bc_len == len) { - nextp->bc_refcount++; + * Insert an xfs_buf_cancel record into the hash table of them. + * If there is already an identical record, bump its reference count. + */ + bucket = XLOG_BUF_CANCEL_BUCKET(log, buf_f->blf_blkno); + list_for_each_entry(bcp, bucket, bc_list) { + if (bcp->bc_blkno == buf_f->blf_blkno && + bcp->bc_len == buf_f->blf_len) { + bcp->bc_refcount++; trace_xfs_log_recover_buf_cancel_ref_inc(log, buf_f); return; } - prevp = nextp; - nextp = nextp->bc_next; } - ASSERT(prevp != NULL); - bcp = (xfs_buf_cancel_t *)kmem_alloc(sizeof(xfs_buf_cancel_t), - KM_SLEEP); - bcp->bc_blkno = blkno; - bcp->bc_len = len; + + bcp = kmem_alloc(sizeof(struct xfs_buf_cancel), KM_SLEEP); + bcp->bc_blkno = buf_f->blf_blkno; + bcp->bc_len = buf_f->blf_len; bcp->bc_refcount = 1; - bcp->bc_next = NULL; - prevp->bc_next = bcp; + list_add_tail(&bcp->bc_list, bucket); + trace_xfs_log_recover_buf_cancel_add(log, buf_f); } @@ -1689,14 +1670,13 @@ xlog_recover_do_buffer_pass1( */ STATIC int xlog_check_buffer_cancelled( - xlog_t *log, + struct log *log, xfs_daddr_t blkno, uint len, ushort flags) { - xfs_buf_cancel_t *bcp; - xfs_buf_cancel_t *prevp; - xfs_buf_cancel_t **bucket; + struct list_head *bucket; + struct xfs_buf_cancel *bcp; if (log->l_buf_cancel_table == NULL) { /* @@ -1707,55 +1687,36 @@ xlog_check_buffer_cancelled( return 0; } - bucket = &log->l_buf_cancel_table[(__uint64_t)blkno % - XLOG_BC_TABLE_SIZE]; - bcp = *bucket; - if (bcp == NULL) { - /* - * There is no corresponding entry in the table built - * in pass one, so this buffer has not been cancelled. - */ - ASSERT(!(flags & XFS_BLF_CANCEL)); - return 0; - } - /* - * Search for an entry in the buffer cancel table that - * matches our buffer. + * Search for an entry in the cancel table that matches our buffer. */ - prevp = NULL; - while (bcp != NULL) { - if (bcp->bc_blkno == blkno && bcp->bc_len == len) { - /* - * We've go a match, so return 1 so that the - * recovery of this buffer is cancelled. - * If this buffer is actually a buffer cancel - * log item, then decrement the refcount on the - * one in the table and remove it if this is the - * last reference. - */ - if (flags & XFS_BLF_CANCEL) { - bcp->bc_refcount--; - if (bcp->bc_refcount == 0) { - if (prevp == NULL) { - *bucket = bcp->bc_next; - } else { - prevp->bc_next = bcp->bc_next; - } - kmem_free(bcp); - } - } - return 1; - } - prevp = bcp; - bcp = bcp->bc_next; + bucket = XLOG_BUF_CANCEL_BUCKET(log, blkno); + list_for_each_entry(bcp, bucket, bc_list) { + if (bcp->bc_blkno == blkno && bcp->bc_len == len) + goto found; } + /* - * We didn't find a corresponding entry in the table, so - * return 0 so that the buffer is NOT cancelled. + * We didn't find a corresponding entry in the table, so return 0 so + * that the buffer is NOT cancelled. */ ASSERT(!(flags & XFS_BLF_CANCEL)); return 0; + +found: + /* + * We've go a match, so return 1 so that the recovery of this buffer + * is cancelled. If this buffer is actually a buffer cancel log + * item, then decrement the refcount on the one in the table and + * remove it if this is the last reference. + */ + if (flags & XFS_BLF_CANCEL) { + if (--bcp->bc_refcount == 0) { + list_del(&bcp->bc_list); + kmem_free(bcp); + } + } + return 1; } /* @@ -3649,7 +3610,7 @@ xlog_do_log_recovery( xfs_daddr_t head_blk, xfs_daddr_t tail_blk) { - int error; + int error, i; ASSERT(head_blk != tail_blk); @@ -3657,10 +3618,12 @@ xlog_do_log_recovery( * First do a pass to find all of the cancelled buf log items. * Store them in the buf_cancel_table for use in the second pass. */ - log->l_buf_cancel_table = - (xfs_buf_cancel_t **)kmem_zalloc(XLOG_BC_TABLE_SIZE * - sizeof(xfs_buf_cancel_t*), + log->l_buf_cancel_table = kmem_zalloc(XLOG_BC_TABLE_SIZE * + sizeof(struct list_head), KM_SLEEP); + for (i = 0; i < XLOG_BC_TABLE_SIZE; i++) + INIT_LIST_HEAD(&log->l_buf_cancel_table[i]); + error = xlog_do_recovery_pass(log, head_blk, tail_blk, XLOG_RECOVER_PASS1); if (error != 0) { @@ -3679,7 +3642,7 @@ xlog_do_log_recovery( int i; for (i = 0; i < XLOG_BC_TABLE_SIZE; i++) - ASSERT(log->l_buf_cancel_table[i] == NULL); + ASSERT(list_empty(&log->l_buf_cancel_table[i])); } #endif /* DEBUG */ From BATV+3217d6c06e4d83826047+2656+infradead.org+hch@bombadil.srs.infradead.org Wed Dec 1 16:05:30 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB1M5STQ236342 for ; Wed, 1 Dec 2010 16:05:30 -0600 X-ASG-Debug-ID: 1291241232-734301db0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6C97F1609CBE for ; Wed, 1 Dec 2010 14:07:12 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 3do7UuMchneZVKLZ for ; Wed, 01 Dec 2010 14:07:12 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PNupR-0007m9-SE for xfs@oss.sgi.com; Wed, 01 Dec 2010 22:07:09 +0000 Message-Id: <20101201220620.340188389@bombadil.infradead.org> User-Agent: quilt/0.48-1 Date: Wed, 01 Dec 2010 17:06:20 -0500 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 0/4] log recovery cleanups Subject: [PATCH 0/4] log recovery cleanups X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291241232 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean A couple of cleanups for the log recovery code that I stumbled upon when researching some improvements for the CRC cleanup. From BATV+3217d6c06e4d83826047+2656+infradead.org+hch@bombadil.srs.infradead.org Wed Dec 1 16:05:30 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_66, LOCAL_GNU_PATCH autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB1M5RQt236332 for ; Wed, 1 Dec 2010 16:05:30 -0600 X-ASG-Debug-ID: 1291241230-3482028f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5ADB44F05FE for ; Wed, 1 Dec 2010 14:07:11 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 2bOMalUQXXzbFOuE for ; Wed, 01 Dec 2010 14:07:11 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PNupS-0007oH-MP for xfs@oss.sgi.com; Wed, 01 Dec 2010 22:07:10 +0000 Message-Id: <20101201220710.647499265@bombadil.infradead.org> User-Agent: quilt/0.48-1 Date: Wed, 01 Dec 2010 17:06:24 -0500 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 4/4] xfs: untangle phase1 vs phase2 recovery helpers Subject: [PATCH 4/4] xfs: untangle phase1 vs phase2 recovery helpers References: <20101201220620.340188389@bombadil.infradead.org> Content-Disposition: inline; filename=xfs-split-log-recovery-passes X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291241231 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Dispatch to a different helper for phase1 vs phase2 in xlog_recover_commit_trans instead of doing it in all the low-level functions. Signed-off-by: Christoph Hellwig Index: xfs/fs/xfs/xfs_log_recover.c =================================================================== --- xfs.orig/fs/xfs/xfs_log_recover.c 2010-12-01 17:03:04.922253529 +0100 +++ xfs/fs/xfs/xfs_log_recover.c 2010-12-01 17:12:29.318255483 +0100 @@ -1616,11 +1616,12 @@ xlog_recover_reorder_trans( * record in the table to tell us how many times we expect to see this * record during the second pass. */ -STATIC void -xlog_recover_do_buffer_pass1( +STATIC int +xlog_recover_buffer_pass1( struct log *log, - xfs_buf_log_format_t *buf_f) + xlog_recover_item_t *item) { + xfs_buf_log_format_t *buf_f = item->ri_buf[0].i_addr; struct list_head *bucket; struct xfs_buf_cancel *bcp; @@ -1629,7 +1630,7 @@ xlog_recover_do_buffer_pass1( */ if (!(buf_f->blf_flags & XFS_BLF_CANCEL)) { trace_xfs_log_recover_buf_not_cancel(log, buf_f); - return; + return 0; } /* @@ -1642,7 +1643,7 @@ xlog_recover_do_buffer_pass1( bcp->bc_len == buf_f->blf_len) { bcp->bc_refcount++; trace_xfs_log_recover_buf_cancel_ref_inc(log, buf_f); - return; + return 0; } } @@ -1653,6 +1654,7 @@ xlog_recover_do_buffer_pass1( list_add_tail(&bcp->bc_list, bucket); trace_xfs_log_recover_buf_cancel_add(log, buf_f); + return 0; } /* @@ -2081,10 +2083,9 @@ xlog_recover_do_dquot_buffer( * for more details on the implementation of the table of cancel records. */ STATIC int -xlog_recover_do_buffer_trans( +xlog_recover_buffer_pass2( xlog_t *log, - xlog_recover_item_t *item, - int pass) + xlog_recover_item_t *item) { xfs_buf_log_format_t *buf_f = item->ri_buf[0].i_addr; xfs_mount_t *mp = log->l_mp; @@ -2092,27 +2093,16 @@ xlog_recover_do_buffer_trans( int error; uint buf_flags; - if (pass == XLOG_RECOVER_PASS1) { - /* - * In this pass we're only looking for buf items - * with the XFS_BLF_CANCEL bit set. - */ - xlog_recover_do_buffer_pass1(log, buf_f); + /* + * In this pass we only want to recover all the buffers which have + * not been cancelled and are not cancellation buffers themselves. + */ + if (xlog_check_buffer_cancelled(log, buf_f->blf_blkno, + buf_f->blf_len, buf_f->blf_flags)) { + trace_xfs_log_recover_buf_cancel(log, buf_f); return 0; - } else { - /* - * In this pass we want to recover all the buffers - * which have not been cancelled and are not - * cancellation buffers themselves. The routine - * we call here will tell us whether or not to - * continue with the replay of this buffer. - */ - if (xlog_check_buffer_cancelled(log, buf_f->blf_blkno, - buf_f->blf_len, buf_f->blf_flags)) { - trace_xfs_log_recover_buf_cancel(log, buf_f); - return 0; - } } + trace_xfs_log_recover_buf_recover(log, buf_f); buf_flags = XBF_LOCK; @@ -2172,16 +2162,14 @@ xlog_recover_do_buffer_trans( } STATIC int -xlog_recover_do_inode_trans( +xlog_recover_inode_pass2( xlog_t *log, - xlog_recover_item_t *item, - int pass) + xlog_recover_item_t *item) { xfs_inode_log_format_t *in_f; - xfs_mount_t *mp; + xfs_mount_t *mp = log->l_mp; xfs_buf_t *bp; xfs_dinode_t *dip; - xfs_ino_t ino; int len; xfs_caddr_t src; xfs_caddr_t dest; @@ -2191,10 +2179,6 @@ xlog_recover_do_inode_trans( xfs_icdinode_t *dicp; int need_free = 0; - if (pass == XLOG_RECOVER_PASS1) { - return 0; - } - if (item->ri_buf[0].i_len == sizeof(xfs_inode_log_format_t)) { in_f = item->ri_buf[0].i_addr; } else { @@ -2204,8 +2188,6 @@ xlog_recover_do_inode_trans( if (error) goto error; } - ino = in_f->ilf_ino; - mp = log->l_mp; /* * Inode buffers can be freed, look out for it, @@ -2240,8 +2222,8 @@ xlog_recover_do_inode_trans( xfs_buf_relse(bp); xfs_fs_cmn_err(CE_ALERT, mp, "xfs_inode_recover: Bad inode magic number, dino ptr = 0x%p, dino bp = 0x%p, ino = %Ld", - dip, bp, ino); - XFS_ERROR_REPORT("xlog_recover_do_inode_trans(1)", + dip, bp, in_f->ilf_ino); + XFS_ERROR_REPORT("xlog_recover_inode_pass2(1)", XFS_ERRLEVEL_LOW, mp); error = EFSCORRUPTED; goto error; @@ -2251,8 +2233,8 @@ xlog_recover_do_inode_trans( xfs_buf_relse(bp); xfs_fs_cmn_err(CE_ALERT, mp, "xfs_inode_recover: Bad inode log record, rec ptr 0x%p, ino %Ld", - item, ino); - XFS_ERROR_REPORT("xlog_recover_do_inode_trans(2)", + item, in_f->ilf_ino); + XFS_ERROR_REPORT("xlog_recover_inode_pass2(2)", XFS_ERRLEVEL_LOW, mp); error = EFSCORRUPTED; goto error; @@ -2280,12 +2262,12 @@ xlog_recover_do_inode_trans( if (unlikely((dicp->di_mode & S_IFMT) == S_IFREG)) { if ((dicp->di_format != XFS_DINODE_FMT_EXTENTS) && (dicp->di_format != XFS_DINODE_FMT_BTREE)) { - XFS_CORRUPTION_ERROR("xlog_recover_do_inode_trans(3)", + XFS_CORRUPTION_ERROR("xlog_recover_inode_pass2(3)", XFS_ERRLEVEL_LOW, mp, dicp); xfs_buf_relse(bp); xfs_fs_cmn_err(CE_ALERT, mp, "xfs_inode_recover: Bad regular inode log record, rec ptr 0x%p, ino ptr = 0x%p, ino bp = 0x%p, ino %Ld", - item, dip, bp, ino); + item, dip, bp, in_f->ilf_ino); error = EFSCORRUPTED; goto error; } @@ -2293,40 +2275,40 @@ xlog_recover_do_inode_trans( if ((dicp->di_format != XFS_DINODE_FMT_EXTENTS) && (dicp->di_format != XFS_DINODE_FMT_BTREE) && (dicp->di_format != XFS_DINODE_FMT_LOCAL)) { - XFS_CORRUPTION_ERROR("xlog_recover_do_inode_trans(4)", + XFS_CORRUPTION_ERROR("xlog_recover_inode_pass2(4)", XFS_ERRLEVEL_LOW, mp, dicp); xfs_buf_relse(bp); xfs_fs_cmn_err(CE_ALERT, mp, "xfs_inode_recover: Bad dir inode log record, rec ptr 0x%p, ino ptr = 0x%p, ino bp = 0x%p, ino %Ld", - item, dip, bp, ino); + item, dip, bp, in_f->ilf_ino); error = EFSCORRUPTED; goto error; } } if (unlikely(dicp->di_nextents + dicp->di_anextents > dicp->di_nblocks)){ - XFS_CORRUPTION_ERROR("xlog_recover_do_inode_trans(5)", + XFS_CORRUPTION_ERROR("xlog_recover_inode_pass2(5)", XFS_ERRLEVEL_LOW, mp, dicp); xfs_buf_relse(bp); xfs_fs_cmn_err(CE_ALERT, mp, "xfs_inode_recover: Bad inode log record, rec ptr 0x%p, dino ptr 0x%p, dino bp 0x%p, ino %Ld, total extents = %d, nblocks = %Ld", - item, dip, bp, ino, + item, dip, bp, in_f->ilf_ino, dicp->di_nextents + dicp->di_anextents, dicp->di_nblocks); error = EFSCORRUPTED; goto error; } if (unlikely(dicp->di_forkoff > mp->m_sb.sb_inodesize)) { - XFS_CORRUPTION_ERROR("xlog_recover_do_inode_trans(6)", + XFS_CORRUPTION_ERROR("xlog_recover_inode_pass2(6)", XFS_ERRLEVEL_LOW, mp, dicp); xfs_buf_relse(bp); xfs_fs_cmn_err(CE_ALERT, mp, "xfs_inode_recover: Bad inode log rec ptr 0x%p, dino ptr 0x%p, dino bp 0x%p, ino %Ld, forkoff 0x%x", - item, dip, bp, ino, dicp->di_forkoff); + item, dip, bp, in_f->ilf_ino, dicp->di_forkoff); error = EFSCORRUPTED; goto error; } if (unlikely(item->ri_buf[1].i_len > sizeof(struct xfs_icdinode))) { - XFS_CORRUPTION_ERROR("xlog_recover_do_inode_trans(7)", + XFS_CORRUPTION_ERROR("xlog_recover_inode_pass2(7)", XFS_ERRLEVEL_LOW, mp, dicp); xfs_buf_relse(bp); xfs_fs_cmn_err(CE_ALERT, mp, @@ -2418,7 +2400,7 @@ xlog_recover_do_inode_trans( break; default: - xlog_warn("XFS: xlog_recover_do_inode_trans: Invalid flag"); + xlog_warn("XFS: xlog_recover_inode_pass2: Invalid flag"); ASSERT(0); xfs_buf_relse(bp); error = EIO; @@ -2442,18 +2424,11 @@ error: * of that type. */ STATIC int -xlog_recover_do_quotaoff_trans( +xlog_recover_quotaoff_pass1( xlog_t *log, - xlog_recover_item_t *item, - int pass) + xlog_recover_item_t *item) { - xfs_qoff_logformat_t *qoff_f; - - if (pass == XLOG_RECOVER_PASS2) { - return (0); - } - - qoff_f = item->ri_buf[0].i_addr; + xfs_qoff_logformat_t *qoff_f = item->ri_buf[0].i_addr; ASSERT(qoff_f); /* @@ -2474,22 +2449,17 @@ xlog_recover_do_quotaoff_trans( * Recover a dquot record */ STATIC int -xlog_recover_do_dquot_trans( +xlog_recover_dquot_pass2( xlog_t *log, - xlog_recover_item_t *item, - int pass) + xlog_recover_item_t *item) { - xfs_mount_t *mp; + xfs_mount_t *mp = log->l_mp; xfs_buf_t *bp; struct xfs_disk_dquot *ddq, *recddq; int error; xfs_dq_logformat_t *dq_f; uint type; - if (pass == XLOG_RECOVER_PASS1) { - return 0; - } - mp = log->l_mp; /* * Filesystems are required to send in quota flags at mount time. @@ -2533,7 +2503,7 @@ xlog_recover_do_dquot_trans( if ((error = xfs_qm_dqcheck(recddq, dq_f->qlf_id, 0, XFS_QMOPT_DOWARN, - "xlog_recover_do_dquot_trans (log copy)"))) { + "xlog_recover_dquot_pass2 (log copy)"))) { return XFS_ERROR(EIO); } ASSERT(dq_f->qlf_len == 1); @@ -2556,7 +2526,7 @@ xlog_recover_do_dquot_trans( * minimal initialization then. */ if (xfs_qm_dqcheck(ddq, dq_f->qlf_id, 0, XFS_QMOPT_DOWARN, - "xlog_recover_do_dquot_trans")) { + "xlog_recover_dquot_pass2")) { xfs_buf_relse(bp); return XFS_ERROR(EIO); } @@ -2579,24 +2549,18 @@ xlog_recover_do_dquot_trans( * LSN. */ STATIC int -xlog_recover_do_efi_trans( +xlog_recover_efi_pass2( xlog_t *log, xlog_recover_item_t *item, - xfs_lsn_t lsn, - int pass) + xfs_lsn_t lsn) { int error; - xfs_mount_t *mp; + xfs_mount_t *mp = log->l_mp; xfs_efi_log_item_t *efip; xfs_efi_log_format_t *efi_formatp; - if (pass == XLOG_RECOVER_PASS1) { - return 0; - } - efi_formatp = item->ri_buf[0].i_addr; - mp = log->l_mp; efip = xfs_efi_init(mp, efi_formatp->efi_nextents); if ((error = xfs_efi_copy_format(&(item->ri_buf[0]), &(efip->efi_format)))) { @@ -2623,11 +2587,10 @@ xlog_recover_do_efi_trans( * efd format structure. If we find it, we remove the efi from the * AIL and free it. */ -STATIC void -xlog_recover_do_efd_trans( +STATIC int +xlog_recover_efd_pass2( xlog_t *log, - xlog_recover_item_t *item, - int pass) + xlog_recover_item_t *item) { xfs_efd_log_format_t *efd_formatp; xfs_efi_log_item_t *efip = NULL; @@ -2636,10 +2599,6 @@ xlog_recover_do_efd_trans( struct xfs_ail_cursor cur; struct xfs_ail *ailp = log->l_ailp; - if (pass == XLOG_RECOVER_PASS1) { - return; - } - efd_formatp = item->ri_buf[0].i_addr; ASSERT((item->ri_buf[0].i_len == (sizeof(xfs_efd_log_format_32_t) + ((efd_formatp->efd_nextents - 1) * sizeof(xfs_extent_32_t)))) || @@ -2671,6 +2630,8 @@ xlog_recover_do_efd_trans( } xfs_trans_ail_cursor_done(ailp, &cur); spin_unlock(&ailp->xa_lock); + + return 0; } /* @@ -2699,32 +2660,59 @@ xlog_recover_free_trans( } STATIC int -xlog_recover_commit_item( +xlog_recover_commit_pass1( struct log *log, struct xlog_recover *trans, - xlog_recover_item_t *item, - int pass) + xlog_recover_item_t *item) { - trace_xfs_log_recover_item_recover(log, trans, item, pass); + trace_xfs_log_recover_item_recover(log, trans, item, XLOG_RECOVER_PASS1); switch (ITEM_TYPE(item)) { case XFS_LI_BUF: - return xlog_recover_do_buffer_trans(log, item, pass); - break; + return xlog_recover_buffer_pass1(log, item); + case XFS_LI_QUOTAOFF: + return xlog_recover_quotaoff_pass1(log, item); case XFS_LI_INODE: - return xlog_recover_do_inode_trans(log, item, pass); case XFS_LI_EFI: - return xlog_recover_do_efi_trans(log, item, trans->r_lsn, pass); case XFS_LI_EFD: - xlog_recover_do_efd_trans(log, item, pass); + case XFS_LI_DQUOT: + /* nothing to do in pass 1 */ return 0; + default: + xlog_warn( + "XFS: invalid item type (%d) xlog_recover_commit_pass1", + ITEM_TYPE(item)); + ASSERT(0); + return XFS_ERROR(EIO); + } +} + +STATIC int +xlog_recover_commit_pass2( + struct log *log, + struct xlog_recover *trans, + xlog_recover_item_t *item) +{ + trace_xfs_log_recover_item_recover(log, trans, item, XLOG_RECOVER_PASS2); + + switch (ITEM_TYPE(item)) { + case XFS_LI_BUF: + return xlog_recover_buffer_pass2(log, item); + case XFS_LI_INODE: + return xlog_recover_inode_pass2(log, item); + case XFS_LI_EFI: + return xlog_recover_efi_pass2(log, item, trans->r_lsn); + case XFS_LI_EFD: + return xlog_recover_efd_pass2(log, item); case XFS_LI_DQUOT: - return xlog_recover_do_dquot_trans(log, item, pass); + return xlog_recover_dquot_pass2(log, item); case XFS_LI_QUOTAOFF: - return xlog_recover_do_quotaoff_trans(log, item, pass); + /* nothing to do in pass2 */ + return 0; default: xlog_warn( - "XFS: invalid item type (%d) xlog_recover_do_trans", ITEM_TYPE(item)); + "XFS: invalid item type (%d) xlog_recover_commit_pass2", + ITEM_TYPE(item)); ASSERT(0); return XFS_ERROR(EIO); } @@ -2752,7 +2740,10 @@ xlog_recover_commit_trans( return error; list_for_each_entry(item, &trans->r_itemq, ri_list) { - error = xlog_recover_commit_item(log, trans, item, pass); + if (pass == XLOG_RECOVER_PASS1) + error = xlog_recover_commit_pass1(log, trans, item); + else + error = xlog_recover_commit_pass2(log, trans, item); if (error) return error; } From SRS0+W+pQ+5+fromorbit.com=david@internode.on.net Wed Dec 1 19:27:03 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB21R305243939 for ; Wed, 1 Dec 2010 19:27:03 -0600 X-ASG-Debug-ID: 1291253324-31bf01b60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4EA8E160AA63 for ; Wed, 1 Dec 2010 17:28:45 -0800 (PST) Received: from mail.internode.on.net (bld-mail15.adl6.internode.on.net [150.101.137.100]) by cuda.sgi.com with ESMTP id 8bkHc1d6Coebwv3m for ; Wed, 01 Dec 2010 17:28:45 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 36992712-1927428 for multiple; Thu, 02 Dec 2010 11:58:43 +1030 (CDT) Received: from dave by dastard with local (Exim 4.71) (envelope-from ) id 1PNxyT-0006D8-Qo; Thu, 02 Dec 2010 12:28:41 +1100 Date: Thu, 2 Dec 2010 12:28:41 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/8] xfs: Pull EFI/EFD handling out from under the AIL lock Subject: Re: [PATCH 1/8] xfs: Pull EFI/EFD handling out from under the AIL lock Message-ID: <20101202012841.GL16922@dastard> References: <1290993152-20999-1-git-send-email-david@fromorbit.com> <1290993152-20999-2-git-send-email-david@fromorbit.com> <20101130201734.GA16079@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101130201734.GA16079@infradead.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: bld-mail15.adl6.internode.on.net[150.101.137.100] X-Barracuda-Start-Time: 1291253326 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48216 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Tue, Nov 30, 2010 at 03:17:34PM -0500, Christoph Hellwig wrote: > > - xfs_efi_init needs to initialize efi_next_extent using ATOMIC_INIT OK. > - there is a behaviour change about the xfs_trans_del_item call > in xfs_efi_item_unpin - before it was protected by the > XFS_EFI_CANCELED which was never set, and now it's not. XFS_EFI_CANCELED has not been set in the code base since xfs_efi_cancel() was removed back in 2006 by commit 065d312e15902976d256ddaf396a7950ec0350a8 ("[XFS] Remove unused iop_abort log item operation), and even then xfs_efi_cancel() was never called. I haven't tracked it back further than that (beyond git history), but handling of efis in cancelled transactions has been broken for a long time. Basically, when we get an IOP_UNPIN(lip, 1); call from xfs_trans_uncommit() (i.e. remove == 1), if we don't free the log item descriptor we leak it. IOWs, the new behaviour introduced in this patch is actually the correct behaviour. > - what happened to XFS_EFI_RECOVERED? You changed it to be indexed > for the atomic bit-ops, but it's still used non-atomic in the log > recovery code. Ah, I forgot to convert it. > - Why is XFS_EFI_COMMITTED cleared in xlog_recover_do_efi_trans, > where it can't ever be set? It was just a straight transformation. I'll kill it. > - can you please add a shared helper for xfs_efi_item_unpin and > xfs_efi_release, ala: Ok. Will do. Cheers, Dave. -- Dave Chinner david@fromorbit.com From SRS0+W+pQ+5+fromorbit.com=david@internode.on.net Wed Dec 1 19:30:34 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB21UXJj244091 for ; Wed, 1 Dec 2010 19:30:34 -0600 X-ASG-Debug-ID: 1291253535-1d0400b80000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A36B81BB270 for ; Wed, 1 Dec 2010 17:32:16 -0800 (PST) Received: from mail.internode.on.net (bld-mail14.adl6.internode.on.net [150.101.137.99]) by cuda.sgi.com with ESMTP id BySFDH6YoApFGSYT for ; Wed, 01 Dec 2010 17:32:16 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 48849312-1927428 for multiple; Thu, 02 Dec 2010 12:02:15 +1030 (CDT) Received: from dave by dastard with local (Exim 4.71) (envelope-from ) id 1PNy1t-0006DK-Sc; Thu, 02 Dec 2010 12:32:13 +1100 Date: Thu, 2 Dec 2010 12:32:13 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 3/8] xfs: bulk AIL insertion during transaction commit Subject: Re: [PATCH 3/8] xfs: bulk AIL insertion during transaction commit Message-ID: <20101202013213.GM16922@dastard> References: <1290993152-20999-1-git-send-email-david@fromorbit.com> <1290993152-20999-4-git-send-email-david@fromorbit.com> <20101130224057.GA16143@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101130224057.GA16143@infradead.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: bld-mail14.adl6.internode.on.net[150.101.137.99] X-Barracuda-Start-Time: 1291253537 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48217 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Tue, Nov 30, 2010 at 05:40:57PM -0500, Christoph Hellwig wrote: > Generally looks good, a few minor comments below: > > > +void > > +xfs_trans_committed_bulk( > > + struct xfs_ail *ailp, > > + struct xfs_log_vec *log_vector, > > + xfs_lsn_t commit_lsn, > > + int aborted) > > +{ > > +#define LGIA_SIZE 32 > > + struct xfs_log_item *lgia[LGIA_SIZE]; > > The lgia name seems a bit to obscure to me. lgia == "log item array" > What about just log_items > as variable name, and LOG_ITEM_BATCH_SIZE or similar for the size? Ok, that's easy to do. > > + spin_lock(&ailp->xa_lock); > > + xfs_trans_ail_update_bulk(ailp, lgia, LGIA_SIZE, > > + commit_lsn); > > + for (i = 0; i < LGIA_SIZE; i++) > > + IOP_UNPIN(lgia[i], 0); > > > + spin_lock(&ailp->xa_lock); > > + xfs_trans_ail_update_bulk(ailp, lgia, i, commit_lsn); > > + for (j = 0; j < i; j++) > > + IOP_UNPIN(lgia[j], 0); > > It might be worth to factor these two little sniplets into a little > helper. I thought about it, but didn't because there was more code in writing a helper. I'll do it anyway... > > > + * Bulk update version of xfs_trans_ail_update. > > That won't be a very useful comment anymore once xfs_trans_ail_update is > implemented as a wrapper around this function.. Yup, but when the wrapper is introduced the comment is updated appropriately. > > > + struct xfs_log_item **lgia, > > Same naming comment here. Will fix. Cheers, Dave. -- Dave Chinner david@fromorbit.com From SRS0+jcQm+5+fromorbit.com=david@internode.on.net Wed Dec 1 19:46:56 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB21ktbw244793 for ; Wed, 1 Dec 2010 19:46:55 -0600 X-ASG-Debug-ID: 1291254516-29f102d70000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DEB951401FAE for ; Wed, 1 Dec 2010 17:48:37 -0800 (PST) Received: from mail.internode.on.net (bld-mail19.adl2.internode.on.net [150.101.137.104]) by cuda.sgi.com with ESMTP id cu1SBKhiqWMQJm7I for ; Wed, 01 Dec 2010 17:48:37 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 47875939-1927428 for multiple; Thu, 02 Dec 2010 12:18:36 +1030 (CDT) Received: from dave by dastard with local (Exim 4.71) (envelope-from ) id 1PNyHi-0006FJ-08; Thu, 02 Dec 2010 12:48:34 +1100 Date: Thu, 2 Dec 2010 12:48:33 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 02/14] xfs: clean up log space grant functions Subject: Re: [PATCH 02/14] xfs: clean up log space grant functions Message-ID: <20101202014833.GN16922@dastard> References: <1290994712-21376-1-git-send-email-david@fromorbit.com> <1290994712-21376-3-git-send-email-david@fromorbit.com> <20101201123032.GA20378@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101201123032.GA20378@infradead.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: bld-mail19.adl2.internode.on.net[150.101.137.104] X-Barracuda-Start-Time: 1291254518 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48218 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Wed, Dec 01, 2010 at 07:30:32AM -0500, Christoph Hellwig wrote: > On Mon, Nov 29, 2010 at 12:38:20PM +1100, Dave Chinner wrote: > > From: Dave Chinner > > > > xlog_grant_log_space and xlog_regrant_log_write_space both have very > > similar structure. Both have a "wait on non-empty queue" section at > > the start, followed by a "wait for space" loop of which the contents > > are almost identical to the initial non-empty queue section. > > > > In both cases, the non-empty queue wait can be folded into the wait > > for space loop, simply by entering the loop if the queue is not > > empty and the current ticket is not on the queue. If we trigger the > > non-empty queue case, we always add ourselves to the queue, and > > hence the second and subsequent loops are always driven by the "wait > > for space" test. > > > > IOWs, both wait conditions can be folded into the one loop, removing > > a bunch of duplicated code and making it simpler to modify in > > future patches. > > I don't really like this patch. The new conditions are overly > complicated because of the desire to only go through the loop once > for the queue not empty case. In addition there's some behaviour > changes: > > - in xlog_grant_log_space we previously didn't call xlog_grant_push_ail > for the queue not empty case, and now we do. As you point out, there's no actual harm in doing that. > - in xlog_regrant_write_log_space the old version of the queue not > empty case would loop over all waiting tickets, and if we could > wake up all of them we'll skip the first wait, and given enough > free space also the second wait, while the new code always adds it > to the writeq, although it will still skip the actualy wait later. I didn't think there's any harm in that, either, because we're walking the entire queue anyway and it does not dirty any global shared cachelines we aren't already dirtying by taking the queue lock. > My recommendation would be to skip this patch for now and revisit the > area later. Ugh. That means the following 10 patches need to be reworked. > For example the superflous xlog_grant_push_ail actually > is rather harmless these days with the xfsaild threshold, so not > skipping it for the first case probably is fine in the end. Then again > the whole add to the queue just in case if it's non-empty doesn't make > much sense to me to start with. As soon as xfs_log_move_tail makes > space in the log it wakes up all tickets waiting for it anyway, so > adding us to the queue just in case seems rather inefficient, and not > overl helpful. Ok, so your main objection is the needless addition to the queue? That can be avoided easily enough via a local variable. Would that be sufficient to alleviate your concerns? Cheers, Dave. -- Dave Chinner david@fromorbit.com From SRS0+W+pQ+5+fromorbit.com=david@internode.on.net Wed Dec 1 19:47:48 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB21llGK244843 for ; Wed, 1 Dec 2010 19:47:48 -0600 X-ASG-Debug-ID: 1291254569-334500330000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BA54F1BB301 for ; Wed, 1 Dec 2010 17:49:30 -0800 (PST) Received: from mail.internode.on.net (bld-mail14.adl6.internode.on.net [150.101.137.99]) by cuda.sgi.com with ESMTP id cfYJDBJR0PX5fX3A for ; Wed, 01 Dec 2010 17:49:30 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 48851849-1927428 for multiple; Thu, 02 Dec 2010 12:19:29 +1030 (CDT) Received: from dave by dastard with local (Exim 4.71) (envelope-from ) id 1PNyIa-0006Fd-2s; Thu, 02 Dec 2010 12:49:28 +1100 Date: Thu, 2 Dec 2010 12:49:28 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 03/14] xfs: convert log grant heads to LSN notation Subject: Re: [PATCH 03/14] xfs: convert log grant heads to LSN notation Message-ID: <20101202014927.GO16922@dastard> References: <1290994712-21376-1-git-send-email-david@fromorbit.com> <1290994712-21376-4-git-send-email-david@fromorbit.com> <20101201124234.GB612@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101201124234.GB612@infradead.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: bld-mail14.adl6.internode.on.net[150.101.137.99] X-Barracuda-Start-Time: 1291254571 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48217 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Wed, Dec 01, 2010 at 07:42:35AM -0500, Christoph Hellwig wrote: > The patch looks good to me, but I really hate overloading the lsn types > and helpers. Just add duplicated of CYCLE_LSN/BLOCK_LSN and > xlog_assign_lsn for a new type as use them. Ok, will fix. Cheers, Dave. -- Dave Chinner david@fromorbit.com From SRS0+tXB3+5+fromorbit.com=david@internode.on.net Wed Dec 1 19:59:54 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB21xrSY245458 for ; Wed, 1 Dec 2010 19:59:53 -0600 X-ASG-Debug-ID: 1291255295-290302990000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 22EF41C85066 for ; Wed, 1 Dec 2010 18:01:35 -0800 (PST) Received: from mail.internode.on.net (bld-mail20.adl6.internode.on.net [150.101.137.105]) by cuda.sgi.com with ESMTP id qNmZFGzcJeGanLPS for ; Wed, 01 Dec 2010 18:01:35 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 3172791-1927428 for multiple; Thu, 02 Dec 2010 12:31:34 +1030 (CDT) Received: from dave by dastard with local (Exim 4.71) (envelope-from ) id 1PNyUG-0006GZ-QQ; Thu, 02 Dec 2010 13:01:32 +1100 Date: Thu, 2 Dec 2010 13:01:32 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 03/14] xfs: convert log grant heads to LSN notation Subject: Re: [PATCH 03/14] xfs: convert log grant heads to LSN notation Message-ID: <20101202020132.GP16922@dastard> References: <1290994712-21376-1-git-send-email-david@fromorbit.com> <1290994712-21376-4-git-send-email-david@fromorbit.com> <20101201130504.GA18379@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101201130504.GA18379@infradead.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: bld-mail20.adl6.internode.on.net[150.101.137.105] X-Barracuda-Start-Time: 1291255297 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48219 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Wed, Dec 01, 2010 at 08:05:04AM -0500, Christoph Hellwig wrote: > > -STATIC int xlog_space_left(xlog_t *log, int cycle, int bytes); > > +STATIC int xlog_space_left(int logsize, xfs_lsn_t tail_lsn, > > + xfs_lsn_t head); > > Looking further through the series I have to say I really hate > passing in the logsize instead of the log structure. Passing the > log pointer from higher level functions just makes a lot more sense. > > Also in this case passing the tail_lsn explicitly doesn't make any sense > - it becomes atomic later and thus there is no locking requirement for > it. What I wanted to make clear is that the calculation works on fixed values and doesn't sample values internally itself. I guess that's not important for the log size, but for stuff like the tail lsn it avoids needing to sample inside xlog_space_left() before we crack it. i.e. something like this is wrong: cycle = CYCLE_LSN(atomic64_read(&log->l_tail_lsn)); block = BLOCK_LSN(atomic64_read(&log->l_tail_lsn)); and this is correct: tail_lsn = atomic64_read(&log->l_tail_lsn); cycle = CYCLE_LSN(tail_lsn); block = BLOCK_LSN(tail_lsn); So it makes sense to me to have the value of of the tail lsn and other variables that should only be sampled once passed into the function. That avoids misunderstandings further down the track because it is obvious that the calculation works on constant values. Perhaps I should add "const" to the parameter declarations to help make my intentions clear... > > > -xlog_grant_sub_space(struct log *log, int bytes) > > +__xlog_grant_sub_space( > > + xfs_lsn_t *head, > > + int bytes, > > + int logsize) > > Same thing here - the calling convention would be a lot more regular > by still passing the log as first argument. Ok, it's only for the logsize again, but that's not the important part of the calculation... > After the factoring I also think we could cut down on the amount of > wrappers in this area. Just rename __xlog_grant_sub_space and > __xlog_grant_add_space to not have the __ prefix, and kill the wrappers > around it - they only have one or two callers, and just having two > helpers and passing the heads we're interested in is a lot simpler and > cleaner. I thought about that - my first version even did this. I thought it was easier to understand the changes if I didn't change the calling conventions for modifying the grant heads. As such, I'd prefer to make this change to the wrappers in a separate patch. Cheers, Dave. -- Dave Chinner david@fromorbit.com From SRS0+W+pQ+5+fromorbit.com=david@internode.on.net Wed Dec 1 20:00:42 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB220gOL245517 for ; Wed, 1 Dec 2010 20:00:42 -0600 X-ASG-Debug-ID: 1291255344-7a5503400000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2D67C1C851E5 for ; Wed, 1 Dec 2010 18:02:24 -0800 (PST) Received: from mail.internode.on.net (bld-mail14.adl6.internode.on.net [150.101.137.99]) by cuda.sgi.com with ESMTP id E5oDqiFFROQkHuEk for ; Wed, 01 Dec 2010 18:02:24 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 48853526-1927428 for multiple; Thu, 02 Dec 2010 12:32:23 +1030 (CDT) Received: from dave by dastard with local (Exim 4.71) (envelope-from ) id 1PNyUu-0006Gh-Ff; Thu, 02 Dec 2010 13:02:12 +1100 Date: Thu, 2 Dec 2010 13:02:12 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 04/14] xfs: use wait queues directly for log grant queues Subject: Re: [PATCH 04/14] xfs: use wait queues directly for log grant queues Message-ID: <20101202020212.GQ16922@dastard> References: <1290994712-21376-1-git-send-email-david@fromorbit.com> <1290994712-21376-5-git-send-email-david@fromorbit.com> <20101201123454.GA612@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101201123454.GA612@infradead.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: bld-mail14.adl6.internode.on.net[150.101.137.99] X-Barracuda-Start-Time: 1291255346 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48219 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Wed, Dec 01, 2010 at 07:34:54AM -0500, Christoph Hellwig wrote: > On Mon, Nov 29, 2010 at 12:38:22PM +1100, Dave Chinner wrote: > > From: Dave Chinner > > > > The log grant queues are one of the few places left using sv_t > > constructs for waiting. Convert them to use wait queues directly > > while we are cleaning up the code to move one step closer to remove > > the sv_t type from the XFS codebase. > > Doing this one separately from the other sv_t removal seems a bit > pointless. Ok, as you suggest later Iii'll just fold the other sv_t patches into this one. Cheers, Dave. -- Dave Chinner david@fromorbit.com From SRS0+fUtr+5+fromorbit.com=david@internode.on.net Wed Dec 1 20:02:57 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB222utm245616 for ; Wed, 1 Dec 2010 20:02:57 -0600 X-ASG-Debug-ID: 1291255478-7a3503430000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B138E1C851FC for ; Wed, 1 Dec 2010 18:04:39 -0800 (PST) Received: from mail.internode.on.net (bld-mail13.adl6.internode.on.net [150.101.137.98]) by cuda.sgi.com with ESMTP id 25HjJPQGDmzktmBs for ; Wed, 01 Dec 2010 18:04:39 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 48639325-1927428 for multiple; Thu, 02 Dec 2010 12:34:31 +1030 (CDT) Received: from dave by dastard with local (Exim 4.71) (envelope-from ) id 1PNyWn-0006H9-G9; Thu, 02 Dec 2010 13:04:09 +1100 Date: Thu, 2 Dec 2010 13:04:09 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 05/14] xfs: make AIL tail pushing independent of the grant lock Subject: Re: [PATCH 05/14] xfs: make AIL tail pushing independent of the grant lock Message-ID: <20101202020409.GR16922@dastard> References: <1290994712-21376-1-git-send-email-david@fromorbit.com> <1290994712-21376-6-git-send-email-david@fromorbit.com> <20101201124540.GC612@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101201124540.GC612@infradead.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: bld-mail13.adl6.internode.on.net[150.101.137.98] X-Barracuda-Start-Time: 1291255480 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48219 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Wed, Dec 01, 2010 at 07:45:40AM -0500, Christoph Hellwig wrote: > Once l_tail_lsn and l_last_sync_lsn are converted to atomic64_ts later > in the series passing them in separately becomes pointless again. Maybe > scale the patch back a bit and require the caller to hold l_grant_lock > for now, until the atomic64_t conversion happens. Same reasoning as for the change to xlog_space_left - the values should only be sampled once for correctness, which is why I pass them into the function. more "const" annotations, I guess. Cheers, Dave. -- Dave Chinner david@fromorbit.com From SRS0+Ztt8+5+fromorbit.com=david@internode.on.net Wed Dec 1 20:03:01 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB2231l0245632 for ; Wed, 1 Dec 2010 20:03:01 -0600 X-ASG-Debug-ID: 1291255483-7a4403460000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7471A1C851FE for ; Wed, 1 Dec 2010 18:04:44 -0800 (PST) Received: from mail.internode.on.net (bld-mail12.adl6.internode.on.net [150.101.137.97]) by cuda.sgi.com with ESMTP id QE2qd7gdZnmAbtmS for ; Wed, 01 Dec 2010 18:04:44 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 48487720-1927428 for multiple; Thu, 02 Dec 2010 12:34:43 +1030 (CDT) Received: from dave by dastard with local (Exim 4.71) (envelope-from ) id 1PNyXJ-0006HJ-Me; Thu, 02 Dec 2010 13:04:41 +1100 Date: Thu, 2 Dec 2010 13:04:41 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 08/14] xfs: convert log grant heads to atomic variables Subject: Re: [PATCH 08/14] xfs: convert log grant heads to atomic variables Message-ID: <20101202020441.GS16922@dastard> References: <1290994712-21376-1-git-send-email-david@fromorbit.com> <1290994712-21376-9-git-send-email-david@fromorbit.com> <20101201125920.GF612@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101201125920.GF612@infradead.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: bld-mail12.adl6.internode.on.net[150.101.137.97] X-Barracuda-Start-Time: 1291255485 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48219 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Wed, Dec 01, 2010 at 07:59:20AM -0500, Christoph Hellwig wrote: > On Mon, Nov 29, 2010 at 12:38:26PM +1100, Dave Chinner wrote: > > From: Dave Chinner > > > > Convert the log grant heads to atomic64_t types in preparation for > > converting the accounting algorithms to atomic operations. his patch > > just converts the variables; the algorithmic changes are in a > > separate patch for clarity. > > > > Signed-off-by: Dave Chinner > > --- > > fs/xfs/linux-2.6/xfs_trace.h | 18 +++++++------ > > fs/xfs/xfs_log.c | 54 +++++++++++++++++++++-------------------- > > fs/xfs/xfs_log_priv.h | 4 +- > > fs/xfs/xfs_log_recover.c | 8 +++--- > > 4 files changed, 44 insertions(+), 40 deletions(-) > > > > diff --git a/fs/xfs/linux-2.6/xfs_trace.h b/fs/xfs/linux-2.6/xfs_trace.h > > index d2cdc85..68c3bdd 100644 > > --- a/fs/xfs/linux-2.6/xfs_trace.h > > +++ b/fs/xfs/linux-2.6/xfs_trace.h > > @@ -768,8 +768,8 @@ DECLARE_EVENT_CLASS(xfs_loggrant_class, > > __field(unsigned int, flags) > > __field(void *, reserveq) > > __field(void *, writeq) > > - __field(xfs_lsn_t, grant_reserve_lsn) > > - __field(xfs_lsn_t, grant_write_lsn) > > + __field(xfs_lsn_t, grant_reserve_head) > > + __field(xfs_lsn_t, grant_write_head) > > What about just naming them _head from the beginning? That would > be a tad cleaner. Same for the actual variables in the log, even > if they change the type here. Will do. Cheers, Dave. -- Dave Chinner david@fromorbit.com From SRS0+W+pQ+5+fromorbit.com=david@internode.on.net Wed Dec 1 20:08:52 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_00,SUBJ_TICKET autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB228pYl245854 for ; Wed, 1 Dec 2010 20:08:52 -0600 X-ASG-Debug-ID: 1291255833-254701ef0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 697681B9487 for ; Wed, 1 Dec 2010 18:10:34 -0800 (PST) Received: from mail.internode.on.net (bld-mail16.adl2.internode.on.net [150.101.137.101]) by cuda.sgi.com with ESMTP id Aye7sVXZM3MCP7qG for ; Wed, 01 Dec 2010 18:10:34 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 48385437-1927428 for multiple; Thu, 02 Dec 2010 12:40:32 +1030 (CDT) Received: from dave by dastard with local (Exim 4.71) (envelope-from ) id 1PNycx-0006Ho-A9; Thu, 02 Dec 2010 13:10:31 +1100 Date: Thu, 2 Dec 2010 13:10:31 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 09/14] xfs: introduce new locks for the log grant ticket wait queues Subject: Re: [PATCH 09/14] xfs: introduce new locks for the log grant ticket wait queues Message-ID: <20101202021031.GT16922@dastard> References: <1290994712-21376-1-git-send-email-david@fromorbit.com> <1290994712-21376-10-git-send-email-david@fromorbit.com> <20101201131208.GA22455@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101201131208.GA22455@infradead.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: bld-mail16.adl2.internode.on.net[150.101.137.101] X-Barracuda-Start-Time: 1291255835 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48219 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Wed, Dec 01, 2010 at 08:12:08AM -0500, Christoph Hellwig wrote: > > + /* co-ordinate with xfs_log_force_shutdown */ > > + if (XLOG_FORCED_SHUTDOWN(log)) { > > + spin_unlock(&log->l_grant_reserve_lock); > > + goto error_return; > > + } > > Where is this coming from? Otherwise the patch looks good to me. To handles the race condition between xfs_log_force_shutdown() clearing all the tickets off the queue and a racing log reserve that had already checked the shutdown flag and was spinning waiting for the reserve lock to add the ticket to the queue. The race condition is documented in xfs_log_force_shutdown()... Cheers, Dave. -- Dave Chinner david@fromorbit.com From SRS0+W+pQ+5+fromorbit.com=david@internode.on.net Wed Dec 1 20:09:50 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB229okA245896 for ; Wed, 1 Dec 2010 20:09:50 -0600 X-ASG-Debug-ID: 1291255892-7a3703750000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4566B1C8525D for ; Wed, 1 Dec 2010 18:11:33 -0800 (PST) Received: from mail.internode.on.net (bld-mail14.adl6.internode.on.net [150.101.137.99]) by cuda.sgi.com with ESMTP id PXiEW8XjQEDNhbnk for ; Wed, 01 Dec 2010 18:11:33 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 48854960-1927428 for multiple; Thu, 02 Dec 2010 12:41:32 +1030 (CDT) Received: from dave by dastard with local (Exim 4.71) (envelope-from ) id 1PNydu-0006Hx-Mo; Thu, 02 Dec 2010 13:11:30 +1100 Date: Thu, 2 Dec 2010 13:11:30 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 10/14] xfs: convert grant head manipulations to lockless algorithm Subject: Re: [PATCH 10/14] xfs: convert grant head manipulations to lockless algorithm Message-ID: <20101202021130.GU16922@dastard> References: <1290994712-21376-1-git-send-email-david@fromorbit.com> <1290994712-21376-11-git-send-email-david@fromorbit.com> <20101201131513.GB22455@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101201131513.GB22455@infradead.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: bld-mail14.adl6.internode.on.net[150.101.137.99] X-Barracuda-Start-Time: 1291255894 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0021 1.0000 -2.0070 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.01 X-Barracuda-Spam-Status: No, SCORE=-2.01 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48219 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Wed, Dec 01, 2010 at 08:15:13AM -0500, Christoph Hellwig wrote: > On Mon, Nov 29, 2010 at 12:38:28PM +1100, Dave Chinner wrote: > > From: Dave Chinner > > > > The only thing that the grant lock remains to protect is the grant head > > manipulations when adding or removing space from the log. These calculations > > are already based on atomic variables, so we can already update them safely > > without locks. However, the grant head manpulations require atomic multi-step > > calculations to be executed, which the algorithms currently don't allow. > > > > To make these multi-step calculations atomic, convert the algorithms to > > compare-and-exchange loops on the atomic variables. That is, we sample the old > > value, perform the calculation and use atomic64_cmpxchg() to attempt to update > > the head with the new value. If the head has not changed since we sampled it, > > it will succeed and we are done. Otherwise, we rerun the calculation again from > > a new sample of the head. > > > > This allows us to remove the grant lock from around all the grant head space > > manipulations, and that effectively removes the grant lock from the log > > completely. > > > > Signed-off-by: Dave Chinner .... > > @@ -3478,11 +3485,18 @@ xlog_verify_dest_ptr( > > xlog_panic("xlog_verify_dest_ptr: invalid ptr"); > > } > > > > +/* > > + * XXX: because we cannot atomically sample both the reserve and write heads, > > + * we cannot verify them reliably as they may be sampled in the middle of > > + * racing modifications. Hence just taking snapshots of the heads can give an > > + * incorrect view of the state of log. Hence just disable this check for now. > > + */ > > STATIC void > > xlog_verify_grant_head( > > I can't see any way to keep this check with the atomic reserve/write > heads, so we might as well remove it entirely. Ok, will do. Cheers, Dave. -- Dave Chinner david@fromorbit.com From SRS0+tXB3+5+fromorbit.com=david@internode.on.net Wed Dec 1 20:14:36 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB22EapY246391 for ; Wed, 1 Dec 2010 20:14:36 -0600 X-ASG-Debug-ID: 1291256177-509401880000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id ABCC7160ADB3 for ; Wed, 1 Dec 2010 18:16:18 -0800 (PST) Received: from mail.internode.on.net (bld-mail20.adl6.internode.on.net [150.101.137.105]) by cuda.sgi.com with ESMTP id DssgHF5xm04GlEHr for ; Wed, 01 Dec 2010 18:16:18 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 3174778-1927428 for multiple; Thu, 02 Dec 2010 12:46:11 +1030 (CDT) Received: from dave by dastard with local (Exim 4.71) (envelope-from ) id 1PNyiP-0006IN-JK; Thu, 02 Dec 2010 13:16:09 +1100 Date: Thu, 2 Dec 2010 13:16:09 +1100 From: Dave Chinner To: Amit Sahrawat Cc: Eric Sandeen , xfs@oss.sgi.com, sandeen-xfs@sandeen.net X-ASG-Orig-Subj: Re: XFS file system corruption(Return Bad Transaction) kernel - 2.6.34 Subject: Re: XFS file system corruption(Return Bad Transaction) kernel - 2.6.34 Message-ID: <20101202021609.GV16922@dastard> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: bld-mail20.adl6.internode.on.net[150.101.137.105] X-Barracuda-Start-Time: 1291256179 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48220 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Wed, Dec 01, 2010 at 12:44:58PM +0530, Amit Sahrawat wrote: > Dear Member, > > I am getting following corruption on XFS formatted disk during a simple copy > operation: > sd 9:0:0:0: Attached scsi removable disk sdc > sd 9:0:0:0: Attached scsi generic sg2 type 0 > XFS mounting filesystem sdc2 > Starting XFS recovery on filesystem: sdc2 (logdev: internal) > XFS: xlog_recover_process_data: bad transaction > XFS: log mount/recovery failed: error 5 > XFS: log mount failed > [root@localhost TEGRA]# "TEGRA" - You're running on an ARM device? If so, what kernel are you running? i.e. does it have the VIVT cache aliasing fixes in it? Cheers, Dave. -- Dave Chinner david@fromorbit.com From SRS0+W+pQ+5+fromorbit.com=david@internode.on.net Wed Dec 1 20:19:36 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB22Ja0P246609 for ; Wed, 1 Dec 2010 20:19:36 -0600 X-ASG-Debug-ID: 1291256478-1cf802aa0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0CD4A1BAC59 for ; Wed, 1 Dec 2010 18:21:18 -0800 (PST) Received: from mail.internode.on.net (bld-mail15.adl6.internode.on.net [150.101.137.100]) by cuda.sgi.com with ESMTP id rAc5VXRMhTeuidCo for ; Wed, 01 Dec 2010 18:21:18 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 37000957-1927428 for multiple; Thu, 02 Dec 2010 12:51:17 +1030 (CDT) Received: from dave by dastard with local (Exim 4.71) (envelope-from ) id 1PNynM-0006JD-81; Thu, 02 Dec 2010 13:21:16 +1100 Date: Thu, 2 Dec 2010 13:21:16 +1100 From: Dave Chinner To: Alex Elder Cc: dchinner@redhat.com, XFS Mailing List X-ASG-Orig-Subj: Re: xfstests 065 failures Subject: Re: xfstests 065 failures Message-ID: <20101202022116.GW16922@dastard> References: <1291235379.2556.28.camel@doink> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1291235379.2556.28.camel@doink> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: bld-mail15.adl6.internode.on.net[150.101.137.100] X-Barracuda-Start-Time: 1291256480 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0015 1.0000 -2.0115 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.01 X-Barracuda-Spam-Status: No, SCORE=-2.01 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48221 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Wed, Dec 01, 2010 at 02:29:39PM -0600, Alex Elder wrote: > Dave, you were asking on IRC about test 065 failures. > I asked Bill Kendall about it and he bisected to find > that the commit below seems to be where the problems > started. I believe the problem is that one of the > times is not updated properly when renaming the file > "addedfile4". Here are the commands that might affect > that file in test 065: > > mv addeddir4/addedfile5 addeddir4/addedfile4 > mv addeddir4 addeddir6 > > I glanced at the commit and saw nothing obviously > wrong, but at the moment I can't really dig into > it any deeper so I thought I'd report what Bill > found so others could look. Yeah, I know that this patch was the cause, and IIRC it only affects a hard linked directory. What I found is that the iterative dump actually contains all the correct changes (the restore part of the test does not fail) - it's just that the dump image table of contents does not contain the all the changes. I haven't tracked down why the dump TOC does not contain a modification that is actually in the dump yet.... Cheers, Dave. -- Dave Chinner david@fromorbit.com From amit.sahrawat83@gmail.com Wed Dec 1 21:38:26 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.2 required=5.0 tests=BAYES_00,FREEMAIL_FROM, HTML_MESSAGE,J_CHICKENPOX_45,T_DKIM_INVALID autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB23cPjH250034 for ; Wed, 1 Dec 2010 21:38:26 -0600 X-ASG-Debug-ID: 1291261209-57e202630000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-qy0-f174.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 674DB1C8632C for ; Wed, 1 Dec 2010 19:40:09 -0800 (PST) Received: from mail-qy0-f174.google.com (mail-qy0-f174.google.com [209.85.216.174]) by cuda.sgi.com with ESMTP id H01HP3eCEGbY5XD7 for ; Wed, 01 Dec 2010 19:40:09 -0800 (PST) Received: by qyk11 with SMTP id 11so3581544qyk.5 for ; Wed, 01 Dec 2010 19:40:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=3eN9FK9Or81wtpTdaaWuXhb7tYTYejpWdMFL4SfU184=; b=Ot6PbvfXc/l1zqKbxX+LM5oL7Xgoi7r7KC8FlOG9t9juebnWWbRlUizVSdjiNDr63Y r9Asgaiw6ueQWbG7F7yBxwIXY5SpcXNw1wieA090u/iwUJ6gqzVGa9+pVNkTiYikaq47 15wpf8a5t1rOxdIEaIAQ+4jOvewox+bsYqRc8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=sWeGKdIUHbL+7XcpfPssn87LoXu4l0Mr3n8sY5/8ekITIHKVKY/1hoG9Ghx/DnJgoE c0wQ/UeAYaWn7hq6jEqDKy9dNMovvOMeyoPB2bd1xUdpdasifJtCiqW2kc4TtUfufVKJ FsYOG5Dc837z35Pw8pVMAaCRbUDWthxV1A+/s= MIME-Version: 1.0 Received: by 10.229.227.12 with SMTP id iy12mr8128080qcb.101.1291261208805; Wed, 01 Dec 2010 19:40:08 -0800 (PST) Received: by 10.220.194.3 with HTTP; Wed, 1 Dec 2010 19:40:08 -0800 (PST) In-Reply-To: <4CF661C7.2020103@sandeen.net> References: <4CF661C7.2020103@sandeen.net> Date: Thu, 2 Dec 2010 09:10:08 +0530 Message-ID: X-ASG-Orig-Subj: Re: XFS file system corruption(Return Bad Transaction) kernel - 2.6.34 Subject: Re: XFS file system corruption(Return Bad Transaction) kernel - 2.6.34 From: Amit Sahrawat To: Eric Sandeen Cc: xfs@oss.sgi.com, sandeen-xfs@sandeen.net, david@fromorbit.com Content-Type: multipart/alternative; boundary=00163630f435a9c7700496652d68 X-Barracuda-Connect: mail-qy0-f174.google.com[209.85.216.174] X-Barracuda-Start-Time: 1291261209 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=DKIM_SIGNED, DKIM_VERIFIED, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48224 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --00163630f435a9c7700496652d68 Content-Type: text/plain; charset=ISO-8859-1 While the copy operation is in progress, simply unplug the usb device and then replug. The issue can be seen from XFS (2.6.31) onwards, I am trying to figure out the changes between 2.6.30.9 and 2.6.31. One thing I noticed is - there is difference in speed for 2 versions - in case of 2.6.30.9 if I remove the USB within '5' seconds - I can see the file being created at the destination and some data written, while in case of 2.6.31(onwards), it takes around 20 seconds to get some data to disk. I am using MIPS at the moment with VIPT(fixes included) Please let me know if this information is useful. Thanks, Amit Sahrawat On Wed, Dec 1, 2010 at 8:25 PM, Eric Sandeen wrote: > On 12/1/10 1:14 AM, Amit Sahrawat wrote: > > Dear Member, > > > > I am getting following corruption on XFS formatted disk during a simple > copy operation: > > sd 9:0:0:0: Attached scsi removable disk sdc > > sd 9:0:0:0: Attached scsi generic sg2 type 0 > > XFS mounting filesystem sdc2 > > Starting XFS recovery on filesystem: sdc2 (logdev: internal) > > XFS: xlog_recover_process_data: bad transaction > > XFS: log mount/recovery failed: error 5 > > XFS: log mount failed > > hm, that's not a simple copy operation, that is a mount failing; > your log appears to be corrupted. > > offhand I'm going to blame it on having a write cache enabled > on your drive, and having barriers either off, or not working > properly. > > -Eric > > --00163630f435a9c7700496652d68 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
While the copy operation is in progress, simply unplug the usb device = and then replug.
The issue can be seen from XFS (2.6.31) onwards, I am trying to figure= out the changes between 2.6.30.9 and 2.6.31.
One thing I noticed is - there is difference in speed for 2 versions -= in case of 2.6.30.9 if I remove the USB within '5' seconds - I can= see the file being created at the destination and some data written, while= in case of 2.6.31(onwards), it takes=A0around 20 seconds to get some data = to disk.
I am using MIPS at the moment with VIPT(fixes included)

Please let me know if this information is useful.
=A0
Thanks,
Amit Sahrawat
On Wed, Dec 1, 2010 at 8:25 PM, Eric Sandeen <sandeen@sandeen.n= et> wrote:
On 12/1/10 1:14 AM, Amit Sahrawat wrote:
> Dear Mem= ber,
>
> I am getting following corruption on XFS formatted dis= k during a simple copy operation:
> sd 9:0:0:0: Attached scsi removab= le disk sdc
> sd 9:0:0:0: Attached scsi generic sg2 type 0
> XFS mounting file= system sdc2
> Starting XFS recovery on filesystem: sdc2 (logdev: inte= rnal)
> XFS: xlog_recover_process_data: bad transaction
> XFS: = log mount/recovery failed: error 5
> XFS: log mount failed

hm, that's not a simple copy op= eration, that is a mount failing;
your log appears to be corrupted.
<= br>offhand I'm going to blame it on having a write cache enabled
on your drive, and having barriers either off, or not working
properly.<= br>
-Eric


--00163630f435a9c7700496652d68-- From amit.sahrawat83@gmail.com Wed Dec 1 21:39:59 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.2 required=5.0 tests=BAYES_00,FREEMAIL_FROM, HTML_MESSAGE,J_CHICKENPOX_55,T_DKIM_INVALID autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB23dw4Y250093 for ; Wed, 1 Dec 2010 21:39:59 -0600 X-ASG-Debug-ID: 1291261301-1db9011e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-qy0-f174.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 809E5160AE7B for ; Wed, 1 Dec 2010 19:41:41 -0800 (PST) Received: from mail-qy0-f174.google.com (mail-qy0-f174.google.com [209.85.216.174]) by cuda.sgi.com with ESMTP id iNVnWkD3UcJXTpfw for ; Wed, 01 Dec 2010 19:41:41 -0800 (PST) Received: by qyk11 with SMTP id 11so3582780qyk.5 for ; Wed, 01 Dec 2010 19:41:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=/oV4NFdpueP4EM2eDGGI0WTQZ6ke8FMxCwNjm9LQ0pg=; b=SzzPS/z2+IYCvItgUr9nFxzk3k1OQzE90MfgYTyB/93p5JHdbQB4qjxtjIMwoLjnyg R6Xy8qi3lgL6LE5tx31MC6U4Qkkdd0KbZf5Xfsh1rk6mLgxV1T4vvJIAmqyuu+gEZHt8 zCwRmj1z1upDXaJgBsqIsxyazAlhIYMU3nsHM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tlq4Hx0PWQIcRDDOdlICdojHgkLSoZTfrU+4juzRWOT56QSYgygoo7zD5q4YvGcdum tBG28TqlA5B1vHds9EHIG3kgS/Nkg5aBHvdseO0WPIbXHRc6p9dK2vbmplEc6SiH4o+C hh5Hl4aC96luFAvnwbXfPXWSBhbiOO1HrG8iM= MIME-Version: 1.0 Received: by 10.229.227.12 with SMTP id iy12mr8129210qcb.101.1291261301021; Wed, 01 Dec 2010 19:41:41 -0800 (PST) Received: by 10.220.194.3 with HTTP; Wed, 1 Dec 2010 19:41:40 -0800 (PST) In-Reply-To: <20101202021609.GV16922@dastard> References: <20101202021609.GV16922@dastard> Date: Thu, 2 Dec 2010 09:11:40 +0530 Message-ID: X-ASG-Orig-Subj: Re: XFS file system corruption(Return Bad Transaction) kernel - 2.6.34 Subject: Re: XFS file system corruption(Return Bad Transaction) kernel - 2.6.34 From: Amit Sahrawat To: Dave Chinner Cc: Eric Sandeen , xfs@oss.sgi.com, sandeen-xfs@sandeen.net Content-Type: multipart/alternative; boundary=00163630f43528de3504966533b4 X-Barracuda-Connect: mail-qy0-f174.google.com[209.85.216.174] X-Barracuda-Start-Time: 1291261302 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=DKIM_SIGNED, DKIM_VERIFIED, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48226 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --00163630f43528de3504966533b4 Content-Type: text/plain; charset=ISO-8859-1 "TEGRA" by mistake happended to be the name of directory where I maintained logs :) I am using MIPS with VIPT cache(fixes included - regarding bad client id). Thanks, Amit Sahrawat On Thu, Dec 2, 2010 at 7:46 AM, Dave Chinner wrote: > On Wed, Dec 01, 2010 at 12:44:58PM +0530, Amit Sahrawat wrote: > > Dear Member, > > > > I am getting following corruption on XFS formatted disk during a simple > copy > > operation: > > sd 9:0:0:0: Attached scsi removable disk sdc > > sd 9:0:0:0: Attached scsi generic sg2 type 0 > > XFS mounting filesystem sdc2 > > Starting XFS recovery on filesystem: sdc2 (logdev: internal) > > XFS: xlog_recover_process_data: bad transaction > > XFS: log mount/recovery failed: error 5 > > XFS: log mount failed > > [root@localhost TEGRA]# > > "TEGRA" - You're running on an ARM device? If so, what kernel are > you running? i.e. does it have the VIVT cache aliasing fixes in it? > > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com > --00163630f43528de3504966533b4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
"TEGRA" by mistake happended to be the name of directory whe= re I maintained logs :)
I am using MIPS with VIPT cache(fixes included - regarding bad client = id).
=A0
=A0
Thanks,
Amit Sahrawat

On Thu, Dec 2, 2010 at 7:46 AM, Dave Chinner <david@fromorbit.c= om> wrote:
On Wed, Dec 01, 2010 at 12:44:58PM +0530, Amit Sahrawat w= rote:
> Dear Member,
>
> I am getting following corruptio= n on XFS formatted disk during a simple copy
> operation:
> sd = 9:0:0:0: Attached scsi removable disk sdc
> sd 9:0:0:0: Attached scsi generic sg2 type 0
> XFS mounting file= system sdc2
> Starting XFS recovery on filesystem: sdc2 (logdev: inte= rnal)
> XFS: xlog_recover_process_data: bad transaction
> XFS: = log mount/recovery failed: error 5
> XFS: log mount failed
> [root@localhost TEGRA]#

&qu= ot;TEGRA" - You're running on an ARM device? If so, what kernel ar= e
you running? i.e. does it have the VIVT cache aliasing fixes in it?
Cheers,

Dave.
--
Dave Chinner
<= a href=3D"mailto:david@fromorbit.com">david@fromorbit.com

--00163630f43528de3504966533b4-- From sandeen@sandeen.net Wed Dec 1 21:55:15 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_45 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB23tEPA250836 for ; Wed, 1 Dec 2010 21:55:15 -0600 X-ASG-Debug-ID: 1291262217-7d0e00ce0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6B1B81C81737 for ; Wed, 1 Dec 2010 19:56:57 -0800 (PST) Received: from mail.sandeen.net (64-131-28-21.usfamily.net [64.131.28.21]) by cuda.sgi.com with ESMTP id edUj8bnxJUBrOgp2 for ; Wed, 01 Dec 2010 19:56:57 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sandeen.net (Postfix) with ESMTP id 204F648E8B05; Wed, 1 Dec 2010 21:56:57 -0600 (CST) Message-ID: <4CF71907.60803@sandeen.net> Date: Wed, 01 Dec 2010 21:56:55 -0600 From: Eric Sandeen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Amit Sahrawat CC: xfs@oss.sgi.com, sandeen-xfs@sandeen.net, david@fromorbit.com X-ASG-Orig-Subj: Re: XFS file system corruption(Return Bad Transaction) kernel - 2.6.34 Subject: Re: XFS file system corruption(Return Bad Transaction) kernel - 2.6.34 References: <4CF661C7.2020103@sandeen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: 64-131-28-21.usfamily.net[64.131.28.21] X-Barracuda-Start-Time: 1291262218 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48227 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 12/1/10 9:40 PM, Amit Sahrawat wrote: > While the copy operation is in progress, simply unplug the usb device and then replug. that's not a simple copy operation either ;) > The issue can be seen from XFS (2.6.31) onwards, I am trying to figure out the changes between 2.6.30.9 and 2.6.31. If you have a regression, perhaps you can do: # git bisect start v2.6.31 v2.6.30 fs/xfs and methodically test the changes in between. -Eric > One thing I noticed is - there is difference in speed for 2 versions - in case of 2.6.30.9 if I remove the USB within '5' seconds - I can see the file being created at the destination and some data written, while in case of 2.6.31(onwards), it takes around 20 seconds to get some data to disk. > I am using MIPS at the moment with VIPT(fixes included) > > Please let me know if this information is useful. > > Thanks, > Amit Sahrawat > On Wed, Dec 1, 2010 at 8:25 PM, Eric Sandeen > wrote: > > On 12/1/10 1:14 AM, Amit Sahrawat wrote: > > Dear Member, > > > > I am getting following corruption on XFS formatted disk during a simple copy operation: > > sd 9:0:0:0: Attached scsi removable disk sdc > > sd 9:0:0:0: Attached scsi generic sg2 type 0 > > XFS mounting filesystem sdc2 > > Starting XFS recovery on filesystem: sdc2 (logdev: internal) > > XFS: xlog_recover_process_data: bad transaction > > XFS: log mount/recovery failed: error 5 > > XFS: log mount failed > > hm, that's not a simple copy operation, that is a mount failing; > your log appears to be corrupted. > > offhand I'm going to blame it on having a write cache enabled > on your drive, and having barriers either off, or not working > properly. > > -Eric > > From amit.sahrawat83@gmail.com Wed Dec 1 22:07:36 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.2 required=5.0 tests=BAYES_00,FREEMAIL_FROM, HTML_MESSAGE,J_CHICKENPOX_45,T_DKIM_INVALID autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB247aI5251339 for ; Wed, 1 Dec 2010 22:07:36 -0600 X-ASG-Debug-ID: 1291262959-082d00e60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-qy0-f181.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BE4C21B9F2F for ; Wed, 1 Dec 2010 20:09:19 -0800 (PST) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.216.181]) by cuda.sgi.com with ESMTP id mntLUYW32B51YOtZ for ; Wed, 01 Dec 2010 20:09:19 -0800 (PST) Received: by qyk12 with SMTP id 12so8736908qyk.5 for ; Wed, 01 Dec 2010 20:09:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=uCP83ARkYvV1ZZoqbtmShdh0PxECl9B3lbsLA8mjFrQ=; b=KPoL3NoOOTRtzI6VwG1rSUKufOGEBQag3jBhwNhXAsOmCt8KgUJyqaMpjM3RCmLwWz UZRXiHqDMQNBkUYTtkcoc5/w4BXPVFV7ety7GXy07h80v0sdb7Z4QEgBm51BDz+8W1K3 nNLjNAKGFiMYloDEcnM+CZISmYIiyLaKrp0PY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FXIrZ9cXftbKYwGawTwNUC6CKZIbKzSBEaaZY2QivcTrTWgFrwqOSRnFkYyGP1n0Ba ttFIiPmTxX5VhI8cZG2LbKHh04eLAq/8OvI4Dj21kxC+2ZMzzB1Fn8FqiYnqhzXQ8Hes VcSYd+A5vAVrxL0x2xZw9jcxD6zHklzV+udW4= MIME-Version: 1.0 Received: by 10.224.54.72 with SMTP id p8mr8712402qag.126.1291262958762; Wed, 01 Dec 2010 20:09:18 -0800 (PST) Received: by 10.220.194.3 with HTTP; Wed, 1 Dec 2010 20:09:18 -0800 (PST) In-Reply-To: <4CF71907.60803@sandeen.net> References: <4CF661C7.2020103@sandeen.net> <4CF71907.60803@sandeen.net> Date: Thu, 2 Dec 2010 09:39:18 +0530 Message-ID: X-ASG-Orig-Subj: Re: XFS file system corruption(Return Bad Transaction) kernel - 2.6.34 Subject: Re: XFS file system corruption(Return Bad Transaction) kernel - 2.6.34 From: Amit Sahrawat To: Eric Sandeen Cc: xfs@oss.sgi.com, sandeen-xfs@sandeen.net, david@fromorbit.com Content-Type: multipart/alternative; boundary=0015175caa80f7fa6804966595a2 X-Barracuda-Connect: mail-qy0-f181.google.com[209.85.216.181] X-Barracuda-Start-Time: 1291262959 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=DKIM_SIGNED, DKIM_VERIFIED, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48227 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --0015175caa80f7fa6804966595a2 Content-Type: text/plain; charset=ISO-8859-1 yes, thats the only approach at the moment which can help. I am doubting the changes related with the disk commit, but I am not sure. Thanks, Amit Sahrawat On Thu, Dec 2, 2010 at 9:26 AM, Eric Sandeen wrote: > On 12/1/10 9:40 PM, Amit Sahrawat wrote: > > While the copy operation is in progress, simply unplug the usb device and > then replug. > > that's not a simple copy operation either ;) > > > The issue can be seen from XFS (2.6.31) onwards, I am trying to figure > out the changes between 2.6.30.9 and 2.6.31. > > If you have a regression, perhaps you can do: > > # git bisect start v2.6.31 v2.6.30 fs/xfs > > and methodically test the changes in between. > > -Eric > > > One thing I noticed is - there is difference in speed for 2 versions - in > case of 2.6.30.9 if I remove the USB within '5' seconds - I can see the file > being created at the destination and some data written, while in case of > 2.6.31(onwards), it takes around 20 seconds to get some data to disk. > > I am using MIPS at the moment with VIPT(fixes included) > > > > Please let me know if this information is useful. > > > > Thanks, > > Amit Sahrawat > > On Wed, Dec 1, 2010 at 8:25 PM, Eric Sandeen sandeen@sandeen.net>> wrote: > > > > On 12/1/10 1:14 AM, Amit Sahrawat wrote: > > > Dear Member, > > > > > > I am getting following corruption on XFS formatted disk during a > simple copy operation: > > > sd 9:0:0:0: Attached scsi removable disk sdc > > > sd 9:0:0:0: Attached scsi generic sg2 type 0 > > > XFS mounting filesystem sdc2 > > > Starting XFS recovery on filesystem: sdc2 (logdev: internal) > > > XFS: xlog_recover_process_data: bad transaction > > > XFS: log mount/recovery failed: error 5 > > > XFS: log mount failed > > > > hm, that's not a simple copy operation, that is a mount failing; > > your log appears to be corrupted. > > > > offhand I'm going to blame it on having a write cache enabled > > on your drive, and having barriers either off, or not working > > properly. > > > > -Eric > > > > > > --0015175caa80f7fa6804966595a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
yes, thats the only approach at the moment which can help. I am doubti= ng the changes related with the disk commit, but I=A0am not sure.
=A0
Thanks,
Amit Sahrawat

On Thu, Dec 2, 2010 at 9:26 AM, Eric Sandeen <sandeen@sandeen.n= et> wrote:
On 12/1/10 9:40 PM, Amit Sahrawat wrote:
> While th= e copy operation is in progress, simply unplug the usb device and then repl= ug.

that's not a simple copy operation either ;)

> The issue can be seen from XFS (2.6.31) onwards,= I am trying to figure out the changes between 2.6.30.9 and 2.6.31.

=
If you have a regression, perhaps you can do:

# git bisect sta= rt v2.6.31 v2.6.30 fs/xfs

and methodically test the changes in between.

-Eric

> One thing I noticed is - there is difference in = speed for 2 versions - in case of 2.6.30.9 if I remove the USB within '= 5' seconds - I can see the file being created at the destination and so= me data written, while in case of 2.6.31(onwards), it takes around 20 secon= ds to get some data to disk.
> I am using MIPS at the moment with VIPT(fixes included)
>
>= ; Please let me know if this information is useful.
>
> Thanks,=
> Amit Sahrawat
> On Wed, Dec 1, 2010 at 8:25 PM, Eric Sandeen <sandeen@sandeen.net <mailto:sandeen@sandeen.net>> wrote: >
> =A0 =A0 On 12/1/10 1:14 AM, Amit Sahrawat wrote:
> =A0 = =A0 > Dear Member,
> =A0 =A0 >
> =A0 =A0 > I am gettin= g following corruption on XFS formatted disk during a simple copy operation= :
> =A0 =A0 > sd 9:0:0:0: Attached scsi removable disk sdc
> =A0 =A0 > sd 9:0:0:0: Attached scsi generic sg2 type 0
> =A0 = =A0 > XFS mounting filesystem sdc2
> =A0 =A0 > Starting XFS rec= overy on filesystem: sdc2 (logdev: internal)
> =A0 =A0 > XFS: xlog= _recover_process_data: bad transaction
> =A0 =A0 > XFS: log mount/recovery failed: error 5
> =A0 =A0 &= gt; XFS: log mount failed
>
> =A0 =A0 hm, that's not a simp= le copy operation, that is a mount failing;
> =A0 =A0 your log appear= s to be corrupted.
>
> =A0 =A0 offhand I'm going to blame it on having a write ca= che enabled
> =A0 =A0 on your drive, and having barriers either off, = or not working
> =A0 =A0 properly.
>
> =A0 =A0 -Eric
&= gt;
>


--0015175caa80f7fa6804966595a2-- From SRS0+W+pQ+5+fromorbit.com=david@internode.on.net Wed Dec 1 22:11:50 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB24Bn5c251500 for ; Wed, 1 Dec 2010 22:11:50 -0600 X-ASG-Debug-ID: 1291263211-1da102870000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3867C160B415 for ; Wed, 1 Dec 2010 20:13:31 -0800 (PST) Received: from mail.internode.on.net (bld-mail18.adl2.internode.on.net [150.101.137.103]) by cuda.sgi.com with ESMTP id wCGnQxD6bHUsRVZq for ; Wed, 01 Dec 2010 20:13:31 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 48229173-1927428 for multiple; Thu, 02 Dec 2010 14:43:24 +1030 (CDT) Received: from dave by dastard with local (Exim 4.71) (envelope-from ) id 1PO0Xg-0006Qu-5j; Thu, 02 Dec 2010 15:13:12 +1100 Date: Thu, 2 Dec 2010 15:13:12 +1100 From: Dave Chinner To: Amit Sahrawat Cc: Eric Sandeen , xfs@oss.sgi.com, sandeen-xfs@sandeen.net X-ASG-Orig-Subj: Re: XFS file system corruption(Return Bad Transaction) kernel - 2.6.34 Subject: Re: XFS file system corruption(Return Bad Transaction) kernel - 2.6.34 Message-ID: <20101202041312.GX16922@dastard> References: <4CF661C7.2020103@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: bld-mail18.adl2.internode.on.net[150.101.137.103] X-Barracuda-Start-Time: 1291263213 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48228 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Dec 02, 2010 at 09:10:08AM +0530, Amit Sahrawat wrote: > While the copy operation is in progress, simply unplug the usb device and > then replug. That's pretty much a guaranteed recipe for data and filesystem corruption regardless of the filesystem you are using. Even if you are lucky enough that there was is no IO being issued while the device is unplugged, what guarantee is there that the device even comes back with the same device name? Further, if the device is usb powered, there is no guarantee that the drive caches were flushed correctly before the unplug so random log and metadata corruptions are definitely possible. Cheers, Dave. -- Dave Chinner david@fromorbit.com From amit.sahrawat83@gmail.com Wed Dec 1 22:37:07 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_00,FREEMAIL_FROM, HTML_MESSAGE,T_DKIM_INVALID autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB24b6Ds254156 for ; Wed, 1 Dec 2010 22:37:07 -0600 X-ASG-Debug-ID: 1291264730-738d035d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-qy0-f181.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9BF711B726B for ; Wed, 1 Dec 2010 20:38:50 -0800 (PST) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.216.181]) by cuda.sgi.com with ESMTP id ZRaJN3asFSpqn6Ac for ; Wed, 01 Dec 2010 20:38:50 -0800 (PST) Received: by qyk12 with SMTP id 12so8761266qyk.5 for ; Wed, 01 Dec 2010 20:38:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=7giLKChMisuw7WvE9okr4pVIv3jUNUrYns1QzEBQGUI=; b=p7JWWetSO9JHzm0ughghPpre3ZLJONc0ecPtSJmNCY8Xcgs7YovVfShowSf94N+bFA vrlX0wVNK41B7nTGCf4itbBPB13C077BEqVp7T+QY1SG1kaXv6944QSkA/wkM5OYB477 1GU1A9VFzvoRwMF47CGoM/bnMDAimHohMYAHo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dMjeilD2oq5U1Bui0QDvUPaW6QEBoFh1PvXb7QtrQtstI8TwKn6HKnTBRqqvODfhJr 6A28sAmAMA8iFNcQ7ifgtKmABROpnjbHf0/ZLeJTrj/PD+zWe7GUlNZ8Y+5gbeCCX6wM 6wwpZpL31XgmDX63qtCG1GMpawMefR3kyIAWY= MIME-Version: 1.0 Received: by 10.224.54.72 with SMTP id p8mr8736042qag.126.1291264729848; Wed, 01 Dec 2010 20:38:49 -0800 (PST) Received: by 10.220.194.3 with HTTP; Wed, 1 Dec 2010 20:38:49 -0800 (PST) In-Reply-To: <20101202041312.GX16922@dastard> References: <4CF661C7.2020103@sandeen.net> <20101202041312.GX16922@dastard> Date: Thu, 2 Dec 2010 10:08:49 +0530 Message-ID: X-ASG-Orig-Subj: Re: XFS file system corruption(Return Bad Transaction) kernel - 2.6.34 Subject: Re: XFS file system corruption(Return Bad Transaction) kernel - 2.6.34 From: Amit Sahrawat To: Dave Chinner Cc: Eric Sandeen , xfs@oss.sgi.com, sandeen-xfs@sandeen.net Content-Type: multipart/alternative; boundary=0015175caa80889cee049665ffdf X-Barracuda-Connect: mail-qy0-f181.google.com[209.85.216.181] X-Barracuda-Start-Time: 1291264730 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=DKIM_SIGNED, DKIM_VERIFIED, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48228 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --0015175caa80889cee049665ffdf Content-Type: text/plain; charset=ISO-8859-1 I am not able to reproduce the same behaviour on 2.6.30.9, had it been on all versions - this can safely be termed as behaviour. But from 2.6.31 onwards this is very much reproducable, especially the change in behaviour of writing to disk. I will try more things and update if I can find anything new in this. Thanks, Amit Sahrawat On Thu, Dec 2, 2010 at 9:43 AM, Dave Chinner wrote: > On Thu, Dec 02, 2010 at 09:10:08AM +0530, Amit Sahrawat wrote: > > While the copy operation is in progress, simply unplug the usb device and > > then replug. > > That's pretty much a guaranteed recipe for data and filesystem > corruption regardless of the filesystem you are using. Even if you > are lucky enough that there was is no IO being issued while the > device is unplugged, what guarantee is there that the device even > comes back with the same device name? Further, if the device is usb > powered, there is no guarantee that the drive caches were > flushed correctly before the unplug so random log and metadata > corruptions are definitely possible. > > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com > --0015175caa80889cee049665ffdf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I am not able to reproduce the same behaviour on 2.6.30.9, had it been= on all versions - this can safely be termed as behaviour. But from 2.6.31 = onwards this is very much reproducable, especially the change in behaviour = of writing to disk.
I will try more things and update if I can find anything new in this.<= /div>
=A0
Thanks,
Amit Sahrawat

On Thu, Dec 2, 2010 at 9:43 AM, Dave Chinner <david@fromorbit.c= om> wrote:
On Thu, Dec 02, 2010 at 09:10:08AM +0530, Amit Sahrawat w= rote:
> While the copy operation is in progress, simply unplug the us= b device and
> then replug.

That's pretty much a gua= ranteed recipe for data and filesystem
corruption regardless of the filesystem you are using. Even if you
are l= ucky enough that there was is no IO being issued while the
device is unp= lugged, what guarantee is there that the device even
comes back with the= same device name? Further, if the device is usb
powered, there is no guarantee that the drive caches were
flushed correc= tly before the unplug so random log and metadata
corruptions are definit= ely possible.

Cheers,

Dave.
--
Dave Chinner
david@fromorbit.com

--0015175caa80889cee049665ffdf-- From ajeet.yadav.77@gmail.com Thu Dec 2 00:59:48 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.0 required=5.0 tests=BAYES_40,FREEMAIL_FROM, HTML_MESSAGE,T_DKIM_INVALID,T_TO_NO_BRKTS_FREEMAIL autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB26xlgh000783 for ; Thu, 2 Dec 2010 00:59:48 -0600 X-ASG-Debug-ID: 1291273290-156901a20000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-qw0-f53.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 832D2160B6BB for ; Wed, 1 Dec 2010 23:01:31 -0800 (PST) Received: from mail-qw0-f53.google.com (mail-qw0-f53.google.com [209.85.216.53]) by cuda.sgi.com with ESMTP id SygcYnwMAJup1BaK for ; Wed, 01 Dec 2010 23:01:31 -0800 (PST) Received: by qwe5 with SMTP id 5so7837165qwe.26 for ; Wed, 01 Dec 2010 23:01:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=xwQuflRrJ83yrtvkZMQVVGu7y3vSBgnWUA9//kXxhBY=; b=DZttjlz/0iZdBUa95YbKPEHNzNcIwOSVFZn8ddaj76m8q+kWhAtF/Ja66YncQ+n0gD qVhwS8WAljpaW3F9v2wZiNmyMCGFpqNgO79vWJQnNPfyCea6sR4y7xewm8bdrkCCle6O qucAXynWeB+b1hIYOqFptM5yomr6c1E8AYwjc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=MiOH9Y6OjeilQuI0pLocQ/6T8TJUYElN2bWwlyw7CW7FyPpcKZ2pXIlTTqts1d2ul3 NbRfjHmhttqdQGJG8/aifO7rsBDPSVb9F094arI8Ugvmk7cVD9KFEUPTa+YhjwvguqR1 jo8IGhuw23jPHMg2W4w0FGX1timQozib0y1Bg= MIME-Version: 1.0 Received: by 10.224.61.6 with SMTP id r6mr8921746qah.104.1291273290692; Wed, 01 Dec 2010 23:01:30 -0800 (PST) Received: by 10.220.162.69 with HTTP; Wed, 1 Dec 2010 23:01:30 -0800 (PST) Date: Thu, 2 Dec 2010 12:31:30 +0530 Message-ID: X-ASG-Orig-Subj: XFS mount fail: XFS_WANT_CORRUPTED_GOTO fs/xfs/xfs_alloc.c Subject: XFS mount fail: XFS_WANT_CORRUPTED_GOTO fs/xfs/xfs_alloc.c From: Ajeet Yadav To: xfs@oss.sgi.com Content-Type: multipart/alternative; boundary=0015175cded4ccbab7049667fd60 X-Barracuda-Connect: mail-qw0-f53.google.com[209.85.216.53] X-Barracuda-Start-Time: 1291273291 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=DKIM_SIGNED, DKIM_VERIFIED, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48238 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --0015175cded4ccbab7049667fd60 Content-Type: text/plain; charset=ISO-8859-1 Dear all, This is XFS fail mount log on linux 2.6.30.9 XFS mounting filesystem sda2 Starting XFS recovery on filesystem: sda2 (logdev: internal) XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1629 of file fs/xfs/xfs_alloc.c. Caller 0x80129658 Call Trace: [<802dedc8>] dump_stack+0x8/0x34 from[<80127400>] xfs_free_ag_extent+0x128/0x7ac [<80127400>] xfs_free_ag_extent+0x128/0x7ac from[<80129658>] xfs_free_extent+0xb8/0xe8 [<80129658>] xfs_free_extent+0xb8/0xe8 from[<80163978>] xlog_recover_process_efi+0x160/0x214 [<80163978>] xlog_recover_process_efi+0x160/0x214 from[<80163ac4>] xlog_recover_process_efis+0x98/0x11c [<80163ac4>] xlog_recover_process_efis+0x98/0x11c from[<8016663c>] xlog_recover_finish+0x28/0xdc [<8016663c>] xlog_recover_finish+0x28/0xdc from[<8016aec0>] xfs_mountfs+0x4d0/0x610 [<8016aec0>] xfs_mountfs+0x4d0/0x610 from[<80184434>] xfs_fs_fill_super+0x1fc/0x418 [<80184434>] xfs_fs_fill_super+0x1fc/0x418 from[<800bae48>] get_sb_bdev+0x11c/0x1c0 [<800bae48>] get_sb_bdev+0x11c/0x1c0 from[<80181f20>] xfs_fs_get_sb+0x20/0x2c [<80181f20>] xfs_fs_get_sb+0x20/0x2c from[<800b9424>] vfs_kern_mount+0x68/0xd0 [<800b9424>] vfs_kern_mount+0x68/0xd0 from[<800b94f0>] do_kern_mount+0x54/0x118 [<800b94f0>] do_kern_mount+0x54/0x118 from[<800d44e8>] do_mount+0x7b4/0x828 [<800d44e8>] do_mount+0x7b4/0x828 from[<800d45f8>] sys_mount+0x9c/0x194 [<800d45f8>] sys_mount+0x9c/0x194 from[<800102c4>] stack_done+0x20/0x3c Failed to recover EFIs on filesystem: sda2 XFS: log mount finish failed --0015175cded4ccbab7049667fd60 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear all,
This is XFS fail mount log on linux 2.6.30.9
=A0
XFS mounting filesystem sda2
Starting XFS recovery on filesystem: s= da2 (logdev: internal)
XFS internal error XFS_WANT_CORRUPTED_GOTO at lin= e 1629 of file fs/xfs/xfs_alloc.c.=A0 Caller 0x80129658
Call Trace:
[<802dedc8>] dump_stack+0x8/0x34 from[<80127400>] xfs_free_ag_e= xtent+0x128/0x7ac
[<80127400>] xfs_free_ag_extent+0x128/0x7ac from= [<80129658>] xfs_free_extent+0xb8/0xe8
[<80129658>] xfs_free= _extent+0xb8/0xe8 from[<80163978>] xlog_recover_process_efi+0x160/0x2= 14
[<80163978>] xlog_recover_process_efi+0x160/0x214 from[<80163ac4&g= t;] xlog_recover_process_efis+0x98/0x11c
[<80163ac4>] xlog_recover= _process_efis+0x98/0x11c from[<8016663c>] xlog_recover_finish+0x28/0x= dc
[<8016663c>] xlog_recover_finish+0x28/0xdc from[<8016aec0>] xfs= _mountfs+0x4d0/0x610
[<8016aec0>] xfs_mountfs+0x4d0/0x610 from[<= ;80184434>] xfs_fs_fill_super+0x1fc/0x418
[<80184434>] xfs_fs_f= ill_super+0x1fc/0x418 from[<800bae48>] get_sb_bdev+0x11c/0x1c0
[<800bae48>] get_sb_bdev+0x11c/0x1c0 from[<80181f20>] xfs_fs_ge= t_sb+0x20/0x2c
[<80181f20>] xfs_fs_get_sb+0x20/0x2c from[<800b9= 424>] vfs_kern_mount+0x68/0xd0
[<800b9424>] vfs_kern_mount+0x68= /0xd0 from[<800b94f0>] do_kern_mount+0x54/0x118
[<800b94f0>] do_kern_mount+0x54/0x118 from[<800d44e8>] do_mount= +0x7b4/0x828
[<800d44e8>] do_mount+0x7b4/0x828 from[<800d45f8&g= t;] sys_mount+0x9c/0x194
[<800d45f8>] sys_mount+0x9c/0x194 from[&l= t;800102c4>] stack_done+0x20/0x3c
=A0
Failed to recover EFIs on filesystem: sda2
XFS: log mount finish = failed
--0015175cded4ccbab7049667fd60-- From michael.monnerie@is.it-management.at Thu Dec 2 05:31:30 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB2BVTh4014138 for ; Thu, 2 Dec 2010 05:31:30 -0600 X-ASG-Debug-ID: 1291289590-73b3018f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mailsrv14.zmi.at (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CA99E1C883BB for ; Thu, 2 Dec 2010 03:33:11 -0800 (PST) Received: from mailsrv14.zmi.at (mailsrv1.zmi.at [212.69.164.54]) by cuda.sgi.com with ESMTP id eHYkEGr4gWzzTT4h for ; Thu, 02 Dec 2010 03:33:11 -0800 (PST) Received: from mailsrv.i.zmi.at (h081217106033.dyn.cm.kabsi.at [81.217.106.33]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified)) by mailsrv14.zmi.at (Postfix) with ESMTPSA id 2609F609; Thu, 2 Dec 2010 12:33:09 +0100 (CET) Received: from saturn.localnet (saturn.i.zmi.at [10.72.27.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailsrv.i.zmi.at (Postfix) with ESMTPSA id 86303401C3D; Thu, 2 Dec 2010 12:33:07 +0100 (CET) From: Michael Monnerie Organization: it-management http://it-management.at To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs_repair of critical volume Subject: Re: xfs_repair of critical volume Date: Thu, 2 Dec 2010 12:33:02 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.34.7-0.5-desktop; KDE/4.4.4; x86_64; ; ) Cc: Eli Morris , Dave Chinner References: <75C248E3-2C99-426E-AE7D-9EC543726796@ucsc.edu> <20101117074708.GP22876@dastard> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2592691.X4ZIO1cIyr"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201012021233.07213@zmi.at> X-Barracuda-Connect: mailsrv1.zmi.at[212.69.164.54] X-Barracuda-Start-Time: 1291289591 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48257 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --nextPart2592691.X4ZIO1cIyr Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Dienstag, 30. November 2010 Eli Morris wrote: > Thanks for your help with this. I wrote the program and ran it > through and it looks like we have we able to preserve 44 TB of valid > data, while removing the corrupted files, which is a great result, > considering the circumstances.=20 Eli, could you post the relevant program here so others can use it if=20 needed? There are requests from time to time, and it would be good if=20 such a program were available (like I'm sure you'd been happy if it=20 already existed the time you needed it). Thanks, and wow: what an amazing filesystem can recover such an event! =2D-=20 mit freundlichen Gr=FCssen, Michael Monnerie, Ing. BSc it-management Internet Services: Prot=E9ger http://proteger.at [gesprochen: Prot-e-schee] Tel: +43 660 / 415 6531 // ****** Radiointerview zum Thema Spam ****** // http://www.it-podcast.at/archiv.html#podcast-100716 //=20 // Haus zu verkaufen: http://zmi.at/langegg/ --nextPart2592691.X4ZIO1cIyr Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iEYEABECAAYFAkz3g/MACgkQzhSR9xwSCbSqfACg3RkCYB+j5dLKRL3PTvGvmA7H Rw8An24uOFEeD0Kgzxb6Wug0hvbNuJXi =wvwl -----END PGP SIGNATURE----- --nextPart2592691.X4ZIO1cIyr-- From BATV+5c8b8fc841e426a1fab9+2657+infradead.org+hch@bombadil.srs.infradead.org Thu Dec 2 05:37:11 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB2Bb8WJ014392 for ; Thu, 2 Dec 2010 05:37:10 -0600 X-ASG-Debug-ID: 1291289931-0a0400850000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A0FBE1404F6A for ; Thu, 2 Dec 2010 03:38:52 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id qm1feOlqniwCKSQC for ; Thu, 02 Dec 2010 03:38:52 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PO7Uv-0005ai-Bx; Thu, 02 Dec 2010 11:38:49 +0000 Date: Thu, 2 Dec 2010 06:38:49 -0500 From: Christoph Hellwig To: Dave Chinner Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/8] xfs: Pull EFI/EFD handling out from under the AIL lock Subject: Re: [PATCH 1/8] xfs: Pull EFI/EFD handling out from under the AIL lock Message-ID: <20101202113849.GA21365@infradead.org> References: <1290993152-20999-1-git-send-email-david@fromorbit.com> <1290993152-20999-2-git-send-email-david@fromorbit.com> <20101130201734.GA16079@infradead.org> <20101202012841.GL16922@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101202012841.GL16922@dastard> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291289932 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Dec 02, 2010 at 12:28:41PM +1100, Dave Chinner wrote: > > - there is a behaviour change about the xfs_trans_del_item call > > in xfs_efi_item_unpin - before it was protected by the > > XFS_EFI_CANCELED which was never set, and now it's not. > > XFS_EFI_CANCELED has not been set in the code base since > xfs_efi_cancel() was removed back in 2006 by commit > 065d312e15902976d256ddaf396a7950ec0350a8 ("[XFS] Remove unused > iop_abort log item operation), and even then xfs_efi_cancel() was > never called. I haven't tracked it back further than that (beyond > git history), but handling of efis in cancelled transactions has > been broken for a long time. > > Basically, when we get an IOP_UNPIN(lip, 1); call from > xfs_trans_uncommit() (i.e. remove == 1), if we don't free the log > item descriptor we leak it. IOWs, the new behaviour introduced in > this patch is actually the correct behaviour. Maybe fix this issue first in a separate patch, instead of hiding it in a bigger one. From BATV+5c8b8fc841e426a1fab9+2657+infradead.org+hch@bombadil.srs.infradead.org Thu Dec 2 05:39:06 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB2Bd6Hq014506 for ; Thu, 2 Dec 2010 05:39:06 -0600 X-ASG-Debug-ID: 1291290050-739201ed0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9C5581C888FB for ; Thu, 2 Dec 2010 03:40:50 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 5sagJsvC2a0Yp2Lj for ; Thu, 02 Dec 2010 03:40:50 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PO7Ws-0006Gn-19; Thu, 02 Dec 2010 11:40:50 +0000 Date: Thu, 2 Dec 2010 06:40:50 -0500 From: Christoph Hellwig To: Dave Chinner Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 02/14] xfs: clean up log space grant functions Subject: Re: [PATCH 02/14] xfs: clean up log space grant functions Message-ID: <20101202114049.GB21365@infradead.org> References: <1290994712-21376-1-git-send-email-david@fromorbit.com> <1290994712-21376-3-git-send-email-david@fromorbit.com> <20101201123032.GA20378@infradead.org> <20101202014833.GN16922@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101202014833.GN16922@dastard> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291290050 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Dec 02, 2010 at 12:48:33PM +1100, Dave Chinner wrote: > Ok, so your main objection is the needless addition to the queue? > That can be avoided easily enough via a local variable. Would that > be sufficient to alleviate your concerns? The main objection is that the new code might be a bit shorted, but is a lot less readable. If you really want it go with it and an updated changelog mentioning the behaviour change, but I don't really feel too good about it. From BATV+5c8b8fc841e426a1fab9+2657+infradead.org+hch@bombadil.srs.infradead.org Thu Dec 2 05:45:43 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB2BjhAX014925 for ; Thu, 2 Dec 2010 05:45:43 -0600 X-ASG-Debug-ID: 1291290447-1619001a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 67668140521E for ; Thu, 2 Dec 2010 03:47:27 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id N3Shda6FvUSZqRSW for ; Thu, 02 Dec 2010 03:47:27 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PO7dG-00079U-Iu; Thu, 02 Dec 2010 11:47:26 +0000 Date: Thu, 2 Dec 2010 06:47:26 -0500 From: Christoph Hellwig To: Dave Chinner Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 03/14] xfs: convert log grant heads to LSN notation Subject: Re: [PATCH 03/14] xfs: convert log grant heads to LSN notation Message-ID: <20101202114726.GC21365@infradead.org> References: <1290994712-21376-1-git-send-email-david@fromorbit.com> <1290994712-21376-4-git-send-email-david@fromorbit.com> <20101201130504.GA18379@infradead.org> <20101202020132.GP16922@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101202020132.GP16922@dastard> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291290447 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Dec 02, 2010 at 01:01:32PM +1100, Dave Chinner wrote: > On Wed, Dec 01, 2010 at 08:05:04AM -0500, Christoph Hellwig wrote: > > > -STATIC int xlog_space_left(xlog_t *log, int cycle, int bytes); > > > +STATIC int xlog_space_left(int logsize, xfs_lsn_t tail_lsn, > > > + xfs_lsn_t head); > > > > Looking further through the series I have to say I really hate > > passing in the logsize instead of the log structure. Passing the > > log pointer from higher level functions just makes a lot more sense. > > > > Also in this case passing the tail_lsn explicitly doesn't make any sense > > - it becomes atomic later and thus there is no locking requirement for > > it. > > What I wanted to make clear is that the calculation works on fixed > values and doesn't sample values internally itself. I guess that's > not important for the log size, but for stuff like the tail lsn > it avoids needing to sample inside xlog_space_left() before we > crack it. i.e. something like this is wrong: > > cycle = CYCLE_LSN(atomic64_read(&log->l_tail_lsn)); > block = BLOCK_LSN(atomic64_read(&log->l_tail_lsn)); > > and this is correct: > > tail_lsn = atomic64_read(&log->l_tail_lsn); > cycle = CYCLE_LSN(tail_lsn); > block = BLOCK_LSN(tail_lsn); > > So it makes sense to me to have the value of of the tail lsn and > other variables that should only be sampled once passed into the > function. That avoids misunderstandings further down the track > because it is obvious that the calculation works on constant values. > Perhaps I should add "const" to the parameter declarations to help > make my intentions clear... I don't think obsfucating the code is a good idea to reach this goal. What might be better is a helper like: static inline void xlog_crack_lsn(atomic64_t *lsn, int *cycle, int *block) { xfs_lsn_t = atomic64_read(lsn); *cycle = CYCLE_LSN(tail_lsn); *block = BLOCK_LSN(tail_lsn); } and a long comment explaining how it needs to be used. > I thought about that - my first version even did this. I thought it > was easier to understand the changes if I didn't change the calling > conventions for modifying the grant heads. As such, I'd prefer to > make this change to the wrappers in a separate patch. Heh, when looking at the patch I actually found this part pretty hard to read already. So moving the factoring of the helpers out into a separate patch might indeed be a good idea, and that patch can also remove the wrappers. From BATV+5c8b8fc841e426a1fab9+2657+infradead.org+hch@bombadil.srs.infradead.org Thu Dec 2 05:46:23 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_00,SUBJ_TICKET autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB2BkNHF014979 for ; Thu, 2 Dec 2010 05:46:23 -0600 X-ASG-Debug-ID: 1291290487-166f00210000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8B5981405227 for ; Thu, 2 Dec 2010 03:48:07 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id H6v1SpJnSIoNaLOG for ; Thu, 02 Dec 2010 03:48:07 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PO7du-0007Bg-QT; Thu, 02 Dec 2010 11:48:06 +0000 Date: Thu, 2 Dec 2010 06:48:06 -0500 From: Christoph Hellwig To: Dave Chinner Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 09/14] xfs: introduce new locks for the log grant ticket wait queues Subject: Re: [PATCH 09/14] xfs: introduce new locks for the log grant ticket wait queues Message-ID: <20101202114806.GD21365@infradead.org> References: <1290994712-21376-1-git-send-email-david@fromorbit.com> <1290994712-21376-10-git-send-email-david@fromorbit.com> <20101201131208.GA22455@infradead.org> <20101202021031.GT16922@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101202021031.GT16922@dastard> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291290487 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Dec 02, 2010 at 01:10:31PM +1100, Dave Chinner wrote: > On Wed, Dec 01, 2010 at 08:12:08AM -0500, Christoph Hellwig wrote: > > > + /* co-ordinate with xfs_log_force_shutdown */ > > > + if (XLOG_FORCED_SHUTDOWN(log)) { > > > + spin_unlock(&log->l_grant_reserve_lock); > > > + goto error_return; > > > + } > > > > Where is this coming from? Otherwise the patch looks good to me. > > To handles the race condition between xfs_log_force_shutdown() clearing > all the tickets off the queue and a racing log reserve that had > already checked the shutdown flag and was spinning waiting for the > reserve lock to add the ticket to the queue. The race condition is > documented in xfs_log_force_shutdown()... Ok. Please add something like that to the patch description. From denny.priebe@googlemail.com Thu Dec 2 06:18:59 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, T_DKIM_INVALID autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB2CIwqS016629 for ; Thu, 2 Dec 2010 06:18:59 -0600 X-ASG-Debug-ID: 1291292440-06c5029a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-wy0-f181.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8F117160B89E for ; Thu, 2 Dec 2010 04:20:40 -0800 (PST) Received: from mail-wy0-f181.google.com (mail-wy0-f181.google.com [74.125.82.181]) by cuda.sgi.com with ESMTP id gYCpgYZwl0MZ8qKW for ; Thu, 02 Dec 2010 04:20:40 -0800 (PST) Received: by wyf22 with SMTP id 22so8783778wyf.26 for ; Thu, 02 Dec 2010 04:20:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Pgb3z0h1KXD7mIDBiGuSEQfxpAJQMRLgy/Ask3kLJHA=; b=gtv/RmcLEw0aUmHOj6EQ+/1yoM9LwcNUkUaNyFnsfHIiD6+BStiot7EXxAmzL+LEnx +gPtRKspLR+5Tkmkb3/YBCwIKcDz5Y1aoWku5+bSsk9tgkAxhIX0SZd3O9f88wvUsZKK BeRW9cOt4aumpG5Xj7dOB2kLeHrsIBZg4KE/E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dLRkvnVyZVkxCaTuPwdibbMza68X2RWRS9sxEGZ0lgEPfY/nFJfTk+4FwQu9359L3m wFPjKVK9EkROpCCjlErwHzCdY29eyhve7Q0GM3Gkb9pbMchMC8QYx57U/ZG3663QM7eI xxSJup9IZNnsagDRk5IAjL9EiE0Tcg4FIW6Ys= MIME-Version: 1.0 Received: by 10.216.48.138 with SMTP id v10mr31687web.66.1291292439423; Thu, 02 Dec 2010 04:20:39 -0800 (PST) Received: by 10.216.18.137 with HTTP; Thu, 2 Dec 2010 04:20:39 -0800 (PST) In-Reply-To: <20101026225839.GZ32255@dastard> References: <20101026225839.GZ32255@dastard> Date: Thu, 2 Dec 2010 12:20:39 +0000 Message-ID: X-ASG-Orig-Subj: Re: Possible deadlock when deleting from realtime section Subject: Re: Possible deadlock when deleting from realtime section From: Denny Priebe To: Dave Chinner Cc: xfs@oss.sgi.com Content-Type: text/plain; charset=ISO-8859-1 X-Barracuda-Connect: mail-wy0-f181.google.com[74.125.82.181] X-Barracuda-Start-Time: 1291292442 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3748 1.0000 -0.0706 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.43 X-Barracuda-Spam-Status: No, SCORE=0.43 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M, DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48260 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.50 BSF_RULE7568M Custom Rule 7568M X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Tue, Oct 26, 2010 at 10:58 PM, Dave Chinner wrote: > Hmmm. Looks like we broke recursive inode locking in > xfs_trans_iget() in commit aa72a5cf00001d0b952c7c755be404b9118ceb2e > ("xfs: simplify xfs_trans_iget"). > What we didn't take into account is multiple RT allocator calls in > the same transaction context. Let me think about the best way to fix > this. Is there any news on this? Maybe some patch I could try out? Regards, Denny From amit.sahrawat83@gmail.com Thu Dec 2 06:21:53 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.2 required=5.0 tests=BAYES_00,FREEMAIL_FROM, HTML_MESSAGE,J_CHICKENPOX_83,T_DKIM_INVALID autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB2CLrrG016765 for ; Thu, 2 Dec 2010 06:21:53 -0600 X-ASG-Debug-ID: 1291292615-67f2011c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-qw0-f53.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C8D811BC14D for ; Thu, 2 Dec 2010 04:23:35 -0800 (PST) Received: from mail-qw0-f53.google.com (mail-qw0-f53.google.com [209.85.216.53]) by cuda.sgi.com with ESMTP id h3IOyiltgDKwAChJ for ; Thu, 02 Dec 2010 04:23:35 -0800 (PST) Received: by qwe5 with SMTP id 5so8157860qwe.26 for ; Thu, 02 Dec 2010 04:23:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=KtjGyAF3BXwyLH8vhsDPunhw5Fs3LPRDTPxIIQTQK9E=; b=PvdVRoz0C6xPQXDZYvkTyYW5/8tjqN4G6+89FW3C1zGL4p1Ntj2oLDnFYxutb61U1/ qwU0OLBmE7OP2stMvDgQbUKDTAc3YGSiIePpbdGcq7da1qLgDHFQ2ItApFr9gGqEU8Ej EsrRnmIqeGXEiOoKeBP5lhpwogVusuo33Tu2Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=c+E28sYntqcphII+xzBTu3uRgrfLuO/pQawK4N1STyu6eRC8XqhO2QSQmQrvJE/cVg CA4IE2UU6X9nAl5HyC0o6xlFXXPgFhoUgX2Fe0wOGTwC54aaxbqp1cb7JaWwJP07idTX E/pD3psGCkeQ3aG0JZHxUW9J2fVFQtBpbgLSw= MIME-Version: 1.0 Received: by 10.224.37.141 with SMTP id x13mr1954749qad.76.1291292614166; Thu, 02 Dec 2010 04:23:34 -0800 (PST) Received: by 10.220.194.3 with HTTP; Thu, 2 Dec 2010 04:23:34 -0800 (PST) In-Reply-To: References: <4CF661C7.2020103@sandeen.net> <20101202041312.GX16922@dastard> Date: Thu, 2 Dec 2010 17:53:34 +0530 Message-ID: X-ASG-Orig-Subj: Re: XFS file system corruption(Return Bad Transaction) kernel - 2.6.34 Subject: Re: XFS file system corruption(Return Bad Transaction) kernel - 2.6.34 From: Amit Sahrawat To: Dave Chinner Cc: Eric Sandeen , xfs@oss.sgi.com, sandeen-xfs@sandeen.net Content-Type: multipart/alternative; boundary=0015175cddbe918a5304966c7de2 X-Barracuda-Connect: mail-qw0-f53.google.com[209.85.216.53] X-Barracuda-Start-Time: 1291292615 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=DKIM_SIGNED, DKIM_VERIFIED, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48260 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --0015175cddbe918a5304966c7de2 Content-Type: text/plain; charset=ISO-8859-1 By tracing back to find the cause of the issue: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.31.y.git;a=commitdiff;h=f95022161d23ee661a48af8f280472209f513a67 This patch results in generating different behaviour for write. - it makes dependency on xfssyncd(for which default time out value is 3000centisecs - cat /proc/sys/fs/xfs/xfssyncd_centisecs) - 30secs is too large for committing to disc. So, either this value can be lowered or this patch can be reverted so that pdflush takes care of all this. Removing the changes from this patch seems viable solution at this moment. What do you suggest? Thanks, Amit Sahrawat On Thu, Dec 2, 2010 at 10:08 AM, Amit Sahrawat wrote: > I am not able to reproduce the same behaviour on 2.6.30.9, had it been on > all versions - this can safely be termed as behaviour. But from 2.6.31 > onwards this is very much reproducable, especially the change in behaviour > of writing to disk. > I will try more things and update if I can find anything new in this. > > Thanks, > Amit Sahrawat > > On Thu, Dec 2, 2010 at 9:43 AM, Dave Chinner wrote: > >> On Thu, Dec 02, 2010 at 09:10:08AM +0530, Amit Sahrawat wrote: >> > While the copy operation is in progress, simply unplug the usb device >> and >> > then replug. >> >> That's pretty much a guaranteed recipe for data and filesystem >> corruption regardless of the filesystem you are using. Even if you >> are lucky enough that there was is no IO being issued while the >> device is unplugged, what guarantee is there that the device even >> comes back with the same device name? Further, if the device is usb >> powered, there is no guarantee that the drive caches were >> flushed correctly before the unplug so random log and metadata >> corruptions are definitely possible. >> >> Cheers, >> >> Dave. >> -- >> Dave Chinner >> david@fromorbit.com >> > > --0015175cddbe918a5304966c7de2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
By tracing back to find the cause of the issue:
This patch results in generating different behaviour for write. - it m= akes dependency on xfssyncd(for which default time out value is 3000centise= cs - cat /proc/sys/fs/xfs/xfssyncd_centisecs) - 30secs is too large for com= mitting to disc.
So, either this value can be lowered or this patch can be reverted so = that pdflush takes care of all this.
Removing the changes from this patch seems viable solution at this mom= ent.
=A0
What do you suggest?
=A0
Thanks,
Amit Sahrawat


=A0
On Thu, Dec 2, 2010 at 10:08 AM, Amit Sahrawat <= span dir=3D"ltr"><amit.sahr= awat83@gmail.com> wrote:
I am not able to reproduce the same behaviour on 2.6.30.9, had it been= on all versions - this can safely be termed as behaviour. But from 2.6.31 = onwards this is very much reproducable, especially the change in behaviour = of writing to disk.
I will try more things and update if I can find anything new in this.<= /div>
=A0
Thanks,
Amit Sahrawat

On Thu, Dec 2, 2010 at 9:43 AM, Dave Chinner <david@fromorbit.com> wrote:
On Thu, Dec 02, 2010 at 09:10:08AM +0530, Amit Sahrawat wrote:
>= While the copy operation is in progress, simply unplug the usb device and<= br>> then replug.

That's pretty much a guaranteed recip= e for data and filesystem
corruption regardless of the filesystem you are using. Even if you
are l= ucky enough that there was is no IO being issued while the
device is unp= lugged, what guarantee is there that the device even
comes back with the= same device name? Further, if the device is usb
powered, there is no guarantee that the drive caches were
flushed correc= tly before the unplug so random log and metadata
corruptions are definit= ely possible.

Cheers,

Dave.
--
Dave Chinner
david@fromorbit.com


--0015175cddbe918a5304966c7de2-- From spelic@shiftmail.org Thu Dec 2 07:54:58 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB2Dsv5p021141 for ; Thu, 2 Dec 2010 07:54:58 -0600 X-ASG-Debug-ID: 1291298200-1a3200810000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from BLADE3.ISTI.CNR.IT (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 18A831C88DF7 for ; Thu, 2 Dec 2010 05:56:40 -0800 (PST) Received: from BLADE3.ISTI.CNR.IT (blade3.isti.cnr.it [194.119.192.19]) by cuda.sgi.com with ESMTP id 68BrRAf1qEQrmksx for ; Thu, 02 Dec 2010 05:56:40 -0800 (PST) Received: from SCRIPT-SPFWL-DAEMON.mx.isti.cnr.it by mx.isti.cnr.it (PMDF V6.5 #31825) id <01NUY6C6IIV4LS7885@mx.isti.cnr.it> for xfs@oss.sgi.com; Thu, 02 Dec 2010 14:55:09 +0100 (MET) Received: from conversionlocal.isti.cnr.it by mx.isti.cnr.it (PMDF V6.5 #31825) id <01NUY6C3HEJKLVVT6P@mx.isti.cnr.it> for xfs@oss.sgi.com; Thu, 02 Dec 2010 14:55:05 +0100 (MET) Received: from [192.168.7.52] (firewall.itb.cnr.it [155.253.6.254]) by mx.isti.cnr.it (PMDF V6.5 #31826) with ESMTPSA id <01NUY6C2UEEWLX52AX@mx.isti.cnr.it>; Thu, 02 Dec 2010 14:55:02 +0100 (MET) Date: Thu, 02 Dec 2010 14:55:05 +0100 From: Spelic X-ASG-Orig-Subj: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram Subject: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram To: "linux-kernel@vger.kernel.org" , xfs@oss.sgi.com, linux-lvm@redhat.com Message-id: <4CF7A539.1050206@shiftmail.org> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 X-INSM-ip-source: 155.253.6.254 Auth Done X-Barracuda-Connect: blade3.isti.cnr.it[194.119.192.19] X-Barracuda-Start-Time: 1291298201 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.12 X-Barracuda-Spam-Status: No, SCORE=-1.12 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M, BSF_SC0_SA085b X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48267 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M 0.40 BSF_SC0_SA085b Custom Rule SA085b X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hello all I noticed what seem to be 4 bugs. (kernel v2.6.37-rc4 but probably also before) First two are one in mkfs.xfs and one in device mapper (lvm mailing list I suppose, otherwise pls forward it): Steps to reproduce: Boot with a large ramdisk, like ramdisk_size=2097152 (actually I had 14GB ramdisk when I tried this but I don't think it will make a difference) Now partition it with a 1GB partition: fdisk /dev/ram0 n p 1 1 +1G w (only one 1GB physical partition) Make a devmapper mapping for the partition kpartx -av /dev/ram0 mkfs.xfs -f /dev/mapper/ram0p1 meta-data=/dev/mapper/ram0p1 isize=256 agcount=4, agsize=66266 blks = sectsz=512 attr=2 data = bsize=4096 blocks=265064, imaxpct=25 = sunit=0 swidth=0 blks naming =version 2 bsize=4096 ascii-ci=0 log =internal log bsize=4096 blocks=2560, version=2 = sectsz=512 sunit=0 blks, lazy-count=1 realtime =none extsz=4096 blocks=0, rtextents=0 Now, lo and behold, partition is gone! fdisk /dev/ram0 p will show no partitions! you can also check with dd if=/dev/ram bs=1M count=1 | hexdump -C All first MB of /dev/ram is zeroed!! also mount /dev/ram0p1 /mnt will fail. Unknown filesystem I think this shows 2 bugs: firstly mkfs.xfs dares to do stuff before the beginning of the device on which it should work. Secondly, device mapper does not constrain access within the boundaries of the device, which I think it should do. Then I have 2 more bugs for you. Please see my thread in linux-rdma called: "NFS-RDMA hangs: connection closed (-103)" in particular this post http://www.mail-archive.com/linux-rdma@vger.kernel.org/msg06632.html with NFS over over Infiniband over XFS over ramdisk it is possible to write a file (2.3GB) which is larger than the size of the device (1.5GB): one bug I think is for XFS people (because I think XFS should check if the space on the filesystem is finished), and another one I think is for /dev/ram people (what mailing list? I am adding lkml), because I think the device should check if someone is writing beyond the end of it. Thank you PS: I am not subscribed to lkml so please do not reply ONLY to lkml. From BATV+5c8b8fc841e426a1fab9+2657+infradead.org+hch@bombadil.srs.infradead.org Thu Dec 2 08:09:54 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB2E9qbN021898 for ; Thu, 2 Dec 2010 08:09:54 -0600 X-ASG-Debug-ID: 1291299096-125b03cd0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5E6231BCA70 for ; Thu, 2 Dec 2010 06:11:36 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id ECjlYSBqnqp1Vghw for ; Thu, 02 Dec 2010 06:11:36 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PO9sk-0006VT-9U; Thu, 02 Dec 2010 14:11:34 +0000 Date: Thu, 2 Dec 2010 09:11:34 -0500 From: Christoph Hellwig To: Spelic Cc: "linux-kernel@vger.kernel.org" , xfs@oss.sgi.com, linux-lvm@redhat.com X-ASG-Orig-Subj: Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram Subject: Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram Message-ID: <20101202141134.GA22012@infradead.org> References: <4CF7A539.1050206@shiftmail.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CF7A539.1050206@shiftmail.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291299096 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean I'm pretty sure you have CONFIG_DEBUG_BLOCK_EXT_DEVT enabled. This option must never be enabled, as it causes block devices to be randomly renumered. Together with the ramdisk driver overloading the BLKFLSBUF ioctl to discard all data it guarantees you to get data loss like yours. From spelic@shiftmail.org Thu Dec 2 08:14:09 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB2EE9TX022176 for ; Thu, 2 Dec 2010 08:14:09 -0600 X-ASG-Debug-ID: 1291299351-12cd01d70000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx2.isti.cnr.it (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 505351E94300 for ; Thu, 2 Dec 2010 06:15:51 -0800 (PST) Received: from mx2.isti.cnr.it (mx2.isti.cnr.it [194.119.192.4]) by cuda.sgi.com with ESMTP id qxG8AlpsczvgWYoB for ; Thu, 02 Dec 2010 06:15:51 -0800 (PST) Received: from SCRIPT-SPFWL-DAEMON.mx.isti.cnr.it by mx.isti.cnr.it (PMDF V6.5 #31825) id <01NUY70BGTDSLVVTNA@mx.isti.cnr.it> for xfs@oss.sgi.com; Thu, 02 Dec 2010 15:14:39 +0100 (MET) Received: from conversionlocal.isti.cnr.it by mx.isti.cnr.it (PMDF V6.5 #31825) id <01NUY706M72OLS71Q6@mx.isti.cnr.it> for xfs@oss.sgi.com; Thu, 02 Dec 2010 15:14:32 +0100 (MET) Received: from [192.168.7.52] (firewall.itb.cnr.it [155.253.6.254]) by mx.isti.cnr.it (PMDF V6.5 #31826) with ESMTPSA id <01NUY704GITULX4XXJ@mx.isti.cnr.it>; Thu, 02 Dec 2010 15:14:26 +0100 (MET) Date: Thu, 02 Dec 2010 15:14:28 +0100 From: Spelic X-ASG-Orig-Subj: Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram Subject: Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram In-reply-to: <20101202141134.GA22012@infradead.org> To: Christoph Hellwig Cc: "linux-kernel@vger.kernel.org" , xfs@oss.sgi.com, linux-lvm@redhat.com Message-id: <4CF7A9C4.2040607@shiftmail.org> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 X-INSM-ip-source: 155.253.6.254 Auth Done References: <4CF7A539.1050206@shiftmail.org> <20101202141134.GA22012@infradead.org> X-Barracuda-Connect: mx2.isti.cnr.it[194.119.192.4] X-Barracuda-Start-Time: 1291299353 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48267 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 12/02/2010 03:11 PM, Christoph Hellwig wrote: > I'm pretty sure you have CONFIG_DEBUG_BLOCK_EXT_DEVT enabled. This > option must never be enabled, as it causes block devices to be > randomly renumered. Together with the ramdisk driver overloading > the BLKFLSBUF ioctl to discard all data it guarantees you to get > data loss like yours. > Nope... # CONFIG_DEBUG_BLOCK_EXT_DEVT is not set From spelic@shiftmail.org Thu Dec 2 08:14:10 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB2EE9hc022179 for ; Thu, 2 Dec 2010 08:14:09 -0600 X-ASG-Debug-ID: 1291299351-681602a70000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx2.isti.cnr.it (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8F1211405B41 for ; Thu, 2 Dec 2010 06:15:52 -0800 (PST) Received: from mx2.isti.cnr.it (mx2.isti.cnr.it [194.119.192.4]) by cuda.sgi.com with ESMTP id VPu7M0CINZM8zeM8 for ; Thu, 02 Dec 2010 06:15:52 -0800 (PST) Received: from SCRIPT-SPFWL-DAEMON.mx.isti.cnr.it by mx.isti.cnr.it (PMDF V6.5 #31825) id <01NUY70IQ3Q8LS7BA9@mx.isti.cnr.it> for xfs@oss.sgi.com; Thu, 02 Dec 2010 15:15:00 +0100 (MET) Received: from conversionlocal.isti.cnr.it by mx.isti.cnr.it (PMDF V6.5 #31825) id <01NUY70FXFGGLS76YD@mx.isti.cnr.it> for xfs@oss.sgi.com; Thu, 02 Dec 2010 15:14:41 +0100 (MET) Received: from [192.168.7.52] (firewall.itb.cnr.it [155.253.6.254]) by mx.isti.cnr.it (PMDF V6.5 #31826) with ESMTPSA id <01NUY70CQOTKLX4XXJ@mx.isti.cnr.it>; Thu, 02 Dec 2010 15:14:36 +0100 (MET) Date: Thu, 02 Dec 2010 15:14:39 +0100 From: Spelic X-ASG-Orig-Subj: Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram Subject: Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram In-reply-to: <4CF7A539.1050206@shiftmail.org> To: Spelic Cc: "linux-kernel@vger.kernel.org" , xfs@oss.sgi.com, linux-lvm@redhat.com Message-id: <4CF7A9CF.2020904@shiftmail.org> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 X-INSM-ip-source: 155.253.6.254 Auth Done References: <4CF7A539.1050206@shiftmail.org> X-Barracuda-Connect: mx2.isti.cnr.it[194.119.192.4] X-Barracuda-Start-Time: 1291299353 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA_TO_FROM_ADDR_MATCH X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48268 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_SC0_SA_TO_FROM_ADDR_MATCH Sender Address Matches Recipient Address X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Sorry for replying to my own email already one more thing on the 3rd bug: On 12/02/2010 02:55 PM, Spelic wrote: > Hello all > [CUT] > ....... > with NFS over over Infiniband over XFS over ramdisk it > is possible to write a file (2.3GB) which is larger than This is also reproducible with: NFS over TCP over Ethernet over XFS over ramdisk. You don't need infiniband for this. With ethernet it doesn't hang (that's another bug, for RDMA people, in the othter thread) but the file is still 1.9GB, i.e. larger than the device. Look, after running the test over ethernet, at server side: # ll -h /mnt/ram total 1.5G drwxr-xr-x 2 root root 21 2010-12-02 12:54 ./ drwxr-xr-x 3 root root 4.0K 2010-11-29 23:51 ../ -rw-r--r-- 1 root root 1.9G 2010-12-02 15:04 zerofile # mount rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw) /dev/sda1 on / type ext4 (rw,errors=remount-ro) proc on /proc type proc (rw,noexec,nosuid,nodev) none on /sys type sysfs (rw,noexec,nosuid,nodev) none on /sys/fs/fuse/connections type fusectl (rw) none on /sys/kernel/debug type debugfs (rw) none on /sys/kernel/security type securityfs (rw) devtmpfs on /dev type devtmpfs (rw,mode=0755) none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620) none on /dev/shm type tmpfs (rw,nosuid,nodev) none on /var/run type tmpfs (rw,nosuid,mode=0755) none on /var/lock type tmpfs (rw,noexec,nosuid,nodev) none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) nfsd on /proc/fs/nfsd type nfsd (rw) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev) /dev/ram0 on /mnt/ram type xfs (rw) # blockdev --getsize64 /dev/ram0 1610612736 # dd if=/mnt/ram/zerofile | wc -c 1985937408 3878784+0 records in 3878784+0 records out 1985937408 bytes (2.0 GB) copied, 6.57081 s, 302 MB/s Feel free to forward to NFS mailing list also if you think it's appropriate. Thank you From BATV+5c8b8fc841e426a1fab9+2657+infradead.org+hch@bombadil.srs.infradead.org Thu Dec 2 08:15:55 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB2EFsZ9022289 for ; Thu, 2 Dec 2010 08:15:55 -0600 X-ASG-Debug-ID: 1291299458-206601370000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DA7AD1E94327 for ; Thu, 2 Dec 2010 06:17:38 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id OjZJoT8GMQJtNhkQ for ; Thu, 02 Dec 2010 06:17:38 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PO9yb-0007om-6Q; Thu, 02 Dec 2010 14:17:37 +0000 Date: Thu, 2 Dec 2010 09:17:37 -0500 From: Christoph Hellwig To: Spelic Cc: Christoph Hellwig , "linux-kernel@vger.kernel.org" , xfs@oss.sgi.com, linux-lvm@redhat.com X-ASG-Orig-Subj: Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram Subject: Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram Message-ID: <20101202141737.GA29799@infradead.org> References: <4CF7A539.1050206@shiftmail.org> <20101202141134.GA22012@infradead.org> <4CF7A9C4.2040607@shiftmail.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CF7A9C4.2040607@shiftmail.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291299458 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Dec 02, 2010 at 03:14:28PM +0100, Spelic wrote: > On 12/02/2010 03:11 PM, Christoph Hellwig wrote: > >I'm pretty sure you have CONFIG_DEBUG_BLOCK_EXT_DEVT enabled. This > >option must never be enabled, as it causes block devices to be > >randomly renumered. Together with the ramdisk driver overloading > >the BLKFLSBUF ioctl to discard all data it guarantees you to get > >data loss like yours. > > Nope... > > # CONFIG_DEBUG_BLOCK_EXT_DEVT is not set Hmm, I suspect dm-linear's dumb forwarding of ioctls has the same effect. From aelder@sgi.com Thu Dec 2 10:41:23 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from relay.sgi.com (relay3.corp.sgi.com [198.149.34.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB2GfNXO029777 for ; Thu, 2 Dec 2010 10:41:23 -0600 Received: from stout.americas.sgi.com (stout.americas.sgi.com [128.162.232.50]) by relay3.corp.sgi.com (Postfix) with ESMTP id 5F451AC006; Thu, 2 Dec 2010 08:43:04 -0800 (PST) Received: from stout.americas.sgi.com (localhost6.localdomain6 [127.0.0.1]) by stout.americas.sgi.com (8.14.4/8.14.2) with ESMTP id oB2Gh3r9006179; Thu, 2 Dec 2010 10:43:03 -0600 Received: (from aelder@localhost) by stout.americas.sgi.com (8.14.4/8.14.4/Submit) id oB2Gh3JL006178; Thu, 2 Dec 2010 10:43:03 -0600 From: Alex Elder Message-Id: <201012021643.oB2Gh3JL006178@stout.americas.sgi.com> Date: Thu, 02 Dec 2010 10:43:03 -0600 To: torvalds@linux-foundation.org Subject: [GIT PULL] XFS update for 2.6.37-rc5 Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com, akpm@linux-foundation.org User-Agent: Heirloom mailx 12.5 7/5/10 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Linus, please pull the following five XFS bug fixes for 2.6.37. -Alex The following changes since commit 22a5b566c8c442b0b35b3b106795e2f2b3578096: Merge branch 'for_linus' of git://github.com/at91linux/linux-2.6-at91 (2010-11-30 17:57:57 -0800) are available in the git repository at: git://oss.sgi.com/xfs/xfs for-linus Dave Chinner (5): xfs: fix failed write truncation handling. xfs: push stale, pinned buffers on trylock failures xfs: delayed alloc blocks beyond EOF are valid after writeback xfs: avoid moving stale inodes in the AIL xfs: only run xfs_error_test if error injection is active fs/xfs/linux-2.6/xfs_aops.c | 94 ++++++++++++++++++------------------------ fs/xfs/linux-2.6/xfs_buf.c | 35 +++++++--------- fs/xfs/xfs_bmap.c | 85 ++++++++++++++++++++++++++++++++++++++- fs/xfs/xfs_bmap.h | 5 ++ fs/xfs/xfs_dfrag.c | 13 ++++++ fs/xfs/xfs_error.c | 3 + fs/xfs/xfs_error.h | 5 +- fs/xfs/xfs_inode_item.c | 31 +++++++++++--- 8 files changed, 188 insertions(+), 83 deletions(-) From msnitzer@redhat.com Thu Dec 2 15:21:03 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB2LL2Jg041167 for ; Thu, 2 Dec 2010 15:21:03 -0600 X-ASG-Debug-ID: 1291324966-1fd003610000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 414491BE224 for ; Thu, 2 Dec 2010 13:22:46 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id yDVCpbiFyUxs9S6S for ; Thu, 02 Dec 2010 13:22:46 -0800 (PST) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oB2LMYvk030630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Dec 2010 16:22:34 -0500 Received: from localhost (dhcp-100-19-150.bos.redhat.com [10.16.19.150]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id oB2LMS4R002275 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 2 Dec 2010 16:22:28 -0500 Date: Thu, 2 Dec 2010 16:22:27 -0500 From: Mike Snitzer To: LVM general discussion and development Cc: Spelic , Christoph Hellwig , "linux-kernel@vger.kernel.org" , xfs@oss.sgi.com, npiggin@kernel.dk, dm-devel@redhat.com X-ASG-Orig-Subj: Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram Subject: Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram Message-ID: <20101202212227.GA22703@redhat.com> References: <4CF7A539.1050206@shiftmail.org> <20101202141134.GA22012@infradead.org> <4CF7A9C4.2040607@shiftmail.org> <20101202141737.GA29799@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101202141737.GA29799@infradead.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1291324967 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Dec 02 2010 at 9:17am -0500, Christoph Hellwig wrote: > On Thu, Dec 02, 2010 at 03:14:28PM +0100, Spelic wrote: > > On 12/02/2010 03:11 PM, Christoph Hellwig wrote: > > >I'm pretty sure you have CONFIG_DEBUG_BLOCK_EXT_DEVT enabled. This > > >option must never be enabled, as it causes block devices to be > > >randomly renumered. Together with the ramdisk driver overloading > > >the BLKFLSBUF ioctl to discard all data it guarantees you to get > > >data loss like yours. > > > > Nope... > > > > # CONFIG_DEBUG_BLOCK_EXT_DEVT is not set > > Hmm, I suspect dm-linear's dumb forwarding of ioctls has the same > effect. For the benefit of others: - mkfs.xfs will avoid sending BLKFLSBUF to any device whose major is ramdisk's major, this dates back to 2004: http://oss.sgi.com/archives/xfs/2004-08/msg00463.html - but because a kpartx partition overlay (linear DM mapping) is used for the /dev/ram0p1 device, mkfs.xfs only sees a device with DM's major - so mkfs.xfs sends BLKFLSBUF to the DM device blissfully unaware that the backing device (behind the DM linear target) is a brd device - DM will forward the BLKFLSBUF ioctl to brd, which triggers drivers/block/brd.c:brd_ioctl (nuking the entire ramdisk in the process) So coming full circle this is what hch was referring to when he mentioned: 1) "ramdisk driver overloading the BLKFLSBUF ioctl ..." 2) "dm-linear's dumb forwarding of ioctls ..." I really can't see DM adding a specific check for ramdisk's major when forwarding the BLKFLSBUF ioctl. brd has direct partition support (see commit d7853d1f8932c) so maybe kpartx should just blacklist /dev/ram devices? Alternatively, what about switching brd away from overloading BLKFLSBUF to a real implementation of (overloaded) BLKDISCARD support in brd.c? One that doesn't blindly nuke the entire device but that properly processes the discard request. Mike From msnitzer@redhat.com Thu Dec 2 16:06:35 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB2M6Ybd043219 for ; Thu, 2 Dec 2010 16:06:35 -0600 X-ASG-Debug-ID: 1291327698-6ba800bf0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 84B431BE190 for ; Thu, 2 Dec 2010 14:08:18 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id bKZwh1D1QxYAFsAm for ; Thu, 02 Dec 2010 14:08:18 -0800 (PST) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oB2M8CQX024459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 2 Dec 2010 17:08:12 -0500 Received: from localhost (dhcp-100-19-150.bos.redhat.com [10.16.19.150]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id oB2M85VB020026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 2 Dec 2010 17:08:06 -0500 Date: Thu, 2 Dec 2010 17:08:05 -0500 From: Mike Snitzer To: LVM general discussion and development Cc: Spelic , Christoph Hellwig , "linux-kernel@vger.kernel.org" , xfs@oss.sgi.com, npiggin@kernel.dk, dm-devel@redhat.com, tytso@mit.edu X-ASG-Orig-Subj: Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram Subject: Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram Message-ID: <20101202220805.GA23388@redhat.com> References: <4CF7A539.1050206@shiftmail.org> <20101202141134.GA22012@infradead.org> <4CF7A9C4.2040607@shiftmail.org> <20101202141737.GA29799@infradead.org> <20101202212227.GA22703@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101202212227.GA22703@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1291327699 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Dec 02 2010 at 4:22pm -0500, Mike Snitzer wrote: > On Thu, Dec 02 2010 at 9:17am -0500, > Christoph Hellwig wrote: > > > On Thu, Dec 02, 2010 at 03:14:28PM +0100, Spelic wrote: > > > On 12/02/2010 03:11 PM, Christoph Hellwig wrote: > > > >I'm pretty sure you have CONFIG_DEBUG_BLOCK_EXT_DEVT enabled. This > > > >option must never be enabled, as it causes block devices to be > > > >randomly renumered. Together with the ramdisk driver overloading > > > >the BLKFLSBUF ioctl to discard all data it guarantees you to get > > > >data loss like yours. > > > > > > Nope... > > > > > > # CONFIG_DEBUG_BLOCK_EXT_DEVT is not set > > > > Hmm, I suspect dm-linear's dumb forwarding of ioctls has the same > > effect. > > For the benefit of others: > - mkfs.xfs will avoid sending BLKFLSBUF to any device whose major is > ramdisk's major, this dates back to 2004: > http://oss.sgi.com/archives/xfs/2004-08/msg00463.html > - but because a kpartx partition overlay (linear DM mapping) is used for > the /dev/ram0p1 device, mkfs.xfs only sees a device with DM's major > - so mkfs.xfs sends BLKFLSBUF to the DM device blissfully unaware that > the backing device (behind the DM linear target) is a brd device > - DM will forward the BLKFLSBUF ioctl to brd, which triggers > drivers/block/brd.c:brd_ioctl (nuking the entire ramdisk in the > process) > > So coming full circle this is what hch was referring to when he > mentioned: > 1) "ramdisk driver overloading the BLKFLSBUF ioctl ..." > 2) "dm-linear's dumb forwarding of ioctls ..." > > I really can't see DM adding a specific check for ramdisk's major when > forwarding the BLKFLSBUF ioctl. > > brd has direct partition support (see commit d7853d1f8932c) so maybe > kpartx should just blacklist /dev/ram devices? > > Alternatively, what about switching brd away from overloading BLKFLSBUF > to a real implementation of (overloaded) BLKDISCARD support in brd.c? > One that doesn't blindly nuke the entire device but that properly > processes the discard request. Hmm, any chance we could revisit this approach? http://lkml.indiana.edu/hypermail/linux/kernel/0405.3/0998.html From SRS0+MKu5+5+fromorbit.com=david@internode.on.net Thu Dec 2 16:43:28 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB2MhROQ044750 for ; Thu, 2 Dec 2010 16:43:28 -0600 X-ASG-Debug-ID: 1291329908-409402ba0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 51346137A73E for ; Thu, 2 Dec 2010 14:45:09 -0800 (PST) Received: from mail.internode.on.net (bld-mail17.adl2.internode.on.net [150.101.137.102]) by cuda.sgi.com with ESMTP id eWZXz8OSPff13P7d for ; Thu, 02 Dec 2010 14:45:09 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 48357133-1927428 for multiple; Fri, 03 Dec 2010 09:15:07 +1030 (CDT) Received: from dave by dastard with local (Exim 4.71) (envelope-from ) id 1POHti-0007hj-6h; Fri, 03 Dec 2010 09:45:06 +1100 Date: Fri, 3 Dec 2010 09:45:06 +1100 From: Dave Chinner To: Ajeet Yadav Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS mount fail: XFS_WANT_CORRUPTED_GOTO fs/xfs/xfs_alloc.c Subject: Re: XFS mount fail: XFS_WANT_CORRUPTED_GOTO fs/xfs/xfs_alloc.c Message-ID: <20101202224506.GY16922@dastard> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: bld-mail17.adl2.internode.on.net[150.101.137.102] X-Barracuda-Start-Time: 1291329911 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48302 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Dec 02, 2010 at 12:31:30PM +0530, Ajeet Yadav wrote: > Dear all, > This is XFS fail mount log on linux 2.6.30.9 > > XFS mounting filesystem sda2 > Starting XFS recovery on filesystem: sda2 (logdev: internal) > XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1629 of file > fs/xfs/xfs_alloc.c. Caller 0x80129658 > Call Trace: > [<802dedc8>] dump_stack+0x8/0x34 from[<80127400>] > xfs_free_ag_extent+0x128/0x7ac > [<80127400>] xfs_free_ag_extent+0x128/0x7ac from[<80129658>] > xfs_free_extent+0xb8/0xe8 > [<80129658>] xfs_free_extent+0xb8/0xe8 from[<80163978>] > xlog_recover_process_efi+0x160/0x214 > [<80163978>] xlog_recover_process_efi+0x160/0x214 from[<80163ac4>] > xlog_recover_process_efis+0x98/0x11c > [<80163ac4>] xlog_recover_process_efis+0x98/0x11c from[<8016663c>] > xlog_recover_finish+0x28/0xdc > [<8016663c>] xlog_recover_finish+0x28/0xdc from[<8016aec0>] > xfs_mountfs+0x4d0/0x610 > [<8016aec0>] xfs_mountfs+0x4d0/0x610 from[<80184434>] > xfs_fs_fill_super+0x1fc/0x418 > [<80184434>] xfs_fs_fill_super+0x1fc/0x418 from[<800bae48>] > get_sb_bdev+0x11c/0x1c0 > [<800bae48>] get_sb_bdev+0x11c/0x1c0 from[<80181f20>] > xfs_fs_get_sb+0x20/0x2c > [<80181f20>] xfs_fs_get_sb+0x20/0x2c from[<800b9424>] > vfs_kern_mount+0x68/0xd0 > [<800b9424>] vfs_kern_mount+0x68/0xd0 from[<800b94f0>] > do_kern_mount+0x54/0x118 > [<800b94f0>] do_kern_mount+0x54/0x118 from[<800d44e8>] do_mount+0x7b4/0x828 > [<800d44e8>] do_mount+0x7b4/0x828 from[<800d45f8>] sys_mount+0x9c/0x194 > [<800d45f8>] sys_mount+0x9c/0x194 from[<800102c4>] stack_done+0x20/0x3c > > Failed to recover EFIs on filesystem: sda2 > XFS: log mount finish failed You corrupted a free space btree. Care to tell uswhat test you were running that caused this? Did you pull the plug on the device during a copy again? Cheers, Dave. -- Dave Chinner david@fromorbit.com From SRS0+Ztt8+5+fromorbit.com=david@internode.on.net Thu Dec 2 17:06:17 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB2N6GOW045850 for ; Thu, 2 Dec 2010 17:06:16 -0600 X-ASG-Debug-ID: 1291331278-1d6f013e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 643181BE568 for ; Thu, 2 Dec 2010 15:07:59 -0800 (PST) Received: from mail.internode.on.net (bld-mail12.adl6.internode.on.net [150.101.137.97]) by cuda.sgi.com with ESMTP id XcfMHcds7sDUAg62 for ; Thu, 02 Dec 2010 15:07:59 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 48608204-1927428 for multiple; Fri, 03 Dec 2010 09:37:45 +1030 (CDT) Received: from dave by dastard with local (Exim 4.71) (envelope-from ) id 1POIFb-0007jg-U3; Fri, 03 Dec 2010 10:07:43 +1100 Date: Fri, 3 Dec 2010 10:07:43 +1100 From: Dave Chinner To: Spelic Cc: "linux-kernel@vger.kernel.org" , xfs@oss.sgi.com, linux-lvm@redhat.com X-ASG-Orig-Subj: Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram Subject: Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram Message-ID: <20101202230743.GZ16922@dastard> References: <4CF7A539.1050206@shiftmail.org> <4CF7A9CF.2020904@shiftmail.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CF7A9CF.2020904@shiftmail.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: bld-mail12.adl6.internode.on.net[150.101.137.97] X-Barracuda-Start-Time: 1291331280 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48303 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Dec 02, 2010 at 03:14:39PM +0100, Spelic wrote: > Sorry for replying to my own email already > one more thing on the 3rd bug: > > On 12/02/2010 02:55 PM, Spelic wrote: > >Hello all > >[CUT] > >....... > >with NFS over over Infiniband over XFS over > >ramdisk it is possible to write a file (2.3GB) which is larger > >than > > This is also reproducible with: > NFS over TCP over Ethernet over XFS over ramdisk. > You don't need infiniband for this. > With ethernet it doesn't hang (that's another bug, for RDMA people, > in the othter thread) but the file is still 1.9GB, i.e. larger than > the device. > > > Look, after running the test over ethernet, > at server side: > > # ll -h /mnt/ram > total 1.5G > drwxr-xr-x 2 root root 21 2010-12-02 12:54 ./ > drwxr-xr-x 3 root root 4.0K 2010-11-29 23:51 ../ > -rw-r--r-- 1 root root 1.9G 2010-12-02 15:04 zerofile This is a classic ENOSPC vs NFS client writeback overcommit caching issue. Have a look at the block map output - I bet theres holes in the file and it's only consuming 1.5GB of disk space. use xfs_bmap to check this. du should tell you the same thing. Basically, the NFS client overcommits the server filesystem space by doing local writeback caching. Hence it caches 1.9GB of data before it gets the first ENOSPC error back from the server at around 1.5GB of written data. At that point, the data that gets ENOSPC errors is tossed by the NFS client, and a ENOSPC error is placed on the address space to be reported to the next write/sync call. That gets to the dd process when it's 1.9GB into the write. However, there is still (in this case) 400MB of dirty data in the NFS client cache that it will try to write to the server. Because XFS uses speculative preallocation and reserves some space for metadata allocation during delayed allocation, it's handling of the initial ENOSPC condition can result in some space being freed up again as unused reserved metadata space is returned to the free pool as delalloc occurs during server writeback. This usually takes a second or two to complete. As a result, shortly after the first ENOSPC has been reported and subsequent writes have also ENOSPC, we can have space freed up and another write will succeed. At that point, the write that succeeds will be a different offset to the last one that succeeded, leaving a hole in the file and moving the EOF well past 1.5GB. That will go on until there really is no space left at all or the NFS client has no more dirty data to send. Basically, what you see it not a bug in XFS, it is a result of NFS clients being able to overcommit server filesystem space and the interaction that has with the way the filesystem on the NFS server handles ENOSPC. Cheers, Dave. -- Dave Chinner david@fromorbit.com From stan@hardwarefreak.com Thu Dec 2 18:56:59 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB30uwMC050877 for ; Thu, 2 Dec 2010 18:56:59 -0600 X-ASG-Debug-ID: 1291337922-5645009a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from greer.hardwarefreak.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 21307140C06B for ; Thu, 2 Dec 2010 16:58:42 -0800 (PST) Received: from greer.hardwarefreak.com (mo-65-41-216-221.sta.embarqhsd.net [65.41.216.221]) by cuda.sgi.com with ESMTP id VVFDpcpLI1pvjkKH for ; Thu, 02 Dec 2010 16:58:42 -0800 (PST) Received: from [192.168.100.53] (gffx.hardwarefreak.com [192.168.100.53]) by greer.hardwarefreak.com (Postfix) with ESMTP id 935C16C0B9 for ; Thu, 2 Dec 2010 18:58:41 -0600 (CST) Message-ID: <4CF840C1.1030301@hardwarefreak.com> Date: Thu, 02 Dec 2010 18:58:41 -0600 From: Stan Hoeppner User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs_repair of critical volume Subject: Re: xfs_repair of critical volume References: <75C248E3-2C99-426E-AE7D-9EC543726796@ucsc.edu> <20101117074708.GP22876@dastard> <201012021233.07213@zmi.at> In-Reply-To: <201012021233.07213@zmi.at> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mo-65-41-216-221.sta.embarqhsd.net[65.41.216.221] X-Barracuda-Start-Time: 1291337923 X-Barracuda-Bayes: INNOCENT GLOBAL 0.1492 1.0000 -1.1057 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.51 X-Barracuda-Spam-Status: No, SCORE=-0.51 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC5_MJ1963, RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48309 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS 0.50 BSF_SC5_MJ1963 Custom Rule MJ1963 X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Michael Monnerie put forth on 12/2/2010 5:33 AM: > Thanks, and wow: what an amazing filesystem can recover such an event! FSVO "recover". It's definitely amazing that he didn't lose all of his data as a result of his hardware failures and storage configuration. -- Stan From SRS0+srf8+6+fromorbit.com=dave@internode.on.net Thu Dec 2 19:54:14 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,J_CHICKENPOX_63, J_CHICKENPOX_74 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB31sDh9054378 for ; Thu, 2 Dec 2010 19:54:14 -0600 X-ASG-Debug-ID: 1291341355-5efc015d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8A5D8140CC45 for ; Thu, 2 Dec 2010 17:55:55 -0800 (PST) Received: from mail.internode.on.net (bld-mail16.adl2.internode.on.net [150.101.137.101]) by cuda.sgi.com with ESMTP id 01ZTFtFKyjewlBqd for ; Thu, 02 Dec 2010 17:55:55 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 48527034-1927428 for ; Fri, 03 Dec 2010 12:25:54 +1030 (CDT) Received: from chute ([192.168.1.1] helo=disappointment) by dastard with esmtp (Exim 4.71) (envelope-from ) id 1POKsK-0007wk-QZ for xfs@oss.sgi.com; Fri, 03 Dec 2010 12:55:52 +1100 Received: from dave by disappointment with local (Exim 4.72) (envelope-from ) id 1POKrj-00089z-L9 for xfs@oss.sgi.com; Fri, 03 Dec 2010 12:55:15 +1100 From: Dave Chinner To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH] xfs: prevent NMI timeouts in cmn_err Subject: [PATCH] xfs: prevent NMI timeouts in cmn_err Date: Fri, 3 Dec 2010 12:55:15 +1100 Message-Id: <1291341315-31338-1-git-send-email-david@fromorbit.com> X-Mailer: git-send-email 1.7.2.3 X-Barracuda-Connect: bld-mail16.adl2.internode.on.net[150.101.137.101] X-Barracuda-Start-Time: 1291341357 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48313 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean From: Dave Chinner We currently have a global error message buffer in cmn_err that is protected by a spin lock that disables interrupts. Recently there have been reports of NMI timeouts occurring when the console is being flooded by SCSI error reports due to cmn_err() getting stuck trying to print to the console while holding this lock (i.e. with interrupts disabled). The NMI watchdog is seeing this CPU as non-responding and so is triggering a panic. While the trigger for the reported case is SCSI errors, pretty much anything that spams the kernel log could cause this to occur. Realistically the only reason that we have the intemediate message buffer is to prepend the correct kernel log level prefix to the log message. The only reason we have the lock is to protect the global message buffer and the only reason the message buffer is global is to keep it off the stack. Hence if we can avoid needing a global message buffer we avoid needing the lock, and we can do this with a small amount of cleanup and some preprocessor tricks: 1. clean up xfs_cmn_err() panic mask functionality to avoid needing debug code in xfs_cmn_err() 2. remove the couple of "!" message prefixes that still exist that the existing cmn_err() code steps over. 3. redefine CE_* levels directly to KERN_* 4. redefine cmn_err() and friends to use printk() directly via variable argument length macros. By doing this, we can completely remove the cmn_err() code and the lock that is causing the problems, and rely solely on printk() serialisation to ensure that we don't get garbled messages. A series of followup patches is really needed to clean up all the cmn_err() calls and related messages properly, but that results in a series that is not easily back portable to enterprise kernels. Hence this initial fix is only to address the direct problem in the lowest impact way possible. Signed-off-by: Dave Chinner --- fs/xfs/linux-2.6/xfs_sysctl.c | 22 +++++++++++- fs/xfs/support/debug.c | 76 ----------------------------------------- fs/xfs/support/debug.h | 40 +++++++++++++++++----- fs/xfs/xfs_error.c | 31 ----------------- fs/xfs/xfs_error.h | 14 ++----- fs/xfs/xfs_log.c | 2 +- fs/xfs/xfs_log_recover.c | 2 +- 7 files changed, 58 insertions(+), 129 deletions(-) diff --git a/fs/xfs/linux-2.6/xfs_sysctl.c b/fs/xfs/linux-2.6/xfs_sysctl.c index 7bb5092..768acd8 100644 --- a/fs/xfs/linux-2.6/xfs_sysctl.c +++ b/fs/xfs/linux-2.6/xfs_sysctl.c @@ -51,6 +51,26 @@ xfs_stats_clear_proc_handler( return ret; } + +STATIC int +xfs_panic_mask_proc_handler( + ctl_table *ctl, + int write, + void __user *buffer, + size_t *lenp, + loff_t *ppos) +{ + int ret, *valp = ctl->data; + + ret = proc_dointvec_minmax(ctl, write, buffer, lenp, ppos); + if (!ret && write) { + xfs_panic_mask = *valp; +#ifdef DEBUG + xfs_panic_mask |= (XFS_PTAG_SHUTDOWN_CORRUPT | XFS_PTAG_LOGRES); +#endif + } + return ret; +} #endif /* CONFIG_PROC_FS */ static ctl_table xfs_table[] = { @@ -77,7 +97,7 @@ static ctl_table xfs_table[] = { .data = &xfs_params.panic_mask.val, .maxlen = sizeof(int), .mode = 0644, - .proc_handler = proc_dointvec_minmax, + .proc_handler = xfs_panic_mask_proc_handler, .extra1 = &xfs_params.panic_mask.min, .extra2 = &xfs_params.panic_mask.max }, diff --git a/fs/xfs/support/debug.c b/fs/xfs/support/debug.c index 975aa10..fa39e98 100644 --- a/fs/xfs/support/debug.c +++ b/fs/xfs/support/debug.c @@ -25,82 +25,6 @@ #include "xfs_mount.h" #include "xfs_error.h" -static char message[1024]; /* keep it off the stack */ -static DEFINE_SPINLOCK(xfs_err_lock); - -/* Translate from CE_FOO to KERN_FOO, err_level(CE_FOO) == KERN_FOO */ -#define XFS_MAX_ERR_LEVEL 7 -#define XFS_ERR_MASK ((1 << 3) - 1) -static const char * const err_level[XFS_MAX_ERR_LEVEL+1] = - {KERN_EMERG, KERN_ALERT, KERN_CRIT, - KERN_ERR, KERN_WARNING, KERN_NOTICE, - KERN_INFO, KERN_DEBUG}; - -void -cmn_err(register int level, char *fmt, ...) -{ - char *fp = fmt; - int len; - ulong flags; - va_list ap; - - level &= XFS_ERR_MASK; - if (level > XFS_MAX_ERR_LEVEL) - level = XFS_MAX_ERR_LEVEL; - spin_lock_irqsave(&xfs_err_lock,flags); - va_start(ap, fmt); - if (*fmt == '!') fp++; - len = vsnprintf(message, sizeof(message), fp, ap); - if (len >= sizeof(message)) - len = sizeof(message) - 1; - if (message[len-1] == '\n') - message[len-1] = 0; - printk("%s%s\n", err_level[level], message); - va_end(ap); - spin_unlock_irqrestore(&xfs_err_lock,flags); - BUG_ON(level == CE_PANIC); -} - -void -xfs_fs_vcmn_err( - int level, - struct xfs_mount *mp, - char *fmt, - va_list ap) -{ - unsigned long flags; - int len = 0; - - level &= XFS_ERR_MASK; - if (level > XFS_MAX_ERR_LEVEL) - level = XFS_MAX_ERR_LEVEL; - - spin_lock_irqsave(&xfs_err_lock,flags); - - if (mp) { - len = sprintf(message, "Filesystem \"%s\": ", mp->m_fsname); - - /* - * Skip the printk if we can't print anything useful - * due to an over-long device name. - */ - if (len >= sizeof(message)) - goto out; - } - - len = vsnprintf(message + len, sizeof(message) - len, fmt, ap); - if (len >= sizeof(message)) - len = sizeof(message) - 1; - if (message[len-1] == '\n') - message[len-1] = 0; - - printk("%s%s\n", err_level[level], message); - out: - spin_unlock_irqrestore(&xfs_err_lock,flags); - - BUG_ON(level == CE_PANIC); -} - void assfail(char *expr, char *file, int line) { diff --git a/fs/xfs/support/debug.h b/fs/xfs/support/debug.h index d2d2046..f659bd0 100644 --- a/fs/xfs/support/debug.h +++ b/fs/xfs/support/debug.h @@ -20,15 +20,37 @@ #include -#define CE_DEBUG 7 /* debug */ -#define CE_CONT 6 /* continuation */ -#define CE_NOTE 5 /* notice */ -#define CE_WARN 4 /* warning */ -#define CE_ALERT 1 /* alert */ -#define CE_PANIC 0 /* panic */ - -extern void cmn_err(int, char *, ...) - __attribute__ ((format (printf, 2, 3))); +#define CE_DEBUG KERN_DEBUG +#define CE_CONT KERN_INFO +#define CE_NOTE KERN_NOTICE +#define CE_WARN KERN_WARNING +#define CE_ALERT KERN_ALERT +#define CE_PANIC KERN_EMERG + +#define cmn_err(lvl, fmt, args...) \ + do { \ + printk(lvl fmt, ## args); \ + BUG_ON(strncmp(lvl, KERN_EMERG, strlen(KERN_EMERG)) == 0); \ + } while (0) + +#define xfs_fs_cmn_err(lvl, mp, fmt, args...) \ + do { \ + printk(lvl "Filesystem %s: " fmt, (mp)->m_fsname, ## args); \ + BUG_ON(strncmp(lvl, KERN_EMERG, strlen(KERN_EMERG)) == 0); \ + } while (0) + +/* All callers to xfs_cmn_err use CE_ALERT, so don't bother testing lvl */ +#define xfs_cmn_err(panic_tag, lvl, mp, fmt, args...) \ + do { \ + int panic = 0; \ + if (xfs_panic_mask && (xfs_panic_mask & panic_tag)) { \ + printk(KERN_ALERT "XFS: Transforming an alert into a BUG."); \ + panic = 1; \ + } \ + printk(KERN_ALERT "Filesystem %s: " fmt, (mp)->m_fsname, ## args); \ + BUG_ON(panic); \ + } while (0) + extern void assfail(char *expr, char *f, int l); #define ASSERT_ALWAYS(expr) \ diff --git a/fs/xfs/xfs_error.c b/fs/xfs/xfs_error.c index c78cc6a..4c7db74 100644 --- a/fs/xfs/xfs_error.c +++ b/fs/xfs/xfs_error.c @@ -152,37 +152,6 @@ xfs_errortag_clearall(xfs_mount_t *mp, int loud) } #endif /* DEBUG */ - -void -xfs_fs_cmn_err(int level, xfs_mount_t *mp, char *fmt, ...) -{ - va_list ap; - - va_start(ap, fmt); - xfs_fs_vcmn_err(level, mp, fmt, ap); - va_end(ap); -} - -void -xfs_cmn_err(int panic_tag, int level, xfs_mount_t *mp, char *fmt, ...) -{ - va_list ap; - -#ifdef DEBUG - xfs_panic_mask |= (XFS_PTAG_SHUTDOWN_CORRUPT | XFS_PTAG_LOGRES); -#endif - - if (xfs_panic_mask && (xfs_panic_mask & panic_tag) - && (level & CE_ALERT)) { - level &= ~CE_ALERT; - level |= CE_PANIC; - cmn_err(CE_ALERT, "XFS: Transforming an alert into a BUG."); - } - va_start(ap, fmt); - xfs_fs_vcmn_err(level, mp, fmt, ap); - va_end(ap); -} - void xfs_error_report( const char *tag, diff --git a/fs/xfs/xfs_error.h b/fs/xfs/xfs_error.h index f338847..6b518d2 100644 --- a/fs/xfs/xfs_error.h +++ b/fs/xfs/xfs_error.h @@ -162,21 +162,15 @@ extern int xfs_errortag_clearall(xfs_mount_t *mp, int loud); struct xfs_mount; -extern void xfs_fs_vcmn_err(int level, struct xfs_mount *mp, - char *fmt, va_list ap) - __attribute__ ((format (printf, 3, 0))); -extern void xfs_cmn_err(int panic_tag, int level, struct xfs_mount *mp, - char *fmt, ...) - __attribute__ ((format (printf, 4, 5))); -extern void xfs_fs_cmn_err(int level, struct xfs_mount *mp, char *fmt, ...) - __attribute__ ((format (printf, 3, 4))); - extern void xfs_hex_dump(void *p, int length); #define xfs_fs_repair_cmn_err(level, mp, fmt, args...) \ xfs_fs_cmn_err(level, mp, fmt " Unmount and run xfs_repair.", ## args) #define xfs_fs_mount_cmn_err(f, fmt, args...) \ - ((f & XFS_MFSI_QUIET)? (void)0 : cmn_err(CE_WARN, "XFS: " fmt, ## args)) + do { \ + if (!(f & XFS_MFSI_QUIET)) \ + cmn_err(CE_WARN, "XFS: " fmt, ## args); \ + } while (0) #endif /* __XFS_ERROR_H__ */ diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c index abdcbd0..2209035 100644 --- a/fs/xfs/xfs_log.c +++ b/fs/xfs/xfs_log.c @@ -431,7 +431,7 @@ xfs_log_mount( cmn_err(CE_NOTE, "XFS mounting filesystem %s", mp->m_fsname); else { cmn_err(CE_NOTE, - "!Mounting filesystem \"%s\" in no-recovery mode. Filesystem will be inconsistent.", + "Mounting filesystem \"%s\" in no-recovery mode. Filesystem will be inconsistent.", mp->m_fsname); ASSERT(mp->m_flags & XFS_MOUNT_RDONLY); } diff --git a/fs/xfs/xfs_log_recover.c b/fs/xfs/xfs_log_recover.c index 6e7dfbb..411f3a9 100644 --- a/fs/xfs/xfs_log_recover.c +++ b/fs/xfs/xfs_log_recover.c @@ -3934,7 +3934,7 @@ xlog_recover_finish( log->l_flags &= ~XLOG_RECOVERY_NEEDED; } else { cmn_err(CE_DEBUG, - "!Ending clean XFS mount for filesystem: %s\n", + "Ending clean XFS mount for filesystem: %s\n", log->l_mp->m_fsname); } return 0; -- 1.7.2.3 From lmcilroy@redhat.com Thu Dec 2 21:50:01 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,J_CHICKENPOX_63, J_CHICKENPOX_74 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB33o0Rw059397 for ; Thu, 2 Dec 2010 21:50:01 -0600 X-ASG-Debug-ID: 1291348304-6039002c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx3-phx2.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 86E4C140D133 for ; Thu, 2 Dec 2010 19:51:44 -0800 (PST) Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id C8aEQCkSdAmJ8kZ3 for ; Thu, 02 Dec 2010 19:51:44 -0800 (PST) X-ASG-Whitelist: Barracuda Reputation Received: from mail05.corp.redhat.com (zmail05.collab.prod.int.phx2.redhat.com [10.5.5.46]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id oB33pW0H003246; Thu, 2 Dec 2010 22:51:32 -0500 Date: Thu, 2 Dec 2010 22:51:32 -0500 (EST) From: Lachlan McIlroy Reply-To: Lachlan McIlroy To: Dave Chinner Cc: xfs@oss.sgi.com Message-ID: <275948151.359301291348292101.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> In-Reply-To: <121488966.359171291347997519.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> X-ASG-Orig-Subj: Re: [PATCH] xfs: prevent NMI timeouts in cmn_err Subject: Re: [PATCH] xfs: prevent NMI timeouts in cmn_err MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.5.71] X-Mailer: Zimbra 5.0.21_GA_3150.RHEL4_64 (ZimbraWebClient - FF3.0 (Linux)/5.0.21_GA_3150.RHEL4_64) X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1291348305 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Dave, overall it looks good - just a few minor points below. Thanks for doing this. ----- "Dave Chinner" wrote: > From: Dave Chinner > > We currently have a global error message buffer in cmn_err that is > protected by a spin lock that disables interrupts. Recently there > have been reports of NMI timeouts occurring when the console is > being flooded by SCSI error reports due to cmn_err() getting stuck > trying to print to the console while holding this lock (i.e. with > interrupts disabled). The NMI watchdog is seeing this CPU as > non-responding and so is triggering a panic. While the trigger for > the reported case is SCSI errors, pretty much anything that spams > the kernel log could cause this to occur. > > Realistically the only reason that we have the intemediate message > buffer is to prepend the correct kernel log level prefix to the log > message. The only reason we have the lock is to protect the global > message buffer and the only reason the message buffer is global is > to keep it off the stack. Hence if we can avoid needing a global > message buffer we avoid needing the lock, and we can do this with a > small amount of cleanup and some preprocessor tricks: > > 1. clean up xfs_cmn_err() panic mask functionality to avoid > needing debug code in xfs_cmn_err() > 2. remove the couple of "!" message prefixes that still exist that > the existing cmn_err() code steps over. > 3. redefine CE_* levels directly to KERN_* > 4. redefine cmn_err() and friends to use printk() directly > via variable argument length macros. > > By doing this, we can completely remove the cmn_err() code and the > lock that is causing the problems, and rely solely on printk() > serialisation to ensure that we don't get garbled messages. > > A series of followup patches is really needed to clean up all the > cmn_err() calls and related messages properly, but that results in a > series that is not easily back portable to enterprise kernels. Hence > this initial fix is only to address the direct problem in the lowest > impact way possible. > > Signed-off-by: Dave Chinner > --- > fs/xfs/linux-2.6/xfs_sysctl.c | 22 +++++++++++- > fs/xfs/support/debug.c | 76 > ----------------------------------------- > fs/xfs/support/debug.h | 40 +++++++++++++++++----- > fs/xfs/xfs_error.c | 31 ----------------- > fs/xfs/xfs_error.h | 14 ++----- > fs/xfs/xfs_log.c | 2 +- > fs/xfs/xfs_log_recover.c | 2 +- > 7 files changed, 58 insertions(+), 129 deletions(-) > > diff --git a/fs/xfs/linux-2.6/xfs_sysctl.c > b/fs/xfs/linux-2.6/xfs_sysctl.c > index 7bb5092..768acd8 100644 > --- a/fs/xfs/linux-2.6/xfs_sysctl.c > +++ b/fs/xfs/linux-2.6/xfs_sysctl.c > @@ -51,6 +51,26 @@ xfs_stats_clear_proc_handler( > > return ret; > } > + > +STATIC int > +xfs_panic_mask_proc_handler( > + ctl_table *ctl, > + int write, > + void __user *buffer, > + size_t *lenp, > + loff_t *ppos) > +{ > + int ret, *valp = ctl->data; > + > + ret = proc_dointvec_minmax(ctl, write, buffer, lenp, ppos); > + if (!ret && write) { > + xfs_panic_mask = *valp; > +#ifdef DEBUG > + xfs_panic_mask |= (XFS_PTAG_SHUTDOWN_CORRUPT | XFS_PTAG_LOGRES); > +#endif > + } > + return ret; > +} > #endif /* CONFIG_PROC_FS */ > > static ctl_table xfs_table[] = { > @@ -77,7 +97,7 @@ static ctl_table xfs_table[] = { > .data = &xfs_params.panic_mask.val, > .maxlen = sizeof(int), > .mode = 0644, > - .proc_handler = proc_dointvec_minmax, > + .proc_handler = xfs_panic_mask_proc_handler, > .extra1 = &xfs_params.panic_mask.min, > .extra2 = &xfs_params.panic_mask.max > }, > diff --git a/fs/xfs/support/debug.c b/fs/xfs/support/debug.c > index 975aa10..fa39e98 100644 > --- a/fs/xfs/support/debug.c > +++ b/fs/xfs/support/debug.c > @@ -25,82 +25,6 @@ > #include "xfs_mount.h" > #include "xfs_error.h" > > -static char message[1024]; /* keep it off the stack */ > -static DEFINE_SPINLOCK(xfs_err_lock); > - > -/* Translate from CE_FOO to KERN_FOO, err_level(CE_FOO) == KERN_FOO > */ > -#define XFS_MAX_ERR_LEVEL 7 > -#define XFS_ERR_MASK ((1 << 3) - 1) > -static const char * const err_level[XFS_MAX_ERR_LEVEL+1] = > - {KERN_EMERG, KERN_ALERT, KERN_CRIT, > - KERN_ERR, KERN_WARNING, KERN_NOTICE, > - KERN_INFO, KERN_DEBUG}; > - > -void > -cmn_err(register int level, char *fmt, ...) > -{ > - char *fp = fmt; > - int len; > - ulong flags; > - va_list ap; > - > - level &= XFS_ERR_MASK; > - if (level > XFS_MAX_ERR_LEVEL) > - level = XFS_MAX_ERR_LEVEL; > - spin_lock_irqsave(&xfs_err_lock,flags); > - va_start(ap, fmt); > - if (*fmt == '!') fp++; > - len = vsnprintf(message, sizeof(message), fp, ap); > - if (len >= sizeof(message)) > - len = sizeof(message) - 1; > - if (message[len-1] == '\n') > - message[len-1] = 0; > - printk("%s%s\n", err_level[level], message); > - va_end(ap); > - spin_unlock_irqrestore(&xfs_err_lock,flags); > - BUG_ON(level == CE_PANIC); > -} > - > -void > -xfs_fs_vcmn_err( > - int level, > - struct xfs_mount *mp, > - char *fmt, > - va_list ap) > -{ > - unsigned long flags; > - int len = 0; > - > - level &= XFS_ERR_MASK; > - if (level > XFS_MAX_ERR_LEVEL) > - level = XFS_MAX_ERR_LEVEL; > - > - spin_lock_irqsave(&xfs_err_lock,flags); > - > - if (mp) { > - len = sprintf(message, "Filesystem \"%s\": ", mp->m_fsname); > - > - /* > - * Skip the printk if we can't print anything useful > - * due to an over-long device name. > - */ > - if (len >= sizeof(message)) > - goto out; > - } > - > - len = vsnprintf(message + len, sizeof(message) - len, fmt, ap); > - if (len >= sizeof(message)) > - len = sizeof(message) - 1; > - if (message[len-1] == '\n') > - message[len-1] = 0; > - > - printk("%s%s\n", err_level[level], message); > - out: > - spin_unlock_irqrestore(&xfs_err_lock,flags); > - > - BUG_ON(level == CE_PANIC); > -} > - > void > assfail(char *expr, char *file, int line) > { > diff --git a/fs/xfs/support/debug.h b/fs/xfs/support/debug.h > index d2d2046..f659bd0 100644 > --- a/fs/xfs/support/debug.h > +++ b/fs/xfs/support/debug.h > @@ -20,15 +20,37 @@ > > #include > > -#define CE_DEBUG 7 /* debug */ > -#define CE_CONT 6 /* continuation */ > -#define CE_NOTE 5 /* notice */ > -#define CE_WARN 4 /* warning */ > -#define CE_ALERT 1 /* alert */ > -#define CE_PANIC 0 /* panic */ > - > -extern void cmn_err(int, char *, ...) > - __attribute__ ((format (printf, 2, 3))); > +#define CE_DEBUG KERN_DEBUG > +#define CE_CONT KERN_INFO > +#define CE_NOTE KERN_NOTICE > +#define CE_WARN KERN_WARNING > +#define CE_ALERT KERN_ALERT > +#define CE_PANIC KERN_EMERG > + > +#define cmn_err(lvl, fmt, args...) \ > + do { \ > + printk(lvl fmt, ## args); \ The old cmn_err() routine would append a newline if one was not supplied. As far as I know printk() will not do the same so either we need to fix all calls to cmn_err() to supply a '\n' or add it here (at the risk of having two newlines) - maybe: printk(lvl fmt "\n", ## args); > + BUG_ON(strncmp(lvl, KERN_EMERG, strlen(KERN_EMERG)) == 0); \ > + } while (0) > + > +#define xfs_fs_cmn_err(lvl, mp, fmt, args...) \ > + do { \ > + printk(lvl "Filesystem %s: " fmt, (mp)->m_fsname, ## args); \ printk(lvl "Filesystem %s: " fmt "\n", (mp)->m_fsname, ## args); > + BUG_ON(strncmp(lvl, KERN_EMERG, strlen(KERN_EMERG)) == 0); \ > + } while (0) > + > +/* All callers to xfs_cmn_err use CE_ALERT, so don't bother testing > lvl */ > +#define xfs_cmn_err(panic_tag, lvl, mp, fmt, args...) \ > + do { \ > + int panic = 0; \ > + if (xfs_panic_mask && (xfs_panic_mask & panic_tag)) { \ > + printk(KERN_ALERT "XFS: Transforming an alert into a BUG."); \ > + panic = 1; \ > + } \ > + printk(KERN_ALERT "Filesystem %s: " fmt, (mp)->m_fsname, ## args); > \ > + BUG_ON(panic); \ > + } while (0) I think we can simplify this case a bit and remove the panic variable, like this: do { \ printk(KERN_ALERT "Filesystem %s: " fmt "\n", (mp)->m_fsname, ## args); if (xfs_panic_mask && (xfs_panic_mask & panic_tag)) { \ printk(KERN_ALERT "XFS: Transforming an alert into a BUG.\n"); \ BUG_ON(1); \ } \ } while (0) This also reorders the messages which I think makes more sense. > + > extern void assfail(char *expr, char *f, int l); > > #define ASSERT_ALWAYS(expr) \ > diff --git a/fs/xfs/xfs_error.c b/fs/xfs/xfs_error.c > index c78cc6a..4c7db74 100644 > --- a/fs/xfs/xfs_error.c > +++ b/fs/xfs/xfs_error.c > @@ -152,37 +152,6 @@ xfs_errortag_clearall(xfs_mount_t *mp, int loud) > } > #endif /* DEBUG */ > > - > -void > -xfs_fs_cmn_err(int level, xfs_mount_t *mp, char *fmt, ...) > -{ > - va_list ap; > - > - va_start(ap, fmt); > - xfs_fs_vcmn_err(level, mp, fmt, ap); > - va_end(ap); > -} > - > -void > -xfs_cmn_err(int panic_tag, int level, xfs_mount_t *mp, char *fmt, > ...) > -{ > - va_list ap; > - > -#ifdef DEBUG > - xfs_panic_mask |= (XFS_PTAG_SHUTDOWN_CORRUPT | XFS_PTAG_LOGRES); > -#endif > - > - if (xfs_panic_mask && (xfs_panic_mask & panic_tag) > - && (level & CE_ALERT)) { > - level &= ~CE_ALERT; > - level |= CE_PANIC; > - cmn_err(CE_ALERT, "XFS: Transforming an alert into a BUG."); > - } > - va_start(ap, fmt); > - xfs_fs_vcmn_err(level, mp, fmt, ap); > - va_end(ap); > -} > - > void > xfs_error_report( > const char *tag, > diff --git a/fs/xfs/xfs_error.h b/fs/xfs/xfs_error.h > index f338847..6b518d2 100644 > --- a/fs/xfs/xfs_error.h > +++ b/fs/xfs/xfs_error.h > @@ -162,21 +162,15 @@ extern int xfs_errortag_clearall(xfs_mount_t > *mp, int loud); > > struct xfs_mount; > > -extern void xfs_fs_vcmn_err(int level, struct xfs_mount *mp, > - char *fmt, va_list ap) > - __attribute__ ((format (printf, 3, 0))); > -extern void xfs_cmn_err(int panic_tag, int level, struct xfs_mount > *mp, > - char *fmt, ...) > - __attribute__ ((format (printf, 4, 5))); > -extern void xfs_fs_cmn_err(int level, struct xfs_mount *mp, char > *fmt, ...) > - __attribute__ ((format (printf, 3, 4))); > - > extern void xfs_hex_dump(void *p, int length); > > #define xfs_fs_repair_cmn_err(level, mp, fmt, args...) \ > xfs_fs_cmn_err(level, mp, fmt " Unmount and run xfs_repair.", ## > args) > > #define xfs_fs_mount_cmn_err(f, fmt, args...) \ > - ((f & XFS_MFSI_QUIET)? (void)0 : cmn_err(CE_WARN, "XFS: " fmt, ## > args)) > + do { \ > + if (!(f & XFS_MFSI_QUIET)) \ > + cmn_err(CE_WARN, "XFS: " fmt, ## args); \ > + } while (0) > > #endif /* __XFS_ERROR_H__ */ > diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c > index abdcbd0..2209035 100644 > --- a/fs/xfs/xfs_log.c > +++ b/fs/xfs/xfs_log.c > @@ -431,7 +431,7 @@ xfs_log_mount( > cmn_err(CE_NOTE, "XFS mounting filesystem %s", mp->m_fsname); > else { > cmn_err(CE_NOTE, > - "!Mounting filesystem \"%s\" in no-recovery mode. Filesystem will > be inconsistent.", > + "Mounting filesystem \"%s\" in no-recovery mode. Filesystem will > be inconsistent.", > mp->m_fsname); > ASSERT(mp->m_flags & XFS_MOUNT_RDONLY); > } > diff --git a/fs/xfs/xfs_log_recover.c b/fs/xfs/xfs_log_recover.c > index 6e7dfbb..411f3a9 100644 > --- a/fs/xfs/xfs_log_recover.c > +++ b/fs/xfs/xfs_log_recover.c > @@ -3934,7 +3934,7 @@ xlog_recover_finish( > log->l_flags &= ~XLOG_RECOVERY_NEEDED; > } else { > cmn_err(CE_DEBUG, > - "!Ending clean XFS mount for filesystem: %s\n", > + "Ending clean XFS mount for filesystem: %s\n", > log->l_mp->m_fsname); > } > return 0; > -- > 1.7.2.3 > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From SRS0+ohoZ+6+fromorbit.com=david@internode.on.net Thu Dec 2 22:37:07 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,J_CHICKENPOX_32, J_CHICKENPOX_33 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB34b6w1061885 for ; Thu, 2 Dec 2010 22:37:07 -0600 X-ASG-Debug-ID: 1291351129-1ebd00650000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 939671BF14B for ; Thu, 2 Dec 2010 20:38:49 -0800 (PST) Received: from mail.internode.on.net (bld-mail18.adl2.internode.on.net [150.101.137.103]) by cuda.sgi.com with ESMTP id wXxizzRzz70u7Hqv for ; Thu, 02 Dec 2010 20:38:49 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 48350448-1927428 for ; Fri, 03 Dec 2010 15:08:48 +1030 (CDT) Received: from dave by dastard with local (Exim 4.71) (envelope-from ) id 1PONPy-00087q-VW for xfs@oss.sgi.com; Fri, 03 Dec 2010 15:38:47 +1100 Date: Fri, 3 Dec 2010 15:38:46 +1100 From: Dave Chinner To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] xfs: prevent NMI timeouts in cmn_err Subject: Re: [PATCH] xfs: prevent NMI timeouts in cmn_err Message-ID: <20101203043846.GB23339@dastard> References: <1291341315-31338-1-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1291341315-31338-1-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: bld-mail18.adl2.internode.on.net[150.101.137.103] X-Barracuda-Start-Time: 1291351130 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48324 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Fri, Dec 03, 2010 at 12:55:15PM +1100, Dave Chinner wrote: > From: Dave Chinner > > We currently have a global error message buffer in cmn_err that is > protected by a spin lock that disables interrupts. Recently there > have been reports of NMI timeouts occurring when the console is > being flooded by SCSI error reports due to cmn_err() getting stuck > trying to print to the console while holding this lock (i.e. with > interrupts disabled). The NMI watchdog is seeing this CPU as > non-responding and so is triggering a panic. While the trigger for > the reported case is SCSI errors, pretty much anything that spams > the kernel log could cause this to occur. > > Realistically the only reason that we have the intemediate message > buffer is to prepend the correct kernel log level prefix to the log > message. The only reason we have the lock is to protect the global > message buffer and the only reason the message buffer is global is > to keep it off the stack. Hence if we can avoid needing a global > message buffer we avoid needing the lock, and we can do this with a > small amount of cleanup and some preprocessor tricks: > > 1. clean up xfs_cmn_err() panic mask functionality to avoid > needing debug code in xfs_cmn_err() > 2. remove the couple of "!" message prefixes that still exist that > the existing cmn_err() code steps over. > 3. redefine CE_* levels directly to KERN_* > 4. redefine cmn_err() and friends to use printk() directly > via variable argument length macros. > > By doing this, we can completely remove the cmn_err() code and the > lock that is causing the problems, and rely solely on printk() > serialisation to ensure that we don't get garbled messages. > > A series of followup patches is really needed to clean up all the > cmn_err() calls and related messages properly, but that results in a > series that is not easily back portable to enterprise kernels. Hence > this initial fix is only to address the direct problem in the lowest > impact way possible. FWIW, while these macros are the best way to make a simple backport is possible, I just discovered that mainline has a %pV format operator that allows an implementation like: void xfs_fs_cmn_err( const char *lvl, struct xfs_mount *mp, const char *fmt, ...) { struct va_format vaf; va_list args; va_start(args, fmt); vaf.fmt = fmt; vaf.va = &args; printk("%sFilesystem %s: %pV", lvl, mp->m_fsname, &vaf); va_end(args); BUG_ON(strncmp(lvl, KERN_EMERG, strlen(KERN_EMERG)) == 0); } Would this be a preferable method for replacing the existing implementations, or are the macros good enough as the first step of a mainline cleanup? Cheers,,, Dave. -- Dave Chinner david@fromorbit.com From SRS0+BQCf+6+fromorbit.com=david@internode.on.net Thu Dec 2 23:23:06 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB35N6WR063608 for ; Thu, 2 Dec 2010 23:23:06 -0600 X-ASG-Debug-ID: 1291353888-1bf302450000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6328F1BF58E for ; Thu, 2 Dec 2010 21:24:48 -0800 (PST) Received: from mail.internode.on.net (bld-mail17.adl2.internode.on.net [150.101.137.102]) by cuda.sgi.com with ESMTP id 8cf0E186evYVNFKT for ; Thu, 02 Dec 2010 21:24:48 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 48410981-1927428 for multiple; Fri, 03 Dec 2010 15:54:47 +1030 (CDT) Received: from dave by dastard with local (Exim 4.71) (envelope-from ) id 1POO8T-0008Ab-Dr; Fri, 03 Dec 2010 16:24:45 +1100 Date: Fri, 3 Dec 2010 16:24:45 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/8] xfs: Pull EFI/EFD handling out from under the AIL lock Subject: Re: [PATCH 1/8] xfs: Pull EFI/EFD handling out from under the AIL lock Message-ID: <20101203052445.GC23339@dastard> References: <1290993152-20999-1-git-send-email-david@fromorbit.com> <1290993152-20999-2-git-send-email-david@fromorbit.com> <20101130201734.GA16079@infradead.org> <20101202012841.GL16922@dastard> <20101202113849.GA21365@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101202113849.GA21365@infradead.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: bld-mail17.adl2.internode.on.net[150.101.137.102] X-Barracuda-Start-Time: 1291353890 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48328 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Dec 02, 2010 at 06:38:49AM -0500, Christoph Hellwig wrote: > On Thu, Dec 02, 2010 at 12:28:41PM +1100, Dave Chinner wrote: > > > - there is a behaviour change about the xfs_trans_del_item call > > > in xfs_efi_item_unpin - before it was protected by the > > > XFS_EFI_CANCELED which was never set, and now it's not. > > > > XFS_EFI_CANCELED has not been set in the code base since > > xfs_efi_cancel() was removed back in 2006 by commit > > 065d312e15902976d256ddaf396a7950ec0350a8 ("[XFS] Remove unused > > iop_abort log item operation), and even then xfs_efi_cancel() was > > never called. I haven't tracked it back further than that (beyond > > git history), but handling of efis in cancelled transactions has > > been broken for a long time. > > > > Basically, when we get an IOP_UNPIN(lip, 1); call from > > xfs_trans_uncommit() (i.e. remove == 1), if we don't free the log > > item descriptor we leak it. IOWs, the new behaviour introduced in > > this patch is actually the correct behaviour. > > Maybe fix this issue first in a separate patch, instead of hiding it > in a bigger one. Ok, I'll split it out. Cheers, Dave. -- Dave Chinner david@fromorbit.com From SRS0+EuKW+6+fromorbit.com=david@internode.on.net Fri Dec 3 00:44:08 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB36i8iw068839 for ; Fri, 3 Dec 2010 00:44:08 -0600 X-ASG-Debug-ID: 1291358751-6aa0011c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id EE5041BBBA4 for ; Thu, 2 Dec 2010 22:45:51 -0800 (PST) Received: from mail.internode.on.net (bld-mail19.adl2.internode.on.net [150.101.137.104]) by cuda.sgi.com with ESMTP id R0JAypqSAnXnyy86 for ; Thu, 02 Dec 2010 22:45:51 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 48057601-1927428 for multiple; Fri, 03 Dec 2010 17:15:50 +1030 (CDT) Received: from dave by dastard with local (Exim 4.71) (envelope-from ) id 1POPOu-0008FY-N7; Fri, 03 Dec 2010 17:45:48 +1100 Date: Fri, 3 Dec 2010 17:45:48 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 02/14] xfs: clean up log space grant functions Subject: Re: [PATCH 02/14] xfs: clean up log space grant functions Message-ID: <20101203064548.GD23339@dastard> References: <1290994712-21376-1-git-send-email-david@fromorbit.com> <1290994712-21376-3-git-send-email-david@fromorbit.com> <20101201123032.GA20378@infradead.org> <20101202014833.GN16922@dastard> <20101202114049.GB21365@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101202114049.GB21365@infradead.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: bld-mail19.adl2.internode.on.net[150.101.137.104] X-Barracuda-Start-Time: 1291358752 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0003 1.0000 -2.0194 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48332 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Dec 02, 2010 at 06:40:50AM -0500, Christoph Hellwig wrote: > On Thu, Dec 02, 2010 at 12:48:33PM +1100, Dave Chinner wrote: > > Ok, so your main objection is the needless addition to the queue? > > That can be avoided easily enough via a local variable. Would that > > be sufficient to alleviate your concerns? > > The main objection is that the new code might be a bit shorted, > but is a lot less readable. If you really want it go with it and > an updated changelog mentioning the behaviour change, but I don't > really feel too good about it. OK, I'll drop it. Cheers, Dave. -- Dave Chinner david@fromorbit.com From SRS0+QyiU+6+fromorbit.com=david@internode.on.net Fri Dec 3 02:35:20 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_63 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB38ZJOl073215 for ; Fri, 3 Dec 2010 02:35:20 -0600 X-ASG-Debug-ID: 1291365421-03da01220000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7A74C1E90C16 for ; Fri, 3 Dec 2010 00:37:01 -0800 (PST) Received: from mail.internode.on.net (bld-mail12.adl6.internode.on.net [150.101.137.97]) by cuda.sgi.com with ESMTP id Ullid87kvhgdvJIZ for ; Fri, 03 Dec 2010 00:37:01 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 48679845-1927428 for multiple; Fri, 03 Dec 2010 19:07:00 +1030 (CDT) Received: from dave by dastard with local (Exim 4.71) (envelope-from ) id 1POR8V-0008Lx-4j; Fri, 03 Dec 2010 19:36:59 +1100 Date: Fri, 3 Dec 2010 19:36:59 +1100 From: Dave Chinner To: Lachlan McIlroy Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] xfs: prevent NMI timeouts in cmn_err Subject: Re: [PATCH] xfs: prevent NMI timeouts in cmn_err Message-ID: <20101203083659.GE23339@dastard> References: <121488966.359171291347997519.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> <275948151.359301291348292101.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <275948151.359301291348292101.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: bld-mail12.adl6.internode.on.net[150.101.137.97] X-Barracuda-Start-Time: 1291365423 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48340 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Dec 02, 2010 at 10:51:32PM -0500, Lachlan McIlroy wrote: > Dave, overall it looks good - just a few minor points below. > Thanks for doing this. > > ----- "Dave Chinner" wrote: [snip] > > -void > > -cmn_err(register int level, char *fmt, ...) > > -{ > > - char *fp = fmt; > > - int len; > > - ulong flags; > > - va_list ap; > > - > > - level &= XFS_ERR_MASK; > > - if (level > XFS_MAX_ERR_LEVEL) > > - level = XFS_MAX_ERR_LEVEL; > > - spin_lock_irqsave(&xfs_err_lock,flags); > > - va_start(ap, fmt); > > - if (*fmt == '!') fp++; > > - len = vsnprintf(message, sizeof(message), fp, ap); > > - if (len >= sizeof(message)) > > - len = sizeof(message) - 1; > > - if (message[len-1] == '\n') > > - message[len-1] = 0; ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > - printk("%s%s\n", err_level[level], message); > > - va_end(ap); > > - spin_unlock_irqrestore(&xfs_err_lock,flags); > > - BUG_ON(level == CE_PANIC); > > -} [snip] > > +#define CE_DEBUG KERN_DEBUG > > +#define CE_CONT KERN_INFO > > +#define CE_NOTE KERN_NOTICE > > +#define CE_WARN KERN_WARNING > > +#define CE_ALERT KERN_ALERT > > +#define CE_PANIC KERN_EMERG > > + > > +#define cmn_err(lvl, fmt, args...) \ > > + do { \ > > + printk(lvl fmt, ## args); \ > > The old cmn_err() routine would append a newline if one was not supplied. > As far as I know printk() will not do the same so either we need to fix > all calls to cmn_err() to supply a '\n' or add it here (at the risk of > having two newlines) - maybe: See above - I think you have it the wrong way around - it looks to me like the old cmn_err() stripped the newline character if it existed, then added one itself. > printk(lvl fmt "\n", ## args); printk() is actually pretty tolerant of missing newlines - if it detects the previous printk() was not newline terminated and the next one starts with a log level that is not KERN_CONT, it will print the new message on a new line automatically. This is the code in vprintk() that handles it: /* Do we have a loglevel in the string? */ if (p[0] == '<') { unsigned char c = p[1]; if (c && p[2] == '>') { switch (c) { case '0' ... '7': /* loglevel */ current_log_level = c - '0'; /* Fallthrough - make sure we're on a new line */ case 'd': /* KERN_DEFAULT */ if (!new_text_line) { emit_log_char('\n'); new_text_line = 1; } /* Fallthrough - skip the loglevel */ case 'c': /* KERN_CONT */ p += 3; break; } } } So we are probably OK not to need additional newlines. Indeed, I didn't notice the output being screwed up without them. ;) I can add them if you want, though. > > > + BUG_ON(strncmp(lvl, KERN_EMERG, strlen(KERN_EMERG)) == 0); \ > > + } while (0) > > + > > +#define xfs_fs_cmn_err(lvl, mp, fmt, args...) \ > > + do { \ > > + printk(lvl "Filesystem %s: " fmt, (mp)->m_fsname, ## args); \ > > printk(lvl "Filesystem %s: " fmt "\n", (mp)->m_fsname, ## args); > > > + BUG_ON(strncmp(lvl, KERN_EMERG, strlen(KERN_EMERG)) == 0); \ > > + } while (0) > > + > > +/* All callers to xfs_cmn_err use CE_ALERT, so don't bother testing > > lvl */ > > +#define xfs_cmn_err(panic_tag, lvl, mp, fmt, args...) \ > > + do { \ > > + int panic = 0; \ > > + if (xfs_panic_mask && (xfs_panic_mask & panic_tag)) { \ > > + printk(KERN_ALERT "XFS: Transforming an alert into a BUG."); \ > > + panic = 1; \ > > + } \ > > + printk(KERN_ALERT "Filesystem %s: " fmt, (mp)->m_fsname, ## args); > > \ > > + BUG_ON(panic); \ > > + } while (0) > > I think we can simplify this case a bit and remove the panic variable, > like this: > > do { \ > printk(KERN_ALERT "Filesystem %s: " fmt "\n", (mp)->m_fsname, ## args); > if (xfs_panic_mask && (xfs_panic_mask & panic_tag)) { \ > printk(KERN_ALERT "XFS: Transforming an alert into a BUG.\n"); \ > BUG_ON(1); \ > } \ > } while (0) > > This also reorders the messages which I think makes more sense. Definitely. That's a vast improvement. ;) Cheers, Dave. -- Dave Chinner david@fromorbit.com From spelic@shiftmail.org Fri Dec 3 08:06:46 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB3E6kdo090363 for ; Fri, 3 Dec 2010 08:06:46 -0600 X-ASG-Debug-ID: 1291385309-312b012f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from BLADE3.ISTI.CNR.IT (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4A59B1C90452 for ; Fri, 3 Dec 2010 06:08:29 -0800 (PST) Received: from BLADE3.ISTI.CNR.IT (blade3.isti.cnr.it [194.119.192.19]) by cuda.sgi.com with ESMTP id emKIeuHBESkn19E5 for ; Fri, 03 Dec 2010 06:08:29 -0800 (PST) Received: from SCRIPT-SPFWL-DAEMON.mx.isti.cnr.it by mx.isti.cnr.it (PMDF V6.5 #31825) id <01NUZL2FI08GLS7MS1@mx.isti.cnr.it> for xfs@oss.sgi.com; Fri, 03 Dec 2010 15:07:57 +0100 (MET) Received: from conversionlocal.isti.cnr.it by mx.isti.cnr.it (PMDF V6.5 #31825) id <01NUZL2E915SLS7X2C@mx.isti.cnr.it> for xfs@oss.sgi.com; Fri, 03 Dec 2010 15:07:54 +0100 (MET) Received: from [192.168.7.52] (firewall.itb.cnr.it [155.253.6.254]) by mx.isti.cnr.it (PMDF V6.5 #31826) with ESMTPSA id <01NUZL2CKKJ8LX5R9L@mx.isti.cnr.it>; Fri, 03 Dec 2010 15:07:52 +0100 (MET) Date: Fri, 03 Dec 2010 15:07:58 +0100 From: Spelic X-ASG-Orig-Subj: Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram Subject: Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram In-reply-to: <20101202230743.GZ16922@dastard> To: Dave Chinner Cc: "linux-kernel@vger.kernel.org" , xfs@oss.sgi.com, linux-lvm@redhat.com Message-id: <4CF8F9BE.6000604@shiftmail.org> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 X-INSM-ip-source: 155.253.6.254 Auth Done References: <4CF7A539.1050206@shiftmail.org> <4CF7A9CF.2020904@shiftmail.org> <20101202230743.GZ16922@dastard> X-Barracuda-Connect: blade3.isti.cnr.it[194.119.192.19] X-Barracuda-Start-Time: 1291385310 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48361 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 12/03/2010 12:07 AM, Dave Chinner wrote: > This is a classic ENOSPC vs NFS client writeback overcommit caching > issue. Have a look at the block map output - I bet theres holes in > the file and it's only consuming 1.5GB of disk space. use xfs_bmap > to check this. du should tell you the same thing. > > Yes you are right! root@server:/mnt/ram# ll -h total 1.5G drwxr-xr-x 2 root root 21 2010-12-02 12:54 ./ drwxr-xr-x 3 root root 4.0K 2010-11-29 23:51 ../ -rw-r--r-- 1 root root 1.9G 2010-12-02 15:04 zerofile root@server:/mnt/ram# ls -lsh total 1.5G 1.5G -rw-r--r-- 1 root root 1.9G 2010-12-02 15:04 zerofile (it's a sparse file) root@server:/mnt/ram# xfs_bmap zerofile zerofile: 0: [0..786367]: 786496..1572863 1: [786368..1572735]: 2359360..3145727 2: [1572736..2232319]: 1593408..2252991 3: [2232320..2529279]: 285184..582143 4: [2529280..2531327]: hole 5: [2531328..2816407]: 96..285175 6: [2816408..2971511]: 582144..737247 7: [2971512..2971647]: hole 8: [2971648..2975183]: 761904..765439 9: [2975184..2975743]: hole 10: [2975744..2975751]: 765440..765447 11: [2975752..2977791]: hole 12: [2977792..2977799]: 765480..765487 13: [2977800..2979839]: hole 14: [2979840..2979847]: 765448..765455 15: [2979848..2981887]: hole 16: [2981888..2981895]: 765472..765479 17: [2981896..2983935]: hole 18: [2983936..2983943]: 765456..765463 19: [2983944..2985983]: hole 20: [2985984..2985991]: 765464..765471 21: [2985992..3202903]: hole 22: [3202904..3215231]: 737248..749575 23: [3215232..3239767]: hole 24: [3239768..3252095]: 774104..786431 25: [3252096..3293015]: hole 26: [3293016..3305343]: 749576..761903 27: [3305344..3370839]: hole 28: [3370840..3383167]: 2252992..2265319 29: [3383168..3473239]: hole 30: [3473240..3485567]: 2265328..2277655 31: [3485568..3632983]: hole 32: [3632984..3645311]: 2277656..2289983 33: [3645312..3866455]: hole 34: [3866456..3878783]: 2289984..2302311 (many delayed allocation extents cannot be filled because space on device is finished) However ... > Basically, the NFS client overcommits the server filesystem space by > doing local writeback caching. Hence it caches 1.9GB of data before > it gets the first ENOSPC error back from the server at around 1.5GB > of written data. At that point, the data that gets ENOSPC errors is > tossed by the NFS client, and a ENOSPC error is placed on the > address space to be reported to the next write/sync call. That gets > to the dd process when it's 1.9GB into the write. > I'm no great expert but isn't this a design flaw in NFS? Ok in this case we were lucky it was all zeroes so XFS made a sparse file and could fit a 1.9GB into 1.5GB device size. In general with nonzero data it seems to me you will get data corruption because the NFS client thinks it has written the data while the NFS server really can't write more data than the device size. It's nice that the NFS server does local writeback caching but it should also cache the filesystem's free space (and check it periodically, since nfs-server is presumably not the only process writing in that filesystem) so that it doesn't accept more data than it can really write. Alternatively, when free space drops below 1GB (or a reasonable size based on network speed), nfs-server should turn off filesystem writeback caching. I can't repeat the test with urandom because it's too slow (8MB/sec !?). How come Linux hasn't got an "uurandom" device capable of e.g. 400MB/sec with only very weak randomness? But I have repeated the test over ethernet with a bunch of symlinks to a 100MB file created from urandom: At client side: # time cat randfile{001..020} | pv -b > /mnt/nfsram/randfile 1.95GB real 0m22.978s user 0m0.310s sys 0m5.360s At server side: # ls -lsh ram total 1.5G 1.5G -rw-r--r-- 1 root root 1.7G 2010-12-03 14:43 randfile # xfs_bmap ram/randfile ram/randfile: 0: [0..786367]: 786496..1572863 1: [786368..790527]: 96..4255 2: [790528..1130495]: hole 3: [1130496..1916863]: 2359360..3145727 4: [1916864..2682751]: 1593408..2359295 5: [2682752..3183999]: 285184..786431 6: [3184000..3387207]: 4256..207463 7: [3387208..3387391]: hole 8: [3387392..3391567]: 207648..211823 9: [3391568..3393535]: hole 10: [3393536..3393543]: 211824..211831 11: [3393544..3395583]: hole 12: [3395584..3395591]: 211832..211839 13: [3395592..3397631]: hole 14: [3397632..3397639]: 211856..211863 15: [3397640..3399679]: hole 16: [3399680..3399687]: 211848..211855 17: [3399688..3401727]: hole 18: [3401728..3409623]: 221984..229879 # dd if=/mnt/ram/randfile | wc -c 3409624+0 records in 3409624+0 records out 1745727488 1745727488 bytes (1.7 GB) copied, 5.72443 s, 305 MB/s The file is still sparse, and this time it certainly has data corruption (holes will be read as zeroes). I understand that the client receives Input/output error when this condition is hit, but the file written at server side has apparent size 1.8GB but the valid data in it is not 1.8GB. Is it good semantics? Wouldn't it be better for nfs-server to turn off writeback caching when it approaches a disk-full situation? And then I see another problem: As you see, xfs_fsr shows lots of holes, even with randomfile (this is taken from urandom so you can be sure it hasn't got many zeroes) already from offset 790528 sectors which is far from the disk full situation... First I checked that this does not happen by pushing less than 1.5GB of data. Ok it does not. Then I tried with exactly 15*100MB (files are 100MB, are symliks to a file which was created with dd if=/dev/urandom of=randfile.rnd bs=1M count=100) and this happened: client side: # time cat randfile{001..015} | pv -b > /mnt/nfsram/randfile 1.46GB real 0m18.265s user 0m0.260s sys 0m4.460s (please note: no I/O error at client side! blockdev --getsize64 /dev/ram0 == 1610612736) server side: # ls -ls ram total 1529676 1529676 -rw-r--r-- 1 root root 1571819520 2010-12-03 14:51 randfile # dd if=/mnt/ram/randfile | wc -c 3069960+0 records in 3069960+0 records out 1571819520 1571819520 bytes (1.6 GB) copied, 5.30442 s, 296 MB/s # xfs_bmap ram/randfile ram/randfile: 0: [0..112639]: 96..112735 1: [112640..208895]: 114784..211039 2: [208896..399359]: 285184..475647 3: [399360..401407]: 112736..114783 4: [401408..573439]: 475648..647679 5: [573440..937983]: 786496..1151039 6: [937984..1724351]: 2359360..3145727 7: [1724352..2383871]: 1593408..2252927 8: [2383872..2805695]: 1151040..1572863 9: [2805696..2944447]: 647680..786431 10: [2944448..2949119]: 211040..215711 11: [2949120..3055487]: 2252928..2359295 12: [3055488..3058871]: 215712..219095 13: [3058872..3059711]: hole 14: [3059712..3060143]: 219936..220367 15: [3060144..3061759]: hole 16: [3061760..3061767]: 220368..220375 17: [3061768..3063807]: hole 18: [3063808..3063815]: 220376..220383 19: [3063816..3065855]: hole 20: [3065856..3065863]: 220384..220391 21: [3065864..3067903]: hole 22: [3067904..3067911]: 220392..220399 23: [3067912..3069951]: hole 24: [3069952..3069959]: 220400..220407 Holes in a random file! This is data corruption, and nobody is notified of this data corruption: no error at client side or server side! Is it good semantics? How could client get notified of this? Some kind of fsync maybe? Thank you From npiggin@kernel.dk Fri Dec 3 11:10:01 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB3HA1aU097359 for ; Fri, 3 Dec 2010 11:10:01 -0600 X-ASG-Debug-ID: 1291396304-53c503dc0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail06.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B86801C90E6A for ; Fri, 3 Dec 2010 09:11:44 -0800 (PST) Received: from ipmail06.adl6.internode.on.net (ipmail06.adl6.internode.on.net [150.101.137.145]) by cuda.sgi.com with ESMTP id 8UMxFbXCxpE4bMxN for ; Fri, 03 Dec 2010 09:11:44 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPuy+Ex5LdV4/2dsb2JhbACjNXLDJ4VIBA Received: from ppp121-45-213-120.lns20.cbr1.internode.on.net (HELO laptop.local0.net) ([121.45.213.120]) by ipmail06.adl6.internode.on.net with ESMTP; 04 Dec 2010 03:41:42 +1030 Received: by laptop.local0.net (Postfix, from userid 1000) id B58542981A; Sat, 4 Dec 2010 04:11:40 +1100 (EST) Date: Sat, 4 Dec 2010 04:11:40 +1100 From: Nick Piggin To: Mike Snitzer Cc: LVM general discussion and development , Spelic , Christoph Hellwig , "linux-kernel@vger.kernel.org" , xfs@oss.sgi.com, npiggin@kernel.dk, dm-devel@redhat.com X-ASG-Orig-Subj: Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram Subject: Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram Message-ID: <20101203171140.GA11889@amd> References: <4CF7A539.1050206@shiftmail.org> <20101202141134.GA22012@infradead.org> <4CF7A9C4.2040607@shiftmail.org> <20101202141737.GA29799@infradead.org> <20101202212227.GA22703@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101202212227.GA22703@redhat.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: ipmail06.adl6.internode.on.net[150.101.137.145] X-Barracuda-Start-Time: 1291396305 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48373 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Dec 02, 2010 at 04:22:27PM -0500, Mike Snitzer wrote: > On Thu, Dec 02 2010 at 9:17am -0500, > Christoph Hellwig wrote: > > > On Thu, Dec 02, 2010 at 03:14:28PM +0100, Spelic wrote: > > > On 12/02/2010 03:11 PM, Christoph Hellwig wrote: > > > >I'm pretty sure you have CONFIG_DEBUG_BLOCK_EXT_DEVT enabled. This > > > >option must never be enabled, as it causes block devices to be > > > >randomly renumered. Together with the ramdisk driver overloading > > > >the BLKFLSBUF ioctl to discard all data it guarantees you to get > > > >data loss like yours. > > > > > > Nope... > > > > > > # CONFIG_DEBUG_BLOCK_EXT_DEVT is not set > > > > Hmm, I suspect dm-linear's dumb forwarding of ioctls has the same > > effect. > > For the benefit of others: > - mkfs.xfs will avoid sending BLKFLSBUF to any device whose major is > ramdisk's major, this dates back to 2004: > http://oss.sgi.com/archives/xfs/2004-08/msg00463.html > - but because a kpartx partition overlay (linear DM mapping) is used for > the /dev/ram0p1 device, mkfs.xfs only sees a device with DM's major > - so mkfs.xfs sends BLKFLSBUF to the DM device blissfully unaware that > the backing device (behind the DM linear target) is a brd device > - DM will forward the BLKFLSBUF ioctl to brd, which triggers > drivers/block/brd.c:brd_ioctl (nuking the entire ramdisk in the > process) > > So coming full circle this is what hch was referring to when he > mentioned: > 1) "ramdisk driver overloading the BLKFLSBUF ioctl ..." > 2) "dm-linear's dumb forwarding of ioctls ..." > > I really can't see DM adding a specific check for ramdisk's major when > forwarding the BLKFLSBUF ioctl. > > brd has direct partition support (see commit d7853d1f8932c) so maybe > kpartx should just blacklist /dev/ram devices? > > Alternatively, what about switching brd away from overloading BLKFLSBUF > to a real implementation of (overloaded) BLKDISCARD support in brd.c? > One that doesn't blindly nuke the entire device but that properly > processes the discard request. Yeah the situation really sucks (mkfs.jfs doesn't work on ramdisk for the same reason). I want to unfortunately keep ioctl for compatibility, but adding new saner ones would be welcome. Also, having a non-default config or load time parameter for brd, to skip the special case, if that would help testing on older userspace. DISCARD is actually a problem for rd. To actually get proper correctness, you need to preload brd with pages, otherwise when doing stress tests, IO can require memory allocations and deadlock. If we add a discard that frees pages, that introduces the same problem. If you find any option useful for testing, however, patches are fine -- brd pretty much is only useful for testing nowadays. From tytso@thunk.org Fri Dec 3 12:13:45 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB3IDi4H099887 for ; Fri, 3 Dec 2010 12:13:45 -0600 X-ASG-Debug-ID: 1291400128-03b802b50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from thunker.thunk.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1A6261C91433 for ; Fri, 3 Dec 2010 10:15:28 -0800 (PST) Received: from thunker.thunk.org (thunk.org [69.25.196.29]) by cuda.sgi.com with ESMTP id lrOSMBAjqamrdbsI for ; Fri, 03 Dec 2010 10:15:28 -0800 (PST) Received: from root (helo=tytso-glaptop) by thunker.thunk.org with local-esmtp (Exim 4.50 #1 (Debian)) id 1POaAD-0001bK-S2; Fri, 03 Dec 2010 13:15:21 -0500 Received: from tytso by tytso-glaptop with local (Exim 4.71) (envelope-from ) id 1POaAC-00072v-GP; Fri, 03 Dec 2010 13:15:20 -0500 Date: Fri, 3 Dec 2010 13:15:20 -0500 From: "Ted Ts'o" To: Nick Piggin Cc: Mike Snitzer , LVM general discussion and development , Spelic , Christoph Hellwig , "linux-kernel@vger.kernel.org" , xfs@oss.sgi.com, dm-devel@redhat.com X-ASG-Orig-Subj: Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram Subject: Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram Message-ID: <20101203181520.GA26906@thunk.org> Mail-Followup-To: Ted Ts'o , Nick Piggin , Mike Snitzer , LVM general discussion and development , Spelic , Christoph Hellwig , "linux-kernel@vger.kernel.org" , xfs@oss.sgi.com, dm-devel@redhat.com References: <4CF7A539.1050206@shiftmail.org> <20101202141134.GA22012@infradead.org> <4CF7A9C4.2040607@shiftmail.org> <20101202141737.GA29799@infradead.org> <20101202212227.GA22703@redhat.com> <20101203171140.GA11889@amd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101203171140.GA11889@amd> User-Agent: Mutt/1.5.20 (2009-06-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false X-Barracuda-Connect: thunk.org[69.25.196.29] X-Barracuda-Start-Time: 1291400129 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48377 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Sat, Dec 04, 2010 at 04:11:40AM +1100, Nick Piggin wrote: > > Alternatively, what about switching brd away from overloading BLKFLSBUF > > to a real implementation of (overloaded) BLKDISCARD support in brd.c? > > One that doesn't blindly nuke the entire device but that properly > > processes the discard request. > > Yeah the situation really sucks (mkfs.jfs doesn't work on ramdisk > for the same reason). > > I want to unfortunately keep ioctl for compatibility, but adding new > saner ones would be welcome. Also, having a non-default config or > load time parameter for brd, to skip the special case, if that would > help testing on older userspace. How many programs actually depend on BLKFLSBUF dropping the pages used in /dev/ram? The fact that it did this at all was a historical accident of how the original /dev/ram was implemented (in the buffer cache directly), and not anything that was intended. I think that's something that we should be able to fix, since the number of programs that knowly operate on the ramdisk is quite small. Just a few system programs used by distributions in their early boot scripts.... So I would argue for dropping the "special" behavior of BLKFLSBUF for /dev/ram. - Ted From ermorris@ucsc.edu Fri Dec 3 18:41:43 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB40fgiI114194 for ; Fri, 3 Dec 2010 18:41:42 -0600 X-ASG-Debug-ID: 1291423404-085803700000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ucsc.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 32E021410F8D for ; Fri, 3 Dec 2010 16:43:24 -0800 (PST) Received: from ucsc.edu (email-prod-out-1.ucsc.edu [128.114.129.85]) by cuda.sgi.com with ESMTP id ZSEDVQmgV7tOxMTi for ; Fri, 03 Dec 2010 16:43:24 -0800 (PST) X-UCSC-EDU-Sender: X-UCSC-EDU-Scanned-By: email-prod-out-1 X-UCSC-EDU-Submitted-Via: SMTP [128.114.125.121] X-UCSC-EDU-ClamAVCheck: not spam, ClamAV(signaure=none) X-UCSC-EDU-SpamCheck: No, score=-1.439 required=5 tests=ALL_TRUSTED, HTML_MESSAGE X-UCSC-EDU-SpamScore: X-UCSC-EDU-SpamFlag: NO X-UCSC-EDU-SpamReport: -1.4 ALL_TRUSTED Passed through trusted hosts only via SMTP X-UCSC-EDU-SpamReport: 0.0 HTML_MESSAGE BODY: HTML included in message Received: from [128.114.125.121] (HELO ucsc.edu) by email-prod-out-1.ucsc.edu (CommuniGate Pro SMTP 5.2.13) with ESMTPS id 28624895; Fri, 03 Dec 2010 16:43:25 -0800 Received: by email-prod-fe-2.ucsc.edu (CommuniGate Pro PIPE 5.2.13) with PIPE id 405752112; Fri, 03 Dec 2010 16:43:22 -0800 X-UCSC-EDU-ClamAVCheck: not spam, ClamAV(signaure=none) Received: from [128.114.25.84] (account ermorris@ucsc.edu HELO dhcp-25-84.ucsc.edu) by email-prod-fe-2.ucsc.edu (CommuniGate Pro SMTP 5.2.13) with ESMTPSA id 405752076; Fri, 03 Dec 2010 16:43:08 -0800 X-ASG-Orig-Subj: Re: xfs_repair of critical volume Subject: Re: xfs_repair of critical volume Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-2--416424039 From: Eli Morris In-Reply-To: <201012021233.07213@zmi.at> Date: Fri, 3 Dec 2010 16:43:08 -0800 Cc: xfs@oss.sgi.com, Dave Chinner Message-Id: <86C6F4CD-B39B-4702-80E7-350A363D5F55@ucsc.edu> References: <75C248E3-2C99-426E-AE7D-9EC543726796@ucsc.edu> <20101117074708.GP22876@dastard> <201012021233.07213@zmi.at> To: Michael Monnerie X-Mailer: Apple Mail (2.1082) X-Barracuda-Connect: email-prod-out-1.ucsc.edu[128.114.129.85] X-Barracuda-Start-Time: 1291423405 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0003 1.0000 -2.0192 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48404 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --Apple-Mail-2--416424039 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Dec 2, 2010, at 3:33 AM, Michael Monnerie wrote: > On Dienstag, 30. November 2010 Eli Morris wrote: >> Thanks for your help with this. I wrote the program and ran it >> through and it looks like we have we able to preserve 44 TB of valid >> data, while removing the corrupted files, which is a great result, >> considering the circumstances.=20 >=20 > Eli, could you post the relevant program here so others can use it if=20= > needed? There are requests from time to time, and it would be good if=20= > such a program were available (like I'm sure you'd been happy if it=20 > already existed the time you needed it). >=20 > Thanks, and wow: what an amazing filesystem can recover such an event! >=20 > --=20 > mit freundlichen Gr=FCssen, > Michael Monnerie, Ing. BSc >=20 > it-management Internet Services: Prot=E9ger > http://proteger.at [gesprochen: Prot-e-schee] > Tel: +43 660 / 415 6531 >=20 > // ****** Radiointerview zum Thema Spam ****** > // http://www.it-podcast.at/archiv.html#podcast-100716 > //=20 > // Haus zu verkaufen: http://zmi.at/langegg/ Good idea, here is the program: Eli #!/bin/bash #=20 # Copyright 2010 Eli Morris, Travis O'Brien, University of California=20= #=20 # remove_bad.sh is free software: you can redistribute it under the = terms # of the GNU General Public License as published by the Free Software # Foundation, either version 3 of the License, or (at your option) = any later # version.=20 #=20 # This program is distributed in the hope that it will be useful, but # WITHOUT ANY WARRANTY; without even the implied warranty of = MERCHANTABILITY # or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public = License # for more details.=20 #=20 # You should have received a copy of the GNU General Public License = along # with this program. If not, see .=20 # # #remove_bad.sh: A script to determine whether any part of a file falls = within a #set of blocks (indicated by arguments 1 and 2). This script is #originally written with the intent to find files on a file system that #exist(ed) on a corrupt section of the file system. It generates a list = of files #that are potentially bad, so that they can be removed by another = script. # #Check command line arguments; grab arguments 1 and 2 if [ $# -eq 2 ]; then BAD_BLOCK_BEGINNING=3D$1 BAD_BLOCK_END=3D$2 echo "bad block beginning $BAD_BLOCK_BEGINNING" echo "bad block ending $BAD_BLOCK_END" #if there aren't exactly 2 arguments then print the usage to the user else echo "usage: remove_bad.sh beginning_block ending_block" exit fi remove file from last run if ( test -e "./naughty_list.txt")=20 then echo "removing the previous naughty list" rm "./naughty_list.txt" fi IFS=3D$'\n' #set the field separator to the carriage return character ALL_FILES=3D(`find /export/vol5 -type f`) #A list of all files on the = volume, SUBSTITUTE NAME OF YOUR VOLUME NUM_FILES=3D${#ALL_FILES[@]} #The number of files on the volume echo "number of files is $NUM_FILES" #Report the number of files to the = user # for each of the file in vol5 for (( COUNT=3D0; COUNT<$NUM_FILES; COUNT++)) do #Report which file is being worked on echo "file number: $COUNT is ${ALL_FILES[$COUNT]}" # report number of files to go FILES_TO_GO=3D$((NUM_FILES-COUNT)) echo "files left: $FILES_TO_GO"=20 #Run xfs_bmap to get the blocks that the file lives within OUTPUT=3D(`xfs_bmap ${ALL_FILES[$COUNT]}`) # output looks like this # vol5dump: # 0: [0..1053271]: 5200578944..5201632215 BAD_FILE=3D0 #Initialize the bad file flag NUM_LINES=3D${#OUTPUT[@]} #The number of lines from xfs_bmap # echo "number of lines for file: $NUM_LINES" #Report the number = of lines to the user #Loop through each line for (( LINE=3D1; LINE < $NUM_LINES; LINE++)) do # echo "line number $LINE: output: ${OUTPUT[$LINE]}" = #Report the current working line # get the block range from the line BLOCKS=3D`echo ${OUTPUT[$LINE]} | cut -d':' -f3` #Report the number of blocks occupied # echo "blocks after cut: '$BLOCKS'"=20 #Use cut to get the first and last block for the file FIRST_BLOCK=3D`echo $BLOCKS | cut -d'.' -f1`=20 LAST_BLOCK=3D`echo $BLOCKS | cut -d'.' -f3` =09 #Report these to the user # echo "beginning block: $FIRST_BLOCK" # echo "ending block: $LAST_BLOCK" #TODO: I'm not sure what exactly 'hole' means, but I get = the impression that it has something #to do with XFS's way of avoiding file fragmentation. = TAO if [ "$BLOCKS" !=3D " hole" ]; then #Don't deal with = lines that report 'hole' # compare to bad block region #For now, check whether the blocks for the file = fall within the user-given block range #if any of the blocks do, then mark this file as = bad. if ( (( "$BAD_BLOCK_BEGINNING" <=3D = "$FIRST_BLOCK")) && (( "$FIRST_BLOCK" <=3D "$BAD_BLOCK_END")) ); then # echo "hit first criterium" BAD_FILE=3D1 break elif ( (( "$BAD_BLOCK_BEGINNING" <=3D = "$LAST_BLOCK")) && (( "$LAST_BLOCK" <=3D "$BAD_BLOCK_END")) ); then # echo "hit second criterium" BAD_FILE=3D1 break fi fi done # add the file to the list of bad files if (($BAD_FILE =3D=3D 1)); then #Report to the user that the current file is bad echo "putting file: ${ALL_FILES[$COUNT]} on the naughty = list" #Write the file's name to the list echo "${ALL_FILES[$COUNT]}" >> naughty_list.txt fi done echo "program_ended_succesfully" >> naughty_list.txt --Apple-Mail-2--416424039 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Dienstag, 30. November 2010 Eli Morris = wrote:
Thanks for your help with this. I = wrote the program and ran it
through and it looks like we have we able to preserve 44 = TB of valid
data, while = removing the corrupted files, which is a great = result,
considering the = circumstances.

Eli, could you post the relevant = program here so others can use it if
needed? There are requests from = time to time, and it would be good if
such a program were available = (like I'm sure you'd been happy if it
already existed the time you = needed it).

Thanks, and wow: what an amazing filesystem can = recover such an event!

--
mit freundlichen = Gr=FCssen,
Michael Monnerie, Ing. BSc

it-management Internet = Services: Prot=E9ger
http://proteger.at [gesprochen: = Prot-e-schee]
Tel: +43 660 / 415 6531

// ****** Radiointerview = zum Thema Spam ******
// http://www.it= -podcast.at/archiv.html#podcast-100716
//
// Haus zu = verkaufen: http://zmi.at/langegg/


Good idea, here is the = program:

Eli

#!/bin/bash
#    Copyright = 2010 Eli Morris, Travis O'Brien, University of = California 
# 
#    remove_bad.sh is free software: you can = redistribute it under the  terms
#  =   of the GNU General Public License as published by the Free = Software
#    Foundation, = either version 3 of the License, or (at your option) any later
#    version. 
# 
#    = This program is distributed in the hope that it will be useful, = but
#    WITHOUT ANY = WARRANTY; without even the implied warranty of MERCHANTABILITY
#    or FITNESS FOR A PARTICULAR = PURPOSE.  See the GNU General Public License
#    for more details. 
# 
#    = You should have received a copy of the GNU General Public License = along
#    with this = program.  If not, see <http://www.gnu.org/licenses/>. 
#
#
#remove_bad.sh: A script to determine whether any part = of a file falls within a
#set of blocks = (indicated by arguments 1 and 2).  This script is
#originally written with the intent to find files on a = file system that
#exist(ed) on a corrupt = section of the file system.  It generates a list of files
#that are potentially bad, so that they can be removed = by another script.
#

#Check command = line arguments; grab arguments 1 and 2
if [ $# -eq 2 ]; = then
BAD_BLOCK_BEGINNING=3D$1
BAD_BLOCK_END=3D$2
echo "bad block beginning = $BAD_BLOCK_BEGINNING"
= echo "bad block ending $BAD_BLOCK_END"
#if there aren't exactly 2 arguments then print the = usage to the user
else
echo = "usage: remove_bad.sh beginning_block ending_block"
= exit
fi

remove file from last run
if ( test -e "./naughty_list.txt") 
= echo "removing the previous naughty list"
rm = "./naughty_list.txt"
fi

IFS=3D$'\n' #set the = field separator to the carriage return character
ALL_FILES=3D(`find /export/vol5 -type f`) #A list of all files on the volume, = SUBSTITUTE NAME OF YOUR VOLUME
NUM_FILES=3D${#ALL_FILES[@]} #The number = of files on the volume
echo "number of files is = $NUM_FILES" #Report the = number of files to the user

# for each of the file in vol5
for (( COUNT=3D0; COUNT<$NUM_FILES; COUNT++))
do
    #Report which file is = being worked on
= echo "file number: $COUNT is = ${ALL_FILES[$COUNT]}"

# report number of files = to go
= FILES_TO_GO=3D$((NUM_FILES-COUNT))
echo "files left: = $FILES_TO_GO" 

    #Run xfs_bmap to get the = blocks that the file lives within
OUTPUT=3D(`xfs_bmap = ${ALL_FILES[$COUNT]}`)
# = output looks like this
= # vol5dump:
# 0: [0..1053271]: = 5200578944..5201632215

BAD_FILE=3D0 = #Initialize the bad file flag
NUM_LINES=3D${#OUTPUT[@]} = #The number of lines from xfs_bmap

# = echo "number of lines for file: $NUM_LINES" #Report the number of lines = to the user
    #Loop through each = line
for (( LINE=3D1; = LINE < $NUM_LINES; LINE++))
do
= # echo "line number $LINE: output: ${OUTPUT[$LINE]}" = #Report the current working line

= # get the block range from the line
= BLOCKS=3D`echo ${OUTPUT[$LINE]} | cut -d':' -f3`

        = #Report the number of blocks occupied
= # echo "blocks after cut: '$BLOCKS'" 
      =   = #Use cut to get the first and last block for the = file
= FIRST_BLOCK=3D`echo $BLOCKS | cut -d'.' -f1` 
LAST_BLOCK=3D`echo = $BLOCKS | cut -d'.' -f3`

=

      =   = #Report these to the user
# echo "beginning = block: $FIRST_BLOCK"
= # echo "ending block: $LAST_BLOCK"

#TODO: I'm not = sure what exactly 'hole' means, but I get the impression that it has = something
= #to do with XFS's way of avoiding file fragmentation. = TAO
= if [ "$BLOCKS" !=3D = " hole" ]; then  #Don't deal with lines that = report 'hole'
= # compare to bad block region
= #For now, check whether the blocks for the file fall = within the user-given block range
#if any of = the blocks do, then mark this file as bad.
=   = if ( (( "$BAD_BLOCK_BEGINNING" <=3D "$FIRST_BLOCK")) && (( "$FIRST_BLOCK" <=3D "$BAD_BLOCK_END")) ); then
=   # echo "hit first = criterium"
  = BAD_FILE=3D1
=   break
=   = elif ( (( "$BAD_BLOCK_BEGINNING" <=3D "$LAST_BLOCK")) && (( "$LAST_BLOCK" <=3D "$BAD_BLOCK_END")) ); then
=   # echo "hit second = criterium"
  = BAD_FILE=3D1
=   break
=   = fi
= fi
= done
= # add the file to the list of bad files
if (($BAD_FILE =3D=3D 1)); then
                = #Report to the user that the current file is bad
= echo "putting file: ${ALL_FILES[$COUNT]} on the naughty = list"
                = #Write the file's name to the list
echo "${ALL_FILES[$COUNT]}" >> = naughty_list.txt
= fi
done
echo = "program_ended_succesfully" = >> naughty_list.txt
Umount -> run xfs_repair -> mount Mount fails -> try xfs_repair -> xfs_repair fails -> finally xfs_repair -L -> mount Adding above mount + xfs_repair procedure to script makes file system stable. But other member of my team do not agree as it increases mount time. On Fri, Dec 3, 2010 at 4:15 AM, Dave Chinner wrote: > On Thu, Dec 02, 2010 at 12:31:30PM +0530, Ajeet Yadav wrote: > > Dear all, > > This is XFS fail mount log on linux 2.6.30.9 > > > > XFS mounting filesystem sda2 > > Starting XFS recovery on filesystem: sda2 (logdev: internal) > > XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1629 of file > > fs/xfs/xfs_alloc.c. Caller 0x80129658 > > Call Trace: > > [<802dedc8>] dump_stack+0x8/0x34 from[<80127400>] > > xfs_free_ag_extent+0x128/0x7ac > > [<80127400>] xfs_free_ag_extent+0x128/0x7ac from[<80129658>] > > xfs_free_extent+0xb8/0xe8 > > [<80129658>] xfs_free_extent+0xb8/0xe8 from[<80163978>] > > xlog_recover_process_efi+0x160/0x214 > > [<80163978>] xlog_recover_process_efi+0x160/0x214 from[<80163ac4>] > > xlog_recover_process_efis+0x98/0x11c > > [<80163ac4>] xlog_recover_process_efis+0x98/0x11c from[<8016663c>] > > xlog_recover_finish+0x28/0xdc > > [<8016663c>] xlog_recover_finish+0x28/0xdc from[<8016aec0>] > > xfs_mountfs+0x4d0/0x610 > > [<8016aec0>] xfs_mountfs+0x4d0/0x610 from[<80184434>] > > xfs_fs_fill_super+0x1fc/0x418 > > [<80184434>] xfs_fs_fill_super+0x1fc/0x418 from[<800bae48>] > > get_sb_bdev+0x11c/0x1c0 > > [<800bae48>] get_sb_bdev+0x11c/0x1c0 from[<80181f20>] > > xfs_fs_get_sb+0x20/0x2c > > [<80181f20>] xfs_fs_get_sb+0x20/0x2c from[<800b9424>] > > vfs_kern_mount+0x68/0xd0 > > [<800b9424>] vfs_kern_mount+0x68/0xd0 from[<800b94f0>] > > do_kern_mount+0x54/0x118 > > [<800b94f0>] do_kern_mount+0x54/0x118 from[<800d44e8>] > do_mount+0x7b4/0x828 > > [<800d44e8>] do_mount+0x7b4/0x828 from[<800d45f8>] sys_mount+0x9c/0x194 > > [<800d45f8>] sys_mount+0x9c/0x194 from[<800102c4>] stack_done+0x20/0x3c > > > > Failed to recover EFIs on filesystem: sda2 > > XFS: log mount finish failed > > You corrupted a free space btree. Care to tell uswhat test you were > running that caused this? Did you pull the plug on the device > during a copy again? > > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com > --0015175cded4cc681904968df599 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Our test case is automated:
1. Create large number of file of 6KB sizes = ( 6KB is taken, we wanted to increase journal load, and file size not in mu= ltiple of file system block size)
2. Set target to reboot at random sec= onds seconds.
3. Next boot do "ls" of all files in XFS partition.
4. Remove = all files in XFS.
5. Go back to step 1

The purpose of this test i= s to test journal and stability of XFS filestem.

Do you think, we sh= ould consider this test case ?

Other is when we should run xfs_repair ? because if mount fails and jou= rnal contain dirty logs then xfs_repair does not run, we are forced to use = (-L) option but its description say that (-L) can corrupt the file system.<= br>
Other case even if xfs mount successfully, even in that case accessing = some files give IO input/ output error.

1. I recommend the following= usage for xfs_repair so that we do not come accross these problem
=A0 = =A0 Mount Success -> Umount -> run xfs_repair -> mount
=A0 =A0 Mount fails -> try xfs_repair -> xfs_repair fails -> final= ly xfs_repair -L -> mount

Adding above mount + xfs_repair procedu= re to script makes file system stable. But other member of my team do not a= gree as it increases mount time.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0=A0 =A0

On Fri, Dec 3, 2= 010 at 4:15 AM, Dave Chinner <david@fromorbit.com> wrote:
<= div class=3D"h5">On Thu, Dec 02, 2010 at 12:31:30PM +0530, Ajeet Yadav wrot= e:
> Dear all,
> This is XFS fail mount log on linux 2.6.30.9
>
> XFS mounting filesystem sda2
> Starting XFS recovery on filesystem: sda2 (logdev: internal)
> XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1629 of file
> fs/xfs/xfs_alloc.c. =A0Caller 0x80129658
> Call Trace:
> [<802dedc8>] dump_stack+0x8/0x34 from[<80127400>]
> xfs_free_ag_extent+0x128/0x7ac
> [<80127400>] xfs_free_ag_extent+0x128/0x7ac from[<80129658>= ;]
> xfs_free_extent+0xb8/0xe8
> [<80129658>] xfs_free_extent+0xb8/0xe8 from[<80163978>] > xlog_recover_process_efi+0x160/0x214
> [<80163978>] xlog_recover_process_efi+0x160/0x214 from[<80163= ac4>]
> xlog_recover_process_efis+0x98/0x11c
> [<80163ac4>] xlog_recover_process_efis+0x98/0x11c from[<80166= 63c>]
> xlog_recover_finish+0x28/0xdc
> [<8016663c>] xlog_recover_finish+0x28/0xdc from[<8016aec0>= ]
> xfs_mountfs+0x4d0/0x610
> [<8016aec0>] xfs_mountfs+0x4d0/0x610 from[<80184434>]
> xfs_fs_fill_super+0x1fc/0x418
> [<80184434>] xfs_fs_fill_super+0x1fc/0x418 from[<800bae48>= ]
> get_sb_bdev+0x11c/0x1c0
> [<800bae48>] get_sb_bdev+0x11c/0x1c0 from[<80181f20>]
> xfs_fs_get_sb+0x20/0x2c
> [<80181f20>] xfs_fs_get_sb+0x20/0x2c from[<800b9424>]
> vfs_kern_mount+0x68/0xd0
> [<800b9424>] vfs_kern_mount+0x68/0xd0 from[<800b94f0>]
> do_kern_mount+0x54/0x118
> [<800b94f0>] do_kern_mount+0x54/0x118 from[<800d44e8>] do_= mount+0x7b4/0x828
> [<800d44e8>] do_mount+0x7b4/0x828 from[<800d45f8>] sys_mou= nt+0x9c/0x194
> [<800d45f8>] sys_mount+0x9c/0x194 from[<800102c4>] stack_d= one+0x20/0x3c
>
> Failed to recover EFIs on filesystem: sda2
> XFS: log mount finish failed

You corrupted a free space btree. Care to tell uswhat test you = were
running that caused this? =A0Did you pull the plug on the device
during a copy again?

Cheers,

Dave.
--
Dave Chinner
david@fromorbit.com

--0015175cded4cc681904968df599-- From Martin@lichtvoll.de Sat Dec 4 04:28:40 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB4ASeKR146814 for ; Sat, 4 Dec 2010 04:28:40 -0600 X-ASG-Debug-ID: 1291458623-37f903e40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.lichtvoll.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D355C1C95399 for ; Sat, 4 Dec 2010 02:30:23 -0800 (PST) Received: from mail.lichtvoll.de (mondschein.lichtvoll.de [194.150.191.11]) by cuda.sgi.com with ESMTP id LDMgRWJzaTBo1yFs for ; Sat, 04 Dec 2010 02:30:23 -0800 (PST) Received: from shambhala.localnet (ppp-93-104-153-33.dynamic.mnet-online.de [93.104.153.33]) by mail.lichtvoll.de (Postfix) with ESMTPSA id 08D22BA for ; Sat, 4 Dec 2010 11:30:22 +0100 (CET) From: Martin Steigerwald To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs_repair of critical volume Subject: Re: xfs_repair of critical volume Date: Sat, 4 Dec 2010 11:30:19 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.37-rc3-tp42; KDE/4.5.3; i686; ; ) References: <75C248E3-2C99-426E-AE7D-9EC543726796@ucsc.edu> <201011121422.28993@zmi.at> <4CDDBC5C.7020708@hardwarefreak.com> (sfid-20101113_121516_584378_2321CE16) In-Reply-To: <4CDDBC5C.7020708@hardwarefreak.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201012041130.20344.Martin@lichtvoll.de> X-Barracuda-Connect: mondschein.lichtvoll.de[194.150.191.11] X-Barracuda-Start-Time: 1291458624 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48443 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Am Freitag 12 November 2010 schrieb Stan Hoeppner: > Michael Monnerie put forth on 11/12/2010 7:22 AM: > > I find the robustness of XFS amazing: You overwrote 1/5th of the disk > > with zeroes, and it still works :-) > > This isn't "robustness" Michael. If anything it's a serious problem. > XFS is reporting that hundreds or thousands of files that have been > physically removed still exist. Regardless of how he arrived at this > position, how is this "robust"? Most people would consider this > inconsistency of state a "corruption" situation, not "robustness". I think its necessary to differentiate here: 1) It appears to be robustness - or pure luck - regarding metadata consistency of the filesystem. I tend to believe its pure luck and that XFS just stored the metadata on the other RAID arrays. 2) XFS does not seem to have a way to detect whether file contents are still valid and consistent. It shares that with I think every other Linux filesystem instead BTRFS which uses checksumming for files. (Maybe NILFS as well, I don't know, and the FUSE or the other ZFS port). Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From 3h8L6TBcKA5EA3xvDvHzwv6wF7D-89CzA6J19916z.x97I0D9DD.D13.x97@photos-server.bounces.google.com Sat Dec 4 16:35:12 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.3 required=5.0 tests=BAYES_99,MIME_8BIT_HEADER, T_DKIM_INVALID autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB4MZB4K234869 for ; Sat, 4 Dec 2010 16:35:11 -0600 X-ASG-Debug-ID: 1291502215-31b603d40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-gx0-f201.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5098614143CA for ; Sat, 4 Dec 2010 14:36:55 -0800 (PST) Received: from mail-gx0-f201.google.com (mail-gx0-f201.google.com [209.85.161.201]) by cuda.sgi.com with ESMTP id nYXxlxkEr99bHmMz for ; Sat, 04 Dec 2010 14:36:55 -0800 (PST) Received: by gxk23 with SMTP id 23so1670722gxk.2 for ; Sat, 04 Dec 2010 14:36:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:reply-to:message-id:date :subject:from:to:content-type; bh=agowN8JAnRlfFmi9Hdq5PZdZN2CAD1MUCisW4OLeL6k=; b=FZwdFQ0r38iPCJxnBPRZRhhcKIm9n+/h+jkex0CYRSUGSBjA3LDk9lALwHtBFzG3Fc AVaYYoVCDzKR6cdCko9g== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:message-id:date:subject:from:to:content-type; b=SPAIEKISSfNvPoqV6iniEj9bSrN0caYDM18iUVuMcpgM3kyN8WFddAXcVB0MqpdC51 6l0+LUR5dnRYjb0veUmg== MIME-Version: 1.0 Received: by 10.90.86.12 with SMTP id j12mt1797696agb.29.1291502215101; Sat, 04 Dec 2010 14:36:55 -0800 (PST) Reply-To: forest lin <247440785@qq.com> Message-ID: <0016364c5d15c1fd6904969d4adf@google.com> Date: Sat, 04 Dec 2010 22:36:55 +0000 X-ASG-Orig-Subj: =?GB2312?B?tci0/crHtv7I/cH3tcS/zbuno6zW97avssXT0NPF1sq/zQ==?= =?GB2312?B?u6c=?= Subject: =?GB2312?B?tci0/crHtv7I/cH3tcS/zbuno6zW97avssXT0NPF1sq/zQ==?= =?GB2312?B?u6c=?= From: Picasa Web Albums To: xfs@oss.sgi.com Content-Type: multipart/mixed; boundary=0016364c5d15c4385004969d4af6 X-Barracuda-Connect: mail-gx0-f201.google.com[209.85.161.201] X-Barracuda-Start-Time: 1291502216 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0209 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.50 X-Barracuda-Spam-Status: No, SCORE=-1.50 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=DKIM_SIGNED, DKIM_VERIFIED, MIME_BASE64_TEXT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48492 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.52 MIME_BASE64_TEXT RAW: Message text disguised using base64 encoding X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --0016364c5d15c4385004969d4af6 Content-Type: text/plain; charset=GB2312; format=flowed; delsp=yes Content-Transfer-Encoding: base64 ytCzob661fm086OszeLDs7K7xNzU2bXItP0NCsj9tPNCMkLGvcyoo6ywosDvsM2wzaGi1tC5+tbG 1Oyhoru3x/LXytS0oaO2vMrUuf3By8Lwo78NCruot9HBy7bgydnIy8Gmo7/K1bvxw/fP1MLwo78N CrK71/bStc7x1LHDu7WluPqjrNf2wcvItLvYsaiyu7TzoaMNCsv5zr21xKGwvKbA36GxyOe6zs2o uf3I7bz+sO/W+r+qt6K/zbuno78NCg0KUVE6IDEzNjQ2NTQwNTSjqNHdyr7V5sq10Ke5+6OpDQq1 57uwOiAxMzc1MTE0NyAxODQNCsGqz7XIy6O6wdbQob3jDQo= --0016364c5d15c4385004969d4af6 Content-Type: image/jpeg; name="=?GB2312?B?v827p7e0wKEwMDAuanBn?=" Content-Disposition: attachment; filename="=?GB2312?B?v827p7e0wKEwMDAuanBn?=" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsK CwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQU FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAARCADdAL0DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD7f1nx zqFt8THgk1FNJt/sKMmlPqcLSyyxqJPLeFYZmDytcLGFiIdhC7Lv+QVR8I+MfEcXhTUL1bzzbm00 mEyQajbSOsN5GRC3mPJMkg3mNw7eWsKMjkuTHKX9I1vwteatLpl/Hqn2TWLGJovMjhP2abc8TuHj Dh9u6FSFEg9GLqWU0rT4cCy1OS6i1zUQtxbyQ3ar5cTzs0yyb90aKEOPMX5QMea7qUkZ3fPknfc+ YlhsV7VtSbjrbVK1169H5fjY5bw3rGt6/wD2NFY6zPYxLd3kwn12xlaW4l+YfZHAaJWZN8rsqgKp jRY/MEMjDbi+Iial4S0OaHUrGPX7n+yprqygkRpI0nntxJ+7JLKpWbAJ6bhznBrSsPBl5pOnkWVz pceotdrdGR9MJtodsC26rBCJgY8RoozvPV+zADSj8JWcXhrS9DEk/wBk0/7J5Tlh5jfZ3jdNxxjk xrnAHU4xVKMkjelQxMYNXs2n162SVtdHp/w+5t1k+IptSgtvNsrzTtNt4keW5vNRjaVI1UA42B0A GNxLlxt242ndldasTxN4YPiT7EP7VvtOW1l88JaCFlkcfcLiWNwdp+ZR2bDdVUjaW2h6tbmcHyq7 8tDEfxZrcf8AYV7cWkFjb6j9mU6bLbytLGZPLD+ZcnbHCyNIQI2UmQx7VO59q2fE/jd9LuLC20+2 8+aW7gjuWuFdBbwvdx25JGM7nLt5ecKwjdgWC4ayngst9iiutc1S/sbXyGFnctCyyPDtKO7iMSM2 9FkPz8tnI2nbRr/w+0TxSqHV7KDULlJUkW7nt4mmCLN5oh3bP9X1QjupOSSSTnadnY4XHE8klB6+ ffr339Pknq6WleOTrni650+3mtbewtbiS1DPHJI93Ki/Oiv8qQujB/kJd3RS4VUwzRT+M79724u7 dYF0m11Cz057We2kS5lNwLciTcWHl7ftS5jaMn92Rkbvl17TwZbWmqx3Yu7p7eG4lvLewcp5ME8u /wAyRSFDknzZeGcqPMOAMLtiPgeCS9WeXUb6WJ5Ybq5tm8oR3VxEECTORGGDDyojhGVDsHy4LAlp 2DkxLhZvW7/LTrsn96WqvdOz4d1W81C/8QW14YG+wah9nhaCMpmMwQyruBZssPNIJGAcZwOlbdZO i+Hho2oaxdi/urs6ncC5eO4EeyJgioAm1FONiIvzE/cB6kk61aK9tTupKSj7+93913b8AooopmwU UUUAFFFFABRRRQAUUUUAFFFFAHk3xE+MHiHw/YWljo/gvUY/FGqzrb6Xbak9pLHMwIMhZYbouFWP cS/CqSu4gGtyz+JWq6n4qg0i08G3pjhdU1WWbVLDztPDrmJmhjndmDck52naMqH6V418Vvhde3Hx Y8BfbL6PxH4i1t9TM814qQ2qxRQq0UEUUkVykcaBnIykjMzMxbJBXov2evCg8M/Fj4nW11ZWUN/Z ppsStarERGkkLuyo0cECgNhCQsa5KjO4jcfiaWMxksf7Cbkk5qP2dEoOp/K1zPZ2e2z05jqcY8l1 /WtjR8bftM2WmaBNcaNp1wJri9l07StSv/s32C8mjfazqftSOYOxnHyLuBOSNp6HwX8eNO8Y6/pW hppVwup3kDzStY3tnf21tsQFzJJBO5VdxCqzou4sOBzjzf4t2t74t+IGh6PbeCZND13xC8bw+INY 1RPtMCWeZnjtTC04tTjb+8Ucl2yhPzV0PwNvPEnhvWvE3gZtJ0q7k0bUY7q/1WTVJTcTJd5lDu32 f/SJlXILt5e7agwMZqaONxjx/s51HyXUfgdrpc3LZpNNx1vsl1la4OMeS6R2Xj34lahpmuXPhPwx o9xqvi46X/atuHSE2gj80x4kLzxHlhj5ckbgcNgrUXh74s6nqnxGs/B+peDb3RbyTSP7UnllvbeY Q/PsIwjHdHu+UMDvJIzGoyw52HQbb4k/tA6/qkct6ukaDpEehzXNlfT2plvDMZmRJYHXcI1O11Zg VcrlehruND+FOj+HvG7+KLW61WW/bTjphjvtQlu08syiTIMxZwcgcBtvX5ckmvUpvG4iq6tOfuKd t1Zxi3fRx3vdXUtfuM3ypWa1sc9Z/GkX3xjg8Lx2V6ukTaQt2sk2jXsVyLk3HljcGQbYdp5kZQoP Vx0rI+Cv7Qg8e2NhH4jfQtMv7xMwNa6rEDJL57xiBrZ381JCAjLjerBs7lJC1xtxa6Nrv7RWq/8A CceJdG1/TLLw6rXBhYWVlaSR30arbTL5zh8SfMUmZgWkAK8KBh/BPxufCreCNI1rUb2xtbC6On6Z ptgJYzrP26WUx38qzCMNaKOE2qzhzuO3IU+FHNMVHFx9rUSjzTVtNdYLVXdklzNNSbeq30NvZx5d EeqfFn46yeCPEt7pWmPpz/2TolxqmpNdo8hWRikVnCgjbIZppIy4cAeW4IYZzWtoXxws3ufBmjaz pWs2fiPXYAJY/wCx7mGGC4WNWlX94oJUMxG5N4UDLFV+avFfip4Ig8NfG+3tfCenR2uqpoK6lb6n ekTQ2Vx9ud5r+7lnLZCxCUeY+8hjHtG4JjW+Edxe6f8AEDWfFWi2set6NqnjLUtIvpLKzS4mjhl8 uSC4SZV3CEOPnLSFNpUhCxzThmeNjjpU5vTmS0V0ldXttfS19NL82t7JckeS56Hqn7SOk22qX2mW uk3v2q2utQtPtWoMkNmXskEtyS0ZllAWMhlxEdxIGByVm8JfFfxD4k+KOm6FJpujR6JfeHV11Li0 vJ5ZDG8m1HBeGPrlf3ZRSAS2/I2V55/woLxlqnijWL+aHTo9Mk1vXpUtLi7ME01vfQLCJUlRJgPl 5CtGCpTnO75TwPYah4e+PPg2xtdWt9U+zaXd6Lfw2Wpw6i1nZ26AxRTbLSAw4mKDc2WY/KSOjXHH Ziq0PrF4xc4paJXTaXba7fnZByQt7vY9J8U/GXVvCul+INeuvCMkPhrRdRWxlnu7p4Ly4TfGjTwQ GEo8e6Q7SZRuCn7vQep15j44tP7e+MfgKznsdZmstM+0agzpp3naW8rROsRlmLgRyxlCy/IxzIuC uc16dX1OElWlVqqpO8U0lot7Xb0tpqlZ6+7e+pzytZWCiiivUICiiigAooooAKKKKACiiigCpc6R YXmoWd9cWVvPe2W/7LcyRK0kG8YfYxGV3Dg4xkdai0zw5pOi3d9dafpdlYXV8/m3c1tbpG9w+Sd0 jKAWOWY5OfvH1rzHWfHOoW3xMeCTUU0m3+woyaU+pwtLLLGok8t4VhmYPK1wsYWIh2ELsu/5BVHw j4x8RxeFNQvVvPNubTSYTJBqNtI6w3kZELeY8kySDeY3Dt5awoyOS5Mcpfl5qfNfl11/K35aHkf2 pT53TSd1e/yPVte8I6F4q8j+2tF07WPI3eT9vtI5/L3Y3bd4OM7RnHXA9KNB8I6F4V8/+xdF07R/ P2+d9gtI4PM2527tgGcbjjPTJ9a878N6xrev/wBjRWOsz2MS3d5MJ9dsZWluJfmH2RwGiVmTfK7K oCqY0WPzBDIw24viImpeEtDmh1Kxj1+5/sqa6soJEaSNJ57cSfuySyqVmwCem4c5waFGk5+15Vzd 7K+3c2hj4ShzPRWuttdE9NfM7TStIsNBsIrHTLK306yiz5dtaRLFGmSScKoAGSSfqTVuisnxFNqU Ft5tleadptvEjy3N5qMbSpGqgHGwOgAxuJcuNu3G07sr0JKEbJaI7py5U5blu20iws9QvL63sreC 9vdn2q5jiVZJ9gwm9gMttHAznA6VFqfhzSdau7G61DS7K/urF/NtJrm3SR7d8g7o2YEqcqpyMfdH pXMv4s1uP+wr24tILG31H7Mp02W3laWMyeWH8y5O2OFkaQgRspMhj2qdz7Vs+J/G76XcWFtp9t58 0t3BHctcK6C3he7jtySMZ3OXby84VhG7AsFw2bVNxaa03/X89fxOf63TScm7W/r+vx0Oi/siw/tb +1PsVv8A2n5H2b7b5S+d5W7d5e/Gdu7nbnGeaNK0iw0GwisdMsrfTrKLPl21pEsUaZJJwqgAZJJ+ pNczpXjk654uudPt5rW3sLW4ktQzxySPdyovzor/ACpC6MH+Ql3dFLhVTDNFP4zv3vbi7t1gXSbX ULPTntZ7aRLmU3AtyJNxYeXt+1LmNoyf3ZGRu+UXs0+ZLv8A8H8hfW6fLzJ3V7fdu/Rf8Ne6v21V LbSLCz1C8vreyt4L292farmOJVkn2DCb2Ay20cDOcDpWFpGp663ixtPv5dOmtxYm7mitIJFe1Z5A sKGRnIlDBJ/mCJ/qgSF3AV1FaaSs2tjenU9om0rf1/X/AA4UUUVRqFFFFABRRRQAUUUUAFFFFABR RRQBzet+FrzVpdMv49U+yaxYxNF5kcJ+zTbnidw8YcPt3QqQokHoxdSymlafDgWWpyXUWuaiFuLe SG7VfLiedmmWTfujRQhx5i/KBjzXdSkjO78j4p+MeueDNC8QeIzpWleKPCdui3GnazpOorGk264j h+zOv7w+YhaQmRfkOwDCkkDX+H/j/wASeI/iT4z8O6xpmlWVroSWhVrG6lmcPNHvALMihwQCc7U2 4Aw+dw8hZhhZVo0deaXk+0mnfazUHZpu9uxjLBU5N1Gvxfl5m3YeDLzSdPIsrnS49Ra7W6Mj6YTb Q7YFt1WCETAx4jRRneer9mAGlH4Ss4vDWl6GJJ/smn/ZPKcsPMb7O8bpuOMcmNc4A6nGK4H4ifGD xD4fsLSx0fwXqMfijVZ1t9LttSe0ljmYEGQssN0XCrHuJfhVJXcQDW5Z/ErVdT8VQaRaeDb0xwuq arLNqlh52nh1zEzQxzuzBuSc7TtGVD9KpY7D+0dJKV1ZfDLd9Nt7avstXoOOEhBaLRp9enXr1/E7 2sTxN4YPiT7EP7VvtOW1l88JaCFlkcfcLiWNwdp+ZR2bDdVUjl9W8e67P8RJdA8LWOna7DYQBdXi u5pLNtOldRJA5m2v5iyJuG2ONipALMAcDP1j4ieM9H+JPgjw7daJoVva6692JWh1Ka4cJDGrsVYw RhSASQCrbumU+9VTzChFO97KSjdJtXbUd1pu7PXR3T1VjWdH2keWWz87eZ16eCy32KK61zVL+xtf IYWdy0LLI8O0o7uIxIzb0WQ/Py2cjadtGv8Aw+0TxSqHV7KDULlJUkW7nt4mmCLN5oh3bP8AV9UI 7qTkkkk+R+I/2qpvD13qnmeF4xYWOvS6E15NeXCpuQnMrMtoyAYGSiu0nohHNaPhT47+IPGHi7w9 p66Jp2h2WozzLEuoNfeZqdukYf7RaSG1SPaFJbD8sMDCZBPEs6y6c/YxneTaVrPq7dV3/wCBqQ8F FxalG6ffX8/6R6haeDLa01WO7F3dPbw3Et5b2DlPJgnl3+ZIpChyT5svDOVHmHAGF2xHwPBJerPL qN9LE8sN1c2zeUI7q4iCBJnIjDBh5URwjKh2D5cFgfLvHv7Wmi+DItQSHw9qt9dW2o3OlxtK0MNv NPbsgmG8O7gBZFIJj5yBxzg0b4+eJNf+JOieHY/D2lWVrNq+paReM1/LM7PaRo8jxt5SBQA+QGU7 +h8v71N5zl6qexU7yulZJvWTsulv+AH1KPL8Om/9fLS21tNj2iz0iGy1DUL1WeS4vXRnaQg7FVAq xqcZCA7m28/NI5/iNXaKK9/YaioqyCiiigoKKKKACiiigAooooAKKKKACiiigD5Y8V6VJ4l1b4sj Vb3TvAs3h6DT7q2awnd7KK9kb7QbxiI0drp9ixCVED7ZCoEhxu1vhPD4W1/x3J4l8Vy2+jeJE8rT NO8K+IdQlur2zYMsqSk3h8wyuzAx+UAqq3G52bHut14F8N32tLrFz4e0q41dXSUahLZRNcB0xsbz Cu7K7Vwc8YGOlaNzpFheahZ31xZW897Zb/stzJErSQbxh9jEZXcODjGR1r5Snk041lWk4uzb1V7+ 9JpvazipWSSs7a/Z5eh1Vax80fFb4XXtx8WPAX2y+j8R+ItbfUzPNeKkNqsUUKtFBFFJFcpHGgZy MpIzMzMWyQV6L9nrwoPDPxY+J1tdWVlDf2aabErWqxERpJC7sqNHBAoDYQkLGuSozuI3H3W50iwv NQs764sree9st/2W5kiVpIN4w+xiMruHBxjI61FpnhzSdFu7660/S7Kwur5/Nu5ra3SN7h8k7pGU Ascsxyc/ePrWlPJYUsYsVB6c/NbfT2fL11b5vebb/ETq3jy/1ufNHjPwXqvjf4zeN7fS9Kt9Z+x+ IvDl7dWl5KkcLW6WcwfzCwOVO4AgKxwThW6UeFPCv/CD/HXwXpM9xoyX0ut69qbaXo9z5q6fFPZQ mKJgUQrwhx8oBABHoPpy20iws9QvL63sreC9vdn2q5jiVZJ9gwm9gMttHAznA6Uf2RYf2t/an2K3 /tPyPs323yl87yt27y9+M7d3O3OM81l/YMef23N73tObyt7Tnsut9lq2uth+10t5fpY+IJodS8Ye MvFVjdPozaVf/wBorpGt3ul2Vu2pus/lh4Z47KR7mU787YcOxPyspwD6H8B/hNrPhPxR4PbV7LUb G1tp9R1SwmeyLeas8CQeTdBWP2SUJEkgDFw28puDoQfpH/hEdC/sD+wv7F07+xP+gb9kj+zff3/6 vG373zdOvPWs6z+F3gzT7uC6tfCOhW11A6yxTQ6bCjxupyrKwXIIIBBFcVDh2VGtCvOfO009W11U rbO6TWmq87renWurLQ+Qfj58K/GOmaXrmsXejRw6FD4l1TUvtYvI2fyrp7ZImMYOQCUGMEty25VA Bb6M1Twd4B+Emv8AhvWv7J1F9T1DW/sVpOL+4uNl3doyPM6yzY+ZVwzYLHC8HAx6peWcGoWk9rdQ R3NrOjRSwzIHSRGGGVlPBBBIINc7Z/C7wZp93BdWvhHQra6gdZYpodNhR43U5VlYLkEEAgiu2lkU MLXqVqNpOXK7zSbi4t6rTtbs01e76S6vMkmdPRRRX1hzhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA HjPxA8e+IfD/AMTvLjn0zS9Hsre2ie81G5kFnDDeLdlrq6HyqrxzWEMca7gG8508xTODFjaR4t8R +DfBvim/bxJdanq+jaB9rsvDHieSMT+XHGrPeSOtrFPKhztXIBJUiVo5WdLf0bxh4E17xBqE15p3 iuXSmaSNVtTHObb7OtvcRsrLFcRP5jPcl/MV1x5Nvhcx7jS0j4Z+ILfS9bXUfGctxq+rxrb3N/p1 gtkNgihiMyornbdBY5SswYYMqhkdIYkT7Sli8vVCEZKOihdWld2ab15Xa/vXad9Uo6XPmZ4fFurK UebeVnddU7acy8rJq3V9DzmfX/FBQWC+KrrRrjw/9r0uS7hlFxLa2y3KRw6hq0c0EinzIkWRSPLJ AeQOIZZXtfQPjB4gvNG+BOs6no2v2rY0h2XXri4Cs6mBtksRh2K0srmNUKlFDShlDbRG8F78KvFW o6jcJc+Nop9CuLtppbGXTpXn8n7b9qREma5IikjBaJJokRlUqfvRRGPrfEXhK81aw0NrXVtmsaNc C6tr6/thOksnkSQO00UZi3bkmkOEKANtPQFTFfF4J1qE4uLUZNuyfrZ3hfV3/mSVnaTuiqWHxKp1 YNS1SSu16ae9bb0bfVaGn4ZvbjUtBsrq6uLG7lmj3i60xy1tcIfuSx5zgOu1tuW27sB3A3G7evcR 2Vw1nFFPdrGxhinlMcbvj5VZwrFQTgEhWx1welZnhDw5/wAItoa2LXH2uZ7i4vJ5gmxXmnmeeUou TtTfI21SWIXALMQSdO9t3urK4giuZbOWSNkW5gCGSIkYDqHVlyOo3KRxyCOK+Xq8ntpcjvG7t0Vr 9tz3qfN7Jc29vxPP18R+L0l1/SzdaPeXelRwXEusW2l3LQxB0ld4BZpM7zTqscLbBKpK3cbbflVZ bul/EtIvAq63q1vK9wkdyfKsLd83LQz+QqIrH91PMxQLayP5odzGctG+IdB+E9z4b02S0sPHXiZN /lgTSfYZGUKZWY4a2Kl5HmZ5JWUyOyqS5wc7Nt8PdJTQ00a7T+1tJbzpLuy1KGGeK9nlmE7zyqUx v83ewCbUBkOF4Tb7NaeBbtdNcy+FNNpR97orXdrK9l5bvzKUMUlfVOz3d1e+nXWy3e/rsuGn+NOp Wfh7R0ubOxj8Tapqep2QtrYXFzHbw2lzLC80cccZluim2HMaBGfez/ukV2TpvGHjO90f4X61rWk3 tjf6pp2if2ul79ilbT7sCNnzHtkwQ4jbAWVigdGO4EbodO+Cui+HLWCPw3c3Xha5huLyZbvSobZX 2XMqySxFHheMpmOBVOzcqwRqGxuDaerfDey1HwRd+Ere/vtL0KbTI9Ijt7QxMYLdVKMEaRHYl4yE YsW4UFdrZY6VKuWurCVJWXPd3XTm7WeijZJXd9b2drxCnjVCSqO75bLXry99PtX1sraW0val8Udb 8VeHtIuL/QZ9HgWKOOK3h1C1luZL68lkEUMA2yxLCGkaJfMYuP3pJCCPLdzWNe+F4tUg0SK/vLq9 /sy4juiZfLAvJEjZVaZVQKcOyygKFAkjjYY2gVs14tWpB0oU4pXV7tK29reb2b1720senThJVJTb dnbS/r8lvbTtcKKKK4zpCiiigAooooAKKKKACiiigAooooA5Dxf8W/CPgeDU/wC1PEGmx32nwNPJ pgvYRdvhN4RYmcEuwxtBxncPWobP4zeDb+zgkg16yu72WNX/ALL064S/vQSMlRDbNIzled2zcAFY 52gmuK+N2oa5G/h67m1W28MaYNc+zwxXl5BbxS7Le4kW4uJpIZ0X95FGYk2NghWbEjKIIfhh4r1X Wfija2lz4xsvElr/AGNeymDTtbt79I3E9oFZ1gtLcKcMwUtv6vjb82766GVUZYJYi19G3afbovca 6d36n3tPI8PLLo4vlvZSk2p9uiXs2t0+rtfd2PR9Z8dS6d4jm0Wx8N6trt1BaQ3kz2D2qJGkryog JmnjJJMEnQHHHPNY/iX4o6t4c8Oarq0nw+18R2FpLdMZrrT1TCIWO4rdOwHHJVWPopPFc58TtPuN T8SeKILaxvdRk+yeGJDbaa5juHRdWuWfY4ZdhCqx37l24yWUDIx/Eui31j4c+IV23h7X7DTZfCN7 FHP4h1WO+e2lVHLLE32qdwJlZCw+RR9lT7xYbaw2CwslT51FtuOjbu7qDf21/M7Wj06srB5dgpKl 7SMW24qzbTd405P/AJex/ndrQ2ju3oev+NfFtv4N0NryQRzXs0i2un2UkwiN7dvxDbqxBwXbAzjC jLHCqSMe6+MHh6wiWS5h1+3jaRIg8vhrUlBd2CIuTb9WZlUDuSAOTR8VNBsb3wZ4onkeO31C80af SYLm4MjhDMpVURFDHLyNGCI1LyFYxhiqAfMugQWdz4g8GCHR47DUrvWbN4rT+yo4rgGC7iN0oZNG gBMIVxJsnAXa2Sw+VqyrKcNmGHdWXN7rd7WXS/Z6JJ6/N9C8jyHCZrhHWnzXg3zNWWlr9U1ZJN36 at6WPqzxV4zi8K+EZNXubbyr54CbTSbmdEnuboxlktEKlg0rFdoCb8n7u6ptV8Y2enS6NHBHJqja pqTaXEbF42EcqLK0pcs6gCMQS7gMsCuApPFc38W4Li7uvBVvbafZatJNrMsRstSmMVvMjabfB1dh HJxtLcbDnocA5HIfDHwG9xp0bajouk6no9zqWqaXPoxhV7XSoI7+5lUxb8BwZo1RgI13AWx2r9nO /gpYPDPCRxNR2eul9781la99OW625r2vex5dHL8G8DHF1nZ3btfe/OkkuZP3eS6vbmu4817HtVre W9/E0ltPHcRrI8ReJwwDoxR1yO6srKR2IIPIqauK+D9nb6d4NmtLSCO1tYNZ1eKKCFAiRoupXIVV UcAAAAAdK7WvFxNJUa86UXdRbX3Ox85jKMcNialGDuoyaT72dgooormOQKKKKACiiigAooooAKKK KACiiigAooooAztV0G31e+0a7meRZNKu2vIQhADOYJYSGyDkbZmPGOQOcZBzYvCM3/CfyeJbjWLm 5hSxaytNMaKJYrXzGjaZg4UO24wQ4DE7SH5IYBec8S/F5NA+IUHh6PTL6/URpDLHb2bmaW6nSWW1 WFmKo0ey0uhJIfkRmiyyhZimZoXxh1q18Kaxr/ifQbUaPo1gJrnUdCluZmuLlR+9ijtpbeN02EHe XbETZRmzHN5fv08Dj1TU4x0cUle17TbslfW78tWn2bMI51Ck3TU9lKO17LeWtny7u706q9nZ9hrP gWXUfEc2tWPiTVtCup7SGzmSwS1dJEieV0JE0EhBBnk6EZ444rN1n4YX/iDSL7S7/wAeeJJ7G9ge 2uIvJ05d8bqVZci0BGQSMgg1yjfGbxM9rpwsfDtrqV/H9q029t5jcWcd7qkMoieKwl8uUMgKTN+8 CjYQxceRciPs/iR411HwL8NNT10aZ9p1q3sJZltLYNcQRzJC0jF5D5f7pdjEs2wsBhRvZUO3sMwo VKVO0eZu0dIN6O27V0l3eluuh1UeIZRi6kGv3aTu4RbVlpaTi22lole608jQ8S6FrWsahaPY6ppt hZw/MGm0s3F3DIQ6NLBK0oSN/LcqC0TgZbIYErWPbfCGw0vUL3VdK1nW9L1/UNn9oavFdLNLe7Rg eZFMkkI9tka7B8qbVJU9fo2p/wBsabDdm0urF3yr215HslidSVZWGSDgg4ZSysMMrMpDGa9u00+y uLqVZWigjaVlgieWQgDJCogLMeOFUEnoATXlxxWJpfuYu3RpJa67PT3lfWzur6nbSzPEUqSjTnaN rPRWave0tPeV9bSur67nLXPw8/t3QfD9l4h1vUtVvtKn+1tqNrL/AGfLcTGKWMnNvsKJiZsKhBwF DM3zbtLQPCFv4X8My6Lpt7ewxtJcypdyyie4jeaV5WbfIG3lWkOC4bOBu3HJOTF8SWk+1WreF9dj 1yDyW/sXbbPO8cvmbJfMSYwIh8icZeVTmPGMvGH2tI8W6dqvhyTW3k/s+yg89bo3rLH9leF3SdZG yVHlvG6lgxX5SQxXBOtf64octT4brRWtd3aslpZ3drKz1S2OV5tUxEfZOp7t+bltaKabv7tlFWcn pbRO1rWLHh7Qbfw3pUdjbvJKokkmkmmILzSySNJLI2AACzu7EKAo3YUAAAaNcZB8V9HuvDljq8Nr qcn9oX9xpdjYfYnW6uLmJ5lKeWceVn7PI2ZSgUDMhTBxp+JvF48KeCL3xLeaVfNFZWn225sITCbm JAu6QcyCMlF3E4c52naWOM4VMNiZVeWpF88pNa6NyvZ/jo3tc454yFbmrSnf7Te++t/nudBRXJ+K /iRZeE725glsL69isLRdR1O5tBF5en2rGQCaQO6s4PkzHbEsj/uj8uSobrK550alOMZzVlLb+vRp +jT2aHGrCcnGL1X9f5/NNBRRRWBqFFFFABRRRQAUUUUAFFFFABRRRQB5N8SvD2uajrl7fad4X/tC OT7LZi7troxX6COG9cTwsLuAKiy3MUfyyRyOr3SnKFGrM07wj4g1TRPFcr+CYtCXVtMGkweH59TU W8bG3gh3Mls6xNAPmUycXKx2+ELCSOGH2yoby8t9Os57u7njtbWCNpZZ5nCJGijLMzHgAAEknpXv U82rRhGlGC0svtX0t/etrZdPJWR5by2FSo3d630tHrf+7fqzwzU/Dfie/wBY1i0XwFLANRu3jj1i K8gEFmv9oiRbiONrpnQSRLHNKIEglM0O4MHdJIO68deGtR1bwNpGlPp91qNgNkOtaPY6kzXF5bG3 kQwpdSvEz4laJmZ3jLojhs7ijd/RUVM2qzlCXKlyu6tzb2t1k7WSVrWta6s9Qhl9OKlHmb5lbp69 tb9b3vs9Dn/Adpqlj4WtYdYaU3YkmZEuJfNmitzK5t4pZMnfIkJjR23PuZWO987jtXr3EdlcNZxR T3axsYYp5THG74+VWcKxUE4BIVsdcHpRZ3lvqNnBd2k8d1azxrLFPC4dJEYZVlYcEEEEEdamry6s 3OrKclZtt26b7HoxpulFU9dNNd9P1PLNE8P+OoLLWpNb0Lwprd/qkcMN0suqz+XcJiYSoS1owWBQ 8axwBD96Znd3dme7D8LXvvBlv4e1F4rVWjuQ15p7oZLGKS6SdbCESwsj2oRRCysqq0cKKYsNhPRq K9CeZVXLmhFRd09L7pWWjbVkum3R3WhwxwVNLlk29GtbdXd9Ovf9TxNfgfqlrb6fLemx8by2t3rD Npuu3P2e2livLtJ0ZzFbFZCvlKxjeJl8yVmVlEUYrpvEPgLWbn4X6v4btTY6prV34di0Q67qE7xT Xj+XJG7zERyMAvmNIo3PuaRwdv329Goq55viakoynZ8r5uyvzc2y0tdva1763srTHL6EE1G+qt+F t/S2+3Td38z8ffDO/wDiTPYRXsdro1tJbwLq1zYand+bdxiTM1gUj8lZImVpFWWQsVEkm2JS5Yem UUVwVsVUrU4UpP3Y3su17X3v2R106EKU5VF8UrXfe2wUUUVyHQFFFFABRRRQAUUUUAFFFFABRRRQ B8wanp+g2WreILi9sbLXNY0rTfFmrS6PrTtdxW7i/iktXNq7EQiSNtwKBPMVt2TnNbuj+C7C1+IG jxXegeE45tM8VrZRT6LoK2TPjRprvc2ZJM4eSIqARhoQ2SSNvss3gXQbjSr3TpNNje1vI7yKYEtv KXchkuVD53KHc5IUjouMbRjHuPh/b6ZrHhRfDukaTo+j6dqU2pXiWqC3LO1nNbrsjSPaxPmjLMy4 EY+9nj7b+2o1YSpqUk3Ga1emt2tb6dUoruld2R+j/wCscK1KdKMpJuNRatW1vJWd7rrFRV/iSu7I 8417w9oOrfGZLHWo47y6vvE4mXR7+dpIbi0XQSBOLRm8tgJoyvnbCQyFd3GK5bT/AA7Ya/pOmz6j 4W8FRQ3MHhnVAul+HVtpV+26iitEXaV9yBInU/KN4k7AEN9KQeHNMt764vUs4zdT3YvnlkG8ifyF t/MXOdh8pQny44z/AHjnj7/4UaZougafpXg/Q9J0iMalps93KB5LvBa3CTZLKjNNJ+72jeR99iWz 1MPnUbU6fNJNKmrt6Llb5nvpporXv5aIMJxHBKlS5pRcY0optqy5G3N76JqyVk27dNEeg0UUV8Sf nAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBz+r+O9G0HXodK1C8itJZLSW9ee aVEhhROcSMzDaWVZnXjlbac5xGazPDnxa0HxD9oR01PRLm0sF1K9g1zTLix+xwnPMskqCMYKuMhy D5bkEhSR5n8WP+EZ0Xx/ea7LNa2epRXGmNHcXdnbvYf2jDbalJGLh5J4Q0vkOoUM8ZjZrNtxVsDM tLrw14i+HPjvR9Jv4tY8E3GmbLa4h0pbiaa+a2txGqMPKQTqz24jtSgIZo0ikURGC3+0pZPhp0IT fNqoXdnZXav0d99FdXs3dLf5meY1o1ZRXLo5aX7J26q22rs7Xtqep3Xxv8Oafptjf3cepxW01g+o XRhsJLltMVDtaO8WEO0DhlmX5htDW04LApit/wATeOdL8J+CL3xVqLywaXa2n2xlmj8iZhtyseyX aVkYkKEbadzBTg14BdeIfCFjr+q2em6vYjXo9bubjTNMkt7YXM+oPqipOk5DsZj5kcLRRuLdTGYW MgeAXFt6Z8XJk1f4Zafa6lcWNjFrMbWVz4h1KxeCDSRNZzK9yYZXVoS2TAqvIpVrhVJY5R4r5Vh6 dahHlkoyk73vstdFy9tLpu7TSTa1qlj606dV3i2krW77a699dbWTu2k9PTbK9t9Ssre8s7iK6tLi NZYZ4HDxyIwyrKw4IIIII65qauZ+G+p/2x4Rt7z7Ja2vm3F0d9lH5cF3/pEg+1xrk/JPjzxy2RKD vf7x2tbWzfRr9dQtvttgbeQXFt9nNx5se0708pQxkyMjYAS2cYOcV8vVpezrSpdm13e9j3qdTnpK p3VzLt/iF4VutBudcg8TaPNottIIp9Sjv4mtonO0BWkDbVPzpwT/ABL6itqyvbfUrK3vLO4iurS4 jWWGeBw8ciMMqysOCCCCCOua8f0fxTY67qWt+JtV0XxNpF/Nb2ltaOvhm6klsABeCIxq0DlrhRNO ZHCGFRNHGDJ8zSXbDRfEM/w1fS9KlutO1i//ALReL7UJLQTQzX243UkyxM1tdtDIZEUBQskr/ucR 7I/ZrZZGm+W7i+ZL3tleN3rbXl6taa7JavzKWOlNXspKzem+jsuul+i39XovTW1vTk0251Br+1Ww tfN8+6My+VF5RZZd75wuwowbJ+UqQcYNQXfijRtP0FdcutXsbbRWjSUalNcolsUfARvMJ24bcuDn nIx1rwCz8Kaza6L4XttZ0qXwz4f0rW9avI4dB0t9Uktrj7Yxsnhi+zHywFkutjtC8flhGwkjxGP1 O41iWLw/p134ph1O0182Fq0kOkaNJfrpl7JDMsktuY4ZvnGZUJLOqqIwQBL+8eIyuFGS5J895Nab 2Umlsmm3ZNtN8t1o21dUcfOqnzR5dE9drtJ9bPrZJ2vZ66O2/qvxC8K6DZafean4m0fTrTUI/Ns5 7u/iijuUwp3RszAOMMpyM/eHqK6CvILXwvcXXw6ttJ/siWO78SanLaX13JbFJZtNa8uLmR7o43Qm a3af5QE8ua7CqsOcJ6/Xn4yhRoWjTbbvJdNUmkmrbX1W7va+mx2YarUq6zVlZP5vdfl99gooorzD uCiiigAooooAKKKKACiiigAooooAKK5DXNMuLzxRHaReN9b0i4vIJLmDTrS3smiWOIxJIwaS1dvv SxnDOTlzjgYHOeB9O1PxF4R8F6xrPj/W/tGqQWV8bJfsNvHcTeWtw0K7LdZChCPlQ+SgYEkZr044 JSpe2dRJadJX1v8A3bP4X1tdbnswy5SofWHWilppad9ebb3LO3LJPW11uepUV438T/E/ia08fDTd K1PVtP09Y9FR5dPisWhhN3qEtvI0vno0hJRVCeWCAwywx1h1p9Yh8cWXh220XxJf2M841JINW1G0 e2YWIhiiKSea06RGZ7aeRm3yEx8RP5soHXTymU4xlKpFXTdr62STa1sr2d0r+rSs330shnOEJyrQ XNFytfWySk078q5uWV0r201aVm/aqK5bxrcahqfgxr/wvd3t1dGNbmzGizWYN6GX5FElyjxCM7gx YDOFyufut414KtLvxfa/2peHW72G9vraK9n8QeJA2hlGlRZYbZLadkunkEgj2sogaQMoWID7PUYX LfrFGVadRRSdrac1/Rtf8GzS10MsFk6xWHnialVRUXy205r+jcdO2rvZpa6H0dRXOfEHxPF4S8L3 N82rabo9x922l1Qp5UkmC3lAPNCrOyqwAMigHknANfOOnfFmTUPtX2fVdEgC6q13ax6tdaelk1xx 5k08SakGRFuAzx+WrgKPOIuJnWVdMvyerj6UqsZJJO2t/wCv6ZtlXD9fNKMq8JKMU7ap/wDDfdd6 PTQ+saK841fxRd3Pw7iuNL165lvJdVsLFtZisBCrrPewI72yyxsjxeXMRG48xSuDvkILHhLvxnrz 634U05da8SX99JPr2nyHRFsBPK0V6y2pnWdVgXMNnc7W2qxMcm3+MVNDKK1dOXMlZyTvdW5YuV3d aKy66+RGFyCviYuXPGKUpRd+ZW5YOd3eOkbK2tnd6o+gqK4r4X2uv29tr0mvtqxafUvMsxrUtq9w IPs0C8i2JiQeYsuFXHqRliT2teVXpKhUdNSUrdVqtuh4eKoLDVXSU1K1tYu62vo/LYKKKK5zlCii igAooooAKKKKACiiigAooooA848TeKLfS/itpE8thrc1vY6VfW089pol7cxCSaSyeNQ8cTK2Vik5 UkAqQcHiuc+El54R8D+EfD7f8IjqWleIk0q3tr+4tvB96s7yCNPNV5Utvny65JyQSM817MtzC9zJ brKhuI0WR4gw3qrFgrEdQCVYA99p9DUVhqdnqkRlsruC8iG3LwSBwNyq68g91ZWHqGB6EV7UcfTW HWHcZWsr2la9nJ/y7Xk9PT5/QRzWgsKsI4Ss0k7TSvZye3I9LzemvTzv4x8X/BOr3fi7/hJUtNAj jS70Gz0/ULuN7q7gdNRBJVNsflhmuRu2ynKw7cAyZjzdW+HWl6nq938Q4PCWm+JraGC2WW1tNLi/ 4nY3Tm8uYIZCwO4ywyRuSZJPsxRWKSrI/vKanZyeVtu4G82V7ePEgO+RN29Bzyy7HyOo2Nnoas10 0c8r0qUacVtpo2rxtG60115d09LuyTs124fibEUaMKUF8K5dG1eFo3jpqm+XdSVrtpJ2a4rxns8b aVDoUXh+TVbfUI4Lt5dUtmisrYCQSRmdHKPIQY8mBQSSoWXylcNXCeHPBeleND4puLXSLLWpLDWU gtR44sLi6uPswsbaRrcPdfv4AZZHYMwcLvZhGwYV7hRXJQzKeGpunSuu2r3urtrq2klpay7nDhs3 qYOjKjQTS6e87XbTba2baioprlsu71OWi0jV9Y8OaHbPcSeH4GtEXUrITPc3oOxf3SXnmZBBDK0u GdgSVZGw4+U/G+jeEvD+i+NrC5sf7N1eGfVfs9qIfD0Sopmma32rMBeBDGYyu35tpHlcbK+1aK7c tzueXzb5OZNp2vbZt72be+7u/M9HJ+I6mVVJSdNSi2nZO2qbe9m3va7u7dTnPFXgi08R+FYNAhb+ yrGGezkRbMGLy47eeKURxmNlMeRFtDKQVyCOmK8gg8D/AGHT4PFOj3mtxaZBrm+2nsI/t+oPYk3y eeivHL526fUZ5A/z7rYRuMyZ3fQVFcWFzOthabpXvFu7T2d9Hunq1bV7dtTzsDnWIwVKVC/NCTu0 9ndWlo09WrK7vbXR3ZyHw61mG/g1OxsNA1LR9I0+dY7S61GCWFr7eiySSbJgs2/zHcM7g72+bexL bevoorzq9SNWo5xVr+d35tt7tvV+b0SWh5OJqxr1XUjG1+7bd7att7tvV7K70SWgUUUVgcwUUUUA FFFFABRRRQAUUUUAFFFFAHjHifSr6L4pW11fwPf3U1j5drctBYQ28UqGBIniaYySxhZ7mRicFyzR KFlCc5vhvSb200LXLG5un0/WbDRxYSTLqM0blYJComjcvFGgjULIIzGuUniLzYnc17Hf+FNM1O2t IrmB5HtE2W9158i3UIwAds4bzAWAAYhssMg5yait/BHh+0ura4t9GsbeW2iMEXkwKionmrNjaBji RQ4OOGyRgk55vZO9z5+WWydVzT0d933Sv0+7Xy6s838H6A2sNpkWp2E9nDaXc8P2PRrq5tY7O5eE SiYoixeVG0J2qowU83Em+SaQx6UGs3uo/Dnwsl1ZXzbv7DmbVJ5Injnc3NoT/wAtDIWyxyWUdDz0 z23/AAh2mjTfsSG+iiMvnvLFqNwk8r425eZZBI/y4GGY8Ko6KMaQ0yzWzgsxaQC0g8vyoBGPLj2E FNq4wNpVSMdMDHSqVNpWN6eBnCLje101p10S106W/wCGLNYHi+C0ktrdry41HG8xwWOm3T28t1MR lVDIysSAr8FwgBZn4Tcu/WbrPhrR/EXk/wBq6VY6n5OfK+2W6TbM4zt3A4zgZx6CtpK6PTrRc4OM Un67HHXMOpWen+GtZm1Z7+4lewhur61vW+znzHhjPlW6qsUqSs75d8Mgk3LnaiDS8eQXo0r+1bm4 eDTNMS4ubywsrqaGS4iXlXSaNo2V1jVm8s5RmbaSMLINu28IaFZahFf2+i6dBfQoI47mK0jWVFCb AoYDIAT5cDtx0ol8IaFPfQ3sui6dJeQP5kVw9pGZI23mTcrYyDvZmyP4mJ6ms+V2aOL6tU5JR7+f brtr5p77NtbclpV3cnVdH1E3l09xf69qGnXCPcO0Jgi+2eWqxE7EI+zxfMqhjtOSdzZu64Hj1fTp RqE9vrjy2rywi+f7FaQGREdGX5UfzD5kcZdDIzv8uAmY+pi0PTYNVm1SLT7WPU508uW9SFRNIvHy s+MkfKvBP8I9KojwP4cW9gvB4f0sXcHl+VOLKPzI9gATa23I2hVAx0wMdKOV2sH1eoocl09f0Svt v19XvfU5f4d65favfWd9qyXS3Gs2Mt/Yq13ujitg8Z8poUAQFfOj2yHfI67ixj4jHodUrDQ9N0q5 u7iy0+1s7i7fzLmW3hVHmbJO5yBljlmOT6n1q7VxTSszpw9OdKnyzd33/r+unmFFFFUdQUUUUAFF FFABRRRQAUUUUAFFFFAH/9k= --0016364c5d15c4385004969d4af6-- From stan@hardwarefreak.com Sat Dec 4 22:48:04 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB54m4tx033800 for ; Sat, 4 Dec 2010 22:48:04 -0600 X-ASG-Debug-ID: 1291524566-5bd5026b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from greer.hardwarefreak.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A13D31DB6B2D for ; Sat, 4 Dec 2010 20:49:26 -0800 (PST) Received: from greer.hardwarefreak.com (mo-65-41-216-221.sta.embarqhsd.net [65.41.216.221]) by cuda.sgi.com with ESMTP id MvkYblPvNLbb9WWS for ; Sat, 04 Dec 2010 20:49:26 -0800 (PST) Received: from [192.168.100.53] (gffx.hardwarefreak.com [192.168.100.53]) by greer.hardwarefreak.com (Postfix) with ESMTP id 770C36C161 for ; Sat, 4 Dec 2010 22:49:25 -0600 (CST) Message-ID: <4CFB19D5.7010301@hardwarefreak.com> Date: Sat, 04 Dec 2010 22:49:25 -0600 From: Stan Hoeppner User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs_repair of critical volume Subject: Re: xfs_repair of critical volume References: <75C248E3-2C99-426E-AE7D-9EC543726796@ucsc.edu> <201011121422.28993@zmi.at> <4CDDBC5C.7020708@hardwarefreak.com> (sfid-20101113_121516_584378_2321CE16) <201012041130.20344.Martin@lichtvoll.de> In-Reply-To: <201012041130.20344.Martin@lichtvoll.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mo-65-41-216-221.sta.embarqhsd.net[65.41.216.221] X-Barracuda-Start-Time: 1291524566 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC5_MJ1963, RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48516 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS 0.50 BSF_SC5_MJ1963 Custom Rule MJ1963 X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Martin Steigerwald put forth on 12/4/2010 4:30 AM: > Am Freitag 12 November 2010 schrieb Stan Hoeppner: >> Michael Monnerie put forth on 11/12/2010 7:22 AM: >>> I find the robustness of XFS amazing: You overwrote 1/5th of the disk >>> with zeroes, and it still works :-) >> >> This isn't "robustness" Michael. If anything it's a serious problem. >> XFS is reporting that hundreds or thousands of files that have been >> physically removed still exist. Regardless of how he arrived at this >> position, how is this "robust"? Most people would consider this >> inconsistency of state a "corruption" situation, not "robustness". > > I think its necessary to differentiate here: > > 1) It appears to be robustness - or pure luck - regarding metadata > consistency of the filesystem. I tend to believe its pure luck and that XFS > just stored the metadata on the other RAID arrays. > > 2) XFS does not seem to have a way to detect whether file contents are > still valid and consistent. It shares that with I think every other Linux > filesystem instead BTRFS which uses checksumming for files. (Maybe NILFS as > well, I don't know, and the FUSE or the other ZFS port). After re-reading my own words above again, I feel I a need to clarify something: I took exception merely to the description of "robustness" being used in this situation. I was not and am not being derogatory of XFS in any way. I love XFS. Of all available filesystems (on any OS) I feel it is the best. That's why I use it. :) In this scenario, other filesystems may have left the OP empty handed. So, I guess XFS deserves deserves a positive attribution for this. But, again, I don't think "robustness" is the correct attribution here. -- Stan From roger@filmlight.ltd.uk Sun Dec 5 03:43:21 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB59hK9R065211 for ; Sun, 5 Dec 2010 03:43:21 -0600 X-ASG-Debug-ID: 1291542305-690801f80000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from a.mx.filmlight.ltd.uk (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id A3B931DB7045 for ; Sun, 5 Dec 2010 01:45:05 -0800 (PST) Received: from a.mx.filmlight.ltd.uk (a.mx.filmlight.ltd.uk [77.107.81.250]) by cuda.sgi.com with SMTP id NkjptsbVyKdMLHEs for ; Sun, 05 Dec 2010 01:45:05 -0800 (PST) Received: (dqd 6921 invoked from network); 5 Dec 2010 09:45:00 -0000 Received: from 50c553bc.flatrate.dk (HELO ?192.168.2.36?) (roger@80.197.83.188) by a.mx.filmlight.ltd.uk with SMTP; 5 Dec 2010 09:45:00 -0000 X-ASG-Orig-Subj: Re: xfs_repair of critical volume Subject: Re: xfs_repair of critical volume Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Roger Willcocks In-Reply-To: <4CFB19D5.7010301@hardwarefreak.com> Date: Sun, 5 Dec 2010 09:44:59 +0000 Cc: xfs@oss.sgi.com Content-Transfer-Encoding: quoted-printable Message-Id: References: <75C248E3-2C99-426E-AE7D-9EC543726796@ucsc.edu> <201011121422.28993@zmi.at> <4CDDBC5C.7020708@hardwarefreak.com> (sfid-20101113_121516_584378_2321CE16) <201012041130.20344.Martin@lichtvoll.de> <4CFB19D5.7010301@hardwarefreak.com> To: Stan Hoeppner X-Mailer: Apple Mail (2.1081) X-Barracuda-Connect: a.mx.filmlight.ltd.uk[77.107.81.250] X-Barracuda-Start-Time: 1291542306 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48534 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 5 Dec 2010, at 04:49, Stan Hoeppner wrote: > Martin Steigerwald put forth on 12/4/2010 4:30 AM: >> Am Freitag 12 November 2010 schrieb Stan Hoeppner: >>> Michael Monnerie put forth on 11/12/2010 7:22 AM: >>>> I find the robustness of XFS amazing: You overwrote 1/5th of the = disk >>>> with zeroes, and it still works :-) >>>=20 >>> This isn't "robustness" Michael. If anything it's a serious = problem. >>> XFS is reporting that hundreds or thousands of files that have been >>> physically removed still exist. Regardless of how he arrived at = this >>> position, how is this "robust"? Most people would consider this >>> inconsistency of state a "corruption" situation, not "robustness". >>=20 >> I think its necessary to differentiate here: >>=20 >> 1) It appears to be robustness - or pure luck - regarding metadata=20 >> consistency of the filesystem. I tend to believe its pure luck and = that XFS=20 >> just stored the metadata on the other RAID arrays. >>=20 >> 2) XFS does not seem to have a way to detect whether file contents = are=20 >> still valid and consistent. It shares that with I think every other = Linux=20 >> filesystem instead BTRFS which uses checksumming for files. (Maybe = NILFS as=20 >> well, I don't know, and the FUSE or the other ZFS port). >=20 > After re-reading my own words above again, I feel I a need to clarify > something: I took exception merely to the description of "robustness" > being used in this situation. I was not and am not being derogatory = of > XFS in any way. I love XFS. Of all available filesystems (on any OS) = I > feel it is the best. That's why I use it. :) >=20 > In this scenario, other filesystems may have left the OP empty handed. > So, I guess XFS deserves deserves a positive attribution for this. = But, > again, I don't think "robustness" is the correct attribution here. I think 'lucky' is probably a more appropriate term. The chances are = that due to the size of the array, all the inodes and the inline extent = lists were on the first volume. If' he'd lost that instead, everything = would be gone. -- Roger From 3kwn8TBcKA-UWPJHZHdLIHSIbTZ-UVYLWSfNVVNSL.JVTeMZVZZ.ZNP.JVT@photos-server.bounces.google.com Sun Dec 5 15:50:35 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.3 required=5.0 tests=BAYES_99,MIME_8BIT_HEADER, T_DKIM_INVALID autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB5LoYab147153 for ; Sun, 5 Dec 2010 15:50:35 -0600 X-ASG-Debug-ID: 1291585939-387103960000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-vw0-f73.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 71CD71C980DC for ; Sun, 5 Dec 2010 13:52:19 -0800 (PST) Received: from mail-vw0-f73.google.com (mail-vw0-f73.google.com [209.85.212.73]) by cuda.sgi.com with ESMTP id rgpocFMC4DM4rKbt for ; Sun, 05 Dec 2010 13:52:19 -0800 (PST) Received: by vws2 with SMTP id 2so1155784vws.2 for ; Sun, 05 Dec 2010 13:52:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:received:reply-to:message-id:date :subject:from:to:content-type; bh=xsVrjduy13Yo+k4KSE/HeK9dU/ReA+/JkQcKoVYMEeI=; b=lmeZQj/+AI6JZD4/9Sykv5yJGEQnNPgcSTc+xIhEQRI+D2bUYGyukRgvpQRZfRDo06 U0Ks694/vAZayjKnVGiw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:message-id:date:subject:from:to:content-type; b=Mw57Otzcemqmzwyq+Hm9hA4kc2u3WLMFsw1W9fOWuXvvNU+HN8IEIiGRfPWvlY/YYi 6WwaMiwSuHs2nUUMJOsw== MIME-Version: 1.0 Received: by 10.229.192.15 with SMTP id do15mt602883qcb.22.1291585939178; Sun, 05 Dec 2010 13:52:19 -0800 (PST) Reply-To: forest lin <247440785@qq.com> Message-ID: <001636283ab21a066a0496b0c9f3@google.com> Date: Sun, 05 Dec 2010 21:52:19 +0000 X-ASG-Orig-Subj: =?GB2312?B?uN/Qp86qxPrV0rW9xPrIq8fytcS/zbun0MXPog==?= Subject: =?GB2312?B?uN/Qp86qxPrV0rW9xPrIq8fytcS/zbun0MXPog==?= From: Picasa Web Albums To: xfs@oss.sgi.com Content-Type: multipart/mixed; boundary=001636283ab21a98ad0496b0c912 X-Barracuda-Connect: mail-vw0-f73.google.com[209.85.212.73] X-Barracuda-Start-Time: 1291585940 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4863 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.52 X-Barracuda-Spam-Status: No, SCORE=0.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=DKIM_SIGNED, DKIM_VERIFIED, MIME_BASE64_TEXT X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48576 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.52 MIME_BASE64_TEXT RAW: Message text disguised using base64 encoding X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --001636283ab21a98ad0496b0c912 Content-Type: text/plain; charset=GB2312; format=flowed; delsp=yes Content-Transfer-Encoding: base64 tci0/crHtv7I/cH3tcS/zbuno6zW97avssXT0NPF1sq/zbunDQrDv8Tqu6jU2kIyQsa9zKi1xMeu o6y+v76509DDu9PQusPQp7n7o78NCsO/zOy1yLT9o6zKx7K7yse4w7u7uPa3vbeoo6zP1tTa1/bN 4sOz06a4w9b3tq+ho8vRy/fS/cfmx7+087u5ysdCMkKjvw0Kz9bU2r/J0tTL0cv3tb3Iq8fyxL+x 6r/Nu6e1xNK7v+7I7bz+o6zKx7K7ysfSqrjEseSy38LUo6zW97avs/a796Gj0rvM7MvRy/fJzyAN Cs3yxL+x6r/Nu6ejrNXStb3Wsb3Tv827p0VNQUlMLrXnu7CjrLSr1eahow0KDQpRUToxMzY0NjU0 MDU0o6jR3cq+1ebKtdCnufujqQ0Ktee7sDogMTM3NSAxMTQ3IDE4NA0KwarPtcjLo7rB1tChveMN Cg== --001636283ab21a98ad0496b0c912 Content-Type: image/jpeg; name="=?GB2312?B?v827p7e0wKEyMzQuanBn?=" Content-Disposition: attachment; filename="=?GB2312?B?v827p7e0wKEyMzQuanBn?=" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsK CwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQU FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAARCACeARsDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD9SKKK K1MgooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKAPGfEXxw8SeHNd1Xw7L4S0q58TRQ6A2m2VvrsrR30uoTzwzKW+yB0W2FndT MyxyFoITIVjwyrp/Cj4s+JPiB4n1jSNV8HQeH00WF4tRuU1KW4CX32y5iS3jDW0e5Wt4IbvexRvL vLYiMrIHrTuvhLFrXxF8GeNdYuoJ9Z8P6dPBMLK3ktory7dFjjuCvmsdsKSagkcUhl2C/lIYHJaz 8P8AwJrPhLxT491TUtasdUtvEurJqlvbWumvbPZ7baG1Ebu08gl/dW0HIVPm8w4wyqn1darlLwk4 0qaVTlTTvUvz3UXFauLTinUvK1nLl6JGCU+bV6fL+vI7euRvPHstp8W9J8FHRp/Iv9DvNYXWGmjE W63uLWFoFjBLlsXSsWYKoGwKXJfy+uxXEat4E1nUPjF4c8Yw61YwaTpWk3ulyaTJprvPP9pkgkeR bgThUw1pb4BibgSgk71MfhYNUHOX1hq3LK17/FyvltbrzW307msr9DD+GXxovPHmpeH0vtAg0rT/ ABTocniTw/Pb6g1zLJYo1tuF3GYYxbzYvbYhI3nXPmjf8il9L4h/E288KeE7HxBpthpUelzQrc3O peMdWbw/ZWUTFFjWZpIZJUmdpVCxtCANrh2RgiPm/DL4LXvgPUvD732vQarp/hbQ5PDfh+C309ra WOxdrbcbuQzSC4mxZWwDxpAufNOz51CdLr+ieNrvTdIfRvFWlabrMEPl3zXmhtc6fdsVXdIsC3Mc sTBlOz/SGULI4YSHY6ezX/sxY2Lo8rp9U3UUbXl5Od+Xl12Ur6OO2a5+XXf5HNH4+WcvjD4e+HIf D+qw6h4phhubqHUUW1l0WKayvbmBbiMkkzOdPuIzGmQhikLsv7sS9L45+IcXhDw9qF9BYz3t5BqN lo8NvOkltFLd3c1vDb/vWQgw77qLfLGsm0CQBWdDHXn1x+yromnyfDObw5ql9pFx4Lu7CR3kubkp qkNtZvZjzoYJ4IjcNCUU3BRiVjWJleEmKvQfHPgi98c+HtQ0yfU4LV11Gy1PSpo7RiLaW1mt7mET qZP36/aIMsEMRMb7AVYeaarrJ/rGHdBv2enPe6fx6vS+jg9ErWSV7yvcXtLO+/8AwDyLxv8Atay+ BEutI1LRfDlh4zspryKey1fxZHp+lztb21lc+VbX00CmSZ01K0CpJFEuVuMuFjVpPouvGrX4HeJd K8QyeMdP8W6Unjy7mumvru50KWTS5Ip4bCFlitFu1ljYJpVnhmuHGTOduHQReleBfCFn8P8AwT4e 8L6dJPNp+iadb6ZbSXTBpXihiWNC5UAFiFGSABnPAqM0/st0KX1Gymvjtz6t9ubaKsuXeTu+a1lc hz3fNsbdFGKMV8ybBRRijFABRRijFABRRijFABRRijFABRRijFABRRijFABRRijFABRRijFABRRi jFABRRijFABRRijFABRRijFAD6yvFFtrd3oVzF4c1HT9K1ltvkXeqWD31vH8wLb4UmhZ8ruAxIuC QeQNp1ayvFFtrd3oVzF4c1HT9K1ltvkXeqWD31vH8wLb4UmhZ8ruAxIuCQeQNpko8B8Z/EL4peDv HWjeFpfib8MGv5rK61vV/tPhO6t/7H0aCJ9+ozbtZx5X2jyIACVJ813GVglxv+LtX8a/CvwD4t1P xv8AGPwRp2pX80R8M3mo6amgaba3aRbhZzPPc3BlgmaEl8ETKslwY3H7ryTTfBVj4H/aQ8BWtrLc X15deE/E13qGqXzK93qNy15oCtPOyqoLFURQqqqRokccapHGiKfEv4YX2lfAz4gfDvw+bjUYPF8N 3ofhnS4bVhbaBFdWPleVJLlhHaRSLcT5bAjjdbeBGK28LoZlfHf9ojxR4Y+GvxZm8M/D3xOmpeGN M1FF8Qw3mhT21jcR2hmiuJIWv2lChHhn8t4fMMbqTGdwU9V4n+M/i3TfD1re2nw1uNFvDNcy3y+N 9ZttNsdO06C382W+nvbP7bEi72jjWIkSNmR9ojikceV/tGfFLwF4j8A+LNPkvtH8EfEDxF4fu/CV 5YeONYTw9d29vcRSxpO0cxEV/Bb3EhxPE0kYQ3ptpJWLRTev6v40/wCFv6FaSfC+48AeP9G+2hLz V7vWftlvpd1C0M0EqQW8Ui3MsTFJvKM1uwKRYkUsHQA8B8B/tmfETxFruozP4K09bDUr28s9L0zU z4hgeO5sFuhdwwzp4e2Tb0sZJktzm4VxMjfMVgg9U+Lf7Qnjf4UeCtP8Q3ngPw/DI3hm41y90rU/ FE9vcRXVtbNc3dhDJFp81vNKkasUzKjSiOZlTZE7j5X8C/EG4nvPB3xa0b45fDC9+K/jO90uHUPD UdpNcXCjVZrG1ms2tBrGxfsqLZktFBFO40uISyHMpb69+IPhfxP4n0LS9L8aeItP0bw/of8AxUOv eL9Pt4tPt5ZLdpZbNIILiW4MH2aWO2vJJpnMZNtEmyaOedIQDyD4jfHz4sJ4I8e6jpHijwxok9pp njbUtLgXwlNczQ2+hX7WXzXL6iEM7l4HUm2aPO/chChX9+i8YzX/AMQ/Dnhiw8eeGNR8T6RC7eL/ AA5BNHHO1u9sGW7itd0k8DC4NrtDyGMQ3Mu4yP5LD5X1TwpNqPh7wlq3ijxBb6D8NNWh1zw/4h8S 2cscNjcrr1vqF7q13DPcRkRaf/aMelxWM77Gk+bPnxzwyS+v+JPi3b3HjX4MfFm30/7D4G1bwbqE 13rfiC8h06y0aC+udDmia7nZmRZWRHSOJCxkl2rlU8yWMAyvhN+0F4+8Zy/BRNY8MeINE8P+KL29 eLxPfjSpBrdr9hvLnTIpYYLhnglltY0uZpUjjVJ7byljEcxMfafFj9oax8HfE/TfD1pfXEiaJpmo eINctdOtVuJr8xJb29ro8O8BPtc82qWkqIkglyluhTbeI1fO9ofBv7Mfjrwn4z8Yan4g8PeDLLRv E+t+FfCGv+Jr2T7HHZRabY6fBa217chTczWk2oTJbuqSR/2g0DKDACvr3x98Aza18Z/Avh3wlpNv pmral4T8YpZ65aCO3Ph64u7nShcashBD+eBcTkeV+8klnCs8aSSzIAW/hx+0b42gl+G/gbxT8NfE F/45ufI0zxPqEep6I6Wk8dik13eNDbXjusQeW2Yho4gEu4tuXkhhl1bn456nqvxL8S6d4V1HT9Ut BrNp4L0q1uQr2o1y2srzVdSE00RLxxPai3tRJ+9aG4icm3YIwlyvAX9t+IfGfjHx54N/tC5sJvH9 t5ljNvs4tT0yXRtJsr3ck+0JLaXELytlPOWTT7i1HltLMtc/pOk2Og/HSz0zTLO307TbL4vpbWtn aRLFDBEnw7CpGiKAFVVAAUAAAACgD0rVfiV8UrH436b4PTwj4QOjaho2t6nZ3DeI7o3E/wBkks47 cyD7Dtg3tdxq6DzsB2ZXJhCT8B8Of2ivilr/APwmeozeD/D+vwjGp6Pouk69dS3QtZfNsdPEDjS0 intry80+4nW7eULHb3QlfbGi57/xJq9xqv7TOkJoFp/aGq+HvBuvQ3EF6JrW3Se5uNHks1kn8p9s U3kXCrKiyAm2uVUM8EqL87aH4Lvvh7+1Dr0fhr4afCjwd48HhPTn0HQNE0xtSBllk1eE3/2tYrI2 MEbeWLt/JkMkQhiRjNLDGwB798H/ANoE6npWl6T4s0/WLKex8JxeINQ8aatNo66bd26qim9drG+u EtlnPnSx7tsbLDPsZhC2PNviD+1frfh34W+MvENn/aE/9veGda8UeGL3S9LfUP7BtY4IotGe5SKB 9kV95d1fLLdiNYtssD7vJYr6p8Gk0zw/p1p8EdesPt2p+DLK1msBNYtcWs+kwXGzSbxp9piW5xbI GVvLf7RaXEkUflKjnwGb4V36f8E8LzxFp3jzxBolpe/CeC+vNCsLHSRZ3bx+H4oiJZHsWuW3xwor MZt4UAIyBUCgH1lZ/EC68Z+Db/VvBOjXF3qUMwghsfF9pqHh1ZGBQuSZ7NpQoRyQ6wurMu3IwxX5 i8M/tmfETXfGqX8fgrTz4M1yy0W20O8uz4httLkvLm5njDpfP4eGfO86xX95siH7oo7mSQJ7n4kn 8SfAzwbqWv3Xjq38YwCaBZ7n4l6zYaBY6dESy7lubLTACzyPCm2RSDxtZTw/xH4N/ZC+I3gv4aeC PFdt4A8Py6j4avdI1Mx5sIdRuYbK9gkeby4vDaX6+bFC0vlm5a7CvteOabdA4B9j/E74i/Ejwb8G PDthPodvdfF7xTMdAtl8Hzwz2lreG2uJ5L2L7eYFZY4LaadYJSNzqkJchjNWVb/tH658RdV8P3Hg PwT4n1Sx0fU9StvF+l2p0r7XZ3Fu09pHp0zTXaQBmlBui0E7yIlvb7k8u8RqwPjT4jl8W6B8FtX8 cWf2TSrzxk09vJ8Mdb1TV5bm1fw/qjQzQT2NtBdHczciFWXyxksUZgD4IzeDfDfwj8J+MNRvPEGm W2jeMvFcWnXElrezX1zHPqupxrZXgkje6bzWEDeVLiSW7htFO+by0YA6rTP2gNT+IHw0+G3iKDSt Q+H8fiT+w9T1C/v4lu4LOC7vYYoLOJ0VluJbxmEKldhghnM83kOIopfK/FH7SPxP1VrmLRfEWn6F MfH6+GLaJvhjrFzbpAviIacDJqrXIs33RLl9oQks0SNHJtZeq8P/AA41PwTY/sgW+vXGoWus6L9l 0K40X7WrWdrPH4X1QXDbY/lllLRom9mcKsX7rYJJTL4tofw88C22v+PviJr3h/ytGsfE2sDxP4kg 8IzvqOki18Qa1PHd2V4Idz+askEM11ZmSe0W0iGIywuLIA+iP2gv2j9c+E3jfRbS38E+J7rQ9Jh1 DxLrt9YnSmhv9EtLBhcmAS3ayhobq808lSkbsI5Nm9chtWx1v4wL8W9M8JnxZ4I1mC0hg1XxD5Hh C8smtbCV5khWKRtUkDTzyW8yqNjKixSvIQRFHPyvxvt4fixqt++jQaxrGky+E7jQfEgg0qT7XoWn ai1tLcC3hYxytqElusbtaSRyyRJFDKI1cpa6lV8Dfs8/BnxP8fPiGLX4TeEJvD+m6NpGniGfwpbx QW+pJdaqbpAjwgLKYmsZCQPnhktZAWjkiYgG/wDF342+LvDXxnv/AAjo2oW+labZ+H9P1XzV+Hms +KZpZbi5vonVjp86CBVW0jKiQZcu+D8pA4v9nL9oP4j/ABh+I3w1/tXXdPj0bW/Bt74h1LSIvAOp aQnmA6cI0gvLu4ZbnY122JoMxlA25CZYnj7+38G6v8UPjf488V+HvHXiDwZo1nZad4V8/Q4NPlGp XVnJeT3Dhrq0uFaKJr8W+YyjCeC7jdcxKT5X+x3pl2Nd+Cch8U+IPEsdh8J2W5stTsbeG30X7Suh y20cLxWsTPFKsU6o8jzbjZTKHLwzgAH2lRRRTEFFFFABRRRQAUUUUAFFFc/4+0aHXvBurWc9trF6 hhMotdA1OTTb6dkIdY4biOaExszKFyZUU5wzBS1AFvw14o0zxfp01/pFz9rtIb27095PLZMT21xJ bTphgD8ssMi56HbkEggnVr8+NO8KDwr4b8AaT4Z8Z+J7p5tM0WLx3PZ+K9YRW1LUfFGk28sipPMk ltPNLb+IEkEaRSxt5yzLGzqp9++DGmaH8G9f+PuoK/ifULG28WWUDo1zqviK7K/2LpTKViLTzO2+ 4bc6qW2KgY+XCgRDO1/4av8Agj/0WPwB/wCFRY//AB2u08A+PvD3xS8G6T4r8Katb654e1WET2l9 bE7ZFyQQQQCrKwKsjAMrKysAQQPy68J+JIvBfjr4Y+EbnSPEF5rOj+Gb7w49vbeMPH1lLc3kcWlz MsMK6UJrb9wnnG1gjaIRyI0hQRwb/qgrotz+y18L/BWq6J/a13oNlZabOvij4P6/4hszPZ2McUsk doYbeWPJlHlzuAGXzVAJD7AD374j/tAfDX4QXlvZ+NfHfh/wzf3HkGKy1HUI4rh0lm8lJRETv8rf kNJjYgR2ZlVGI7+vz4+D/ivxH4KvviXovg/W7fwVpq+LLW7+zaF8AvEJhyNN0xpEW2SbFosqoUeJ x5pDvMjp50RX1/4ypcfHbTvh1qWneFfCF/d6x5a2PhD4pfDya91jT0NxGup3T+Zdwi3igiKM2U2S PHCiSubmAEA+k7nxRplp4p07w5Lc7NZ1CyudQtrby2PmQW7wRzPuA2ja11AMEgnfwCA2NWvgP4r6 br8/haPxb4U+KmoQ2mm/BrxBrVifBWi2mj6dplm6ae+nQwwSRTXNpFcx20jDfP5u6ykMDwiN0X37 4w3T2dnHB4h8HfE/XtK8NWRkm8X6J4xsfD9vdIIUaa4uPJ1Wxzt2EsZIURCJCgVDkgHtPhPxRpnj jwto3iPRLn7bo2sWUOoWNz5bR+dBKgkjfa4DLlWBwwBGeQDRc+KNMtPFOneHJbnZrOoWVzqFtbeW x8yC3eCOZ9wG0bWuoBgkE7+AQGx8W/s6aPd+DPBXw71bTPgn8T9d8e+FtGsNFvhf+Ordbex862tG vIvsVxrBEGYjFOlrJbxcpbZWHCulT9ovw3Z+I/i3rdl4e03xuXv/AAN40027v9au/EE9sLu4ewtR 9i08LPJcQJLcwlhBbi18uVJY3ka0CxgH2l4Q8feHvH0eoyeHdWt9ZgsJooJri0JeEtLawXcZSTG2 RWguoJA6FlIkHOQQLfizxRpngfwtrPiPW7n7Fo2j2U2oX1z5bSeTBEhkkfagLNhVJwoJOOATXwH8 A/EOsfFX9pzwTrmqWXkbtZu/FGn6vcWGos+t2TeF7LTpLmGaTQ7WPyjKtu7OJbaMvJt8iT/RXPK/ tTaN4Ktfivb6R8TNd0/VfEHiT7S3iWTRU8ELcaZ5sEjWmnRT6jFBexeVbiPGoTsu4RQBFElyotwL H6YR6tYzarcaZHeW76lbQxXM1msqmaKKRpFjkZM5VXaGUKxGCY3AztOLdfG/7FHgbwjB4+13XfCP inwRrD6Xph0rWbPwpb6NcGO5nlSeJkvLHSbB2gEMK8/vEklklTCNZkyfSfjXVviLYarFH4R8LeGN c00whpLjWvEtzpsyy7myojj0+4BXaFO7eCSSNowCQR2tcV41+Nvw6+G2qxaZ4u8feGPC2pSwi5js 9a1m2s5niLMokCSOpKlkYbsYypHY1yura98e5tKvI9M8C/Di01J4XW1uLvxpfzwxSlTsZ410lC6h sEqHQkAgMucg8fan8TfDHh7VvFl34z8EeEfD2maYdS1C1ufC19rLWKxW4e5xcR31ubhVZZCpFvGx XaNmerGavhv9pb4T+M/GWm+FPDvxH8MeIPEOowzz2tjpOqw3bSLCFMgzGzAMFfcEJDMqSMoIjcr6 VXyZ+zzoPxru/gx4e8IweOvDHgzWPBUOm6BqmlXfguS8u7KW2trWb7O9wmrNBOstu8JMsQUlJzgQ ygrH0HjT/haWsftS+Erew/4RDwj5PhnxJ/Z+oXP2rXvtlr9u0YHzrYfYfs8v+pYbZpl5decBigPf vCfijTPHHhbRvEeiXP23RtYsodQsbny2j86CVBJG+1wGXKsDhgCM8gGql74+8PaZquu6ffatb2E+ haZDrOpvdkww2lnK1wqTvKwCBc2lxn5vlEZLYBBPyv8AsbJfW1z8G7WHxT4n1+CP4WpJqtjqJaKx 08yR6PJpyRwxxRQsuxtRWK4KvLJ5VzG00ht2WLyv4nx2el+KPibrHhtfG+g6PZ+H/CWoQ654vvfE F3cxNaa3eXzzm0ntr+WCAJYXCie7t1WGSLKxPFds7gH35YePvD2o+GdS8RR6tbw6Hps19Be6hdk2 8Ns1nPLBdF2kChVjkglBc/LhCwJXBPF/8NX/AAR/6LH4A/8ACosf/jtfMP7KerXU3x613xX4v063 8DvoPh/xNcajFqVnqFq0Vnf+IpNQguZZ7zSrUJAFS62eZcPlUZ1hgYXIHtPjvxrffFDxv8J7exit z8LtV8WJGLmVW87XZbWwvdStrm3YMPLtI7mwt3STk3RXK4twrXYB2unftV/BnVrzV7ez+KnhC5/s myh1C+uI9atzbwQSzGFHabf5f+t2oQGypli3AebHu1fC/wC0H8LfHGu22ieHPiV4Q8QazdbvI07S 9etbm4m2qXbZGkhZsKrMcDgKT0FVNN+Ierf2V4u0HV/s9h468N6Yt7NPY6bcX9pcwyrOLW+gtYn8 51ke2nBtA/nK8MkatIpinl+Lbnx34uvvhd8eNBvvFNxf2Nh4f8QW2pvN8LdZ02fxBcyaBDc/b729 uJGSynQnyUgYInkqiRxrG9qIgD9B9G8UaZ4g1HXbCwufPu9DvV0/UI/LZfIna3huQmSAG/dXMLZX I+fGcggcVeftLfCew8ZWHhKT4j+GG8T3upnRotIh1WGW5W8Af9xJGrExNujZPn25kKx/fdVNX4Of 8lE+Ov8A2OVt/wCo9o1eV+Dv+aRf9ll8af8Au00AfVFZWjeKNM8QajrthYXPn3eh3q6fqEflsvkT tbw3ITJADfurmFsrkfPjOQQMrxzqPjfT/sX/AAhvh7w/r2/f9q/t3Xp9M8rG3Z5flWdz5mcvnOzb hcbsnb4X8KNe+MCePPjM1p4F8ETzv4st2u0m8aXkawy/2FpICxsNJYyL5YjbcQh3My7SFDuwPp6s rw14o0zxfp01/pFz9rtIb27095PLZMT21xJbTphgD8ssMi56HbkEggngLbSfil4x0LRNG8Wnw/4a jmslPiHUvCWrXT3E8wZle3s98EbW0UqiNjceY00YaSOMB9l2nK/DXRdbv/Dt54n8AR+H/C1/bazq 2h3Ph37G8ej6la6ZqFxYWY2xvm0uRb2cEP2pFkUJw8EyxW6QoR79RVTSZL6bSrOTU7e3tNSeFGur e0naeGKUqN6pIyIXUNkBiiEgAlVzgW6YBRRRQAVleKLbW7vQrmLw5qOn6VrLbfIu9UsHvreP5gW3 wpNCz5XcBiRcEg8gbTq1leKNZu/D+hXN/YaFqHiW7h27NL0t7dLifLBTsNxLFENoJY7pF4U4ycAg Hmus/syeHte0W50271/xOU1CazvdXuIdUMU+qXlteQXcV5JIigwzhrcRb7bydsLLGoVbe1EGr4a+ Blj4G8PeLNM8L+KPE+iz+ItTTVZdWm1BdUvraVbe2tysct+lwXUx2iDEwkI3sFKgIE+d9Q/bK8VN 8OfE8sfhDxfpU3iSyi1PwH4jvLTTJzFZ6kLeCxmmtre4kkuPIvrtEaO3t5pUgez82N5Jcye0j9p3 SNf8LePdT8N6VqEVz4PvbWzvP+Ey07UNBsx5yQSmV5XtJJIoo4p97s8P7tU8yQRwukxQzV1H9nXw xqGseHm8ny9B0nRtT0v+zt0pnlmu7ywu/tv2vzPOW5Sax83z8mZppfN8wSLubtPBXhrUfC2lS2mp +LNY8YzvMZVvtais45o1KqBGBaW8CbQVJyULZY5YjAHzFZftY+N774x+JtCtl+GEtt4esnt9Y01v Hc7xWNzCHmmuDMmk+ZbxQxDy7iWdfs/mPbRRypMk8b+k+J/il4x0n9nu11PW4rfw14wvfD9zqGo6 /pljdy6Z4fhih3zai8d1brLujRlkSwkjMzyHyj8kc1xGAd/8Mfh1N8P4/EU97rlx4i1bXtTGpXuo XEEcBkZLW3s4vkjAUN5FpAZCoCtKZWRIkZYkq+Of2f8A4a/E7xTZeI/GHgTw/wCKdZsrJ9PgudY0 +O62wM6yFCsgKthlypIJTfJtKiR93zt+0H+0t8QfCp+OFt4f1q30NPB0MkWnGH4c6vrLM39j216J JNRim+x27CS4YYmjKxqivIrKefdPiX461Pwx/wAK28Ixa9p8Xj3xTrNnbJJDCsMVxBa4vNVdYJHl dImtbeeJcGQpJc26l13eaADnx+yrpNt8JNY8FaZqNv4ffxDDJZa7daLpNvbQXFnMkyTWdtb4ItIE W6neBI2PlzHzZTctJc/aeq+Mnwh1H4s3PhL7J451jwhZ6Jqf9pXNrplpZ3C37LG3kb1uoZUDQzeX MhKsoZN2zzFhlh8hs/j58SviRoXgudP+EQ+EFh4j8Mt47h8RXV9JryQ6batYyT211DJFZJBvS+jD yiZ9qJMF2sUlT6ooA8g0P4Ea5oXxP0fxo3xW8T63PBC9jqVjq1jpSw6lZlJDFE5tbO3bdFO6yxyM X2AzooAuJCbfjH4WeL9S+I0HjLw7410+wv7Oyn0+xtNc0I39vbQXJtmukAhuLZ23PY2joWclC10C ZFkiW39UopiPIPCXwH1H4deIRrHhrxrcTXN/Mp15de0iznXUo/tEs8jp9ljtTbzlppNpQm3DSzyt byTzyzNb8e/BbU/iJ4W8W6PqPjbUIV8TebYXiW1uv2WPSXSaA2kMDlhHL5U7ubkHe1wEZ91vGloP VKKAOV07wN/ZHxG1fxRa3uY9Zsobe/tLiLzX8yAkQNDMW3RRBZJt0GGjLv5iCJ3uGuOqoooAK4rU /AV94n8ZJf8AiLVrfUfDWnzRXek+H4LJoVS5QKRPeSGVxdNHIu+FQkSRsQ7LJLHDLF2tFAHAfEf4 W3fi68t9X8NeK9Q8AeKF8i2uNb0q2t7h7uwWbe9rLFcRyRPw0vlSMpaF5HK/LJNHKfEL4e63rvin QfFXhXXtP0LxJpNle6Yr6xpb6jZyWt09tJMDDHcW7iUPZW+1/M2hfMBRiysnf0UAeF3nwW+IutaL 4e8O6h4z8EWfhTSNT0i+XTdA8EXNiyxafeW91Fbws2qSJEpNsif6tgqngcCtW9+EHjWHx9rviTRv iHb2L63DDpt1JeaAlxd29hDLcTQJbSLMkSTxvfXgWWWGZSgtQ8TtFK9x6/RQM8r+GnwTu/hBqMFv 4a8Tb/Cs21tR0jVNKt2leRLdYY5Lae3EHk52JuSRJo0jjiht0too0QdV4y8Df8Jb4i8C6r9t+yf8 IvrMmr+V5W/7Tv0+8s/LzuGzH2zfuw3+r24+bI6qigRz/j7QtZ8TeDdW0zw74luPB2uXEJWy1y2t ILtrSUEFWMMyski5GGUgEqWCsjYZeA8KfsyeHtD1rxBrGt6/4n8calr8zy6mNf1QrY3ivZx2Rjm0 61WCxlXyIlXMluzHqWO1dvr9FAHlejfCTxP4Z0fXY9J8d7de8Rayuoavr15o8Us7QrZw2S/Z41dI YrnybW2YyukkJmErfZxG6wx2vEXwZhTwl4E0nwZeW/hmfwLNFL4e+3W0moWkKpZTWAjnj86OWVRb 3MoBEytvEbFmAZX9KooA4D4S/D3W/A8vjG/8R69p/iDWfE2srq882l6W+nW8O2xtLNY0ie4nb7tm rFjJyXPAArV8G+Bv+ES8ReOtV+2/a/8AhKNZj1fyvK2fZtmn2dn5edx35+x792F/1m3Hy5PVUUAF cr8NfA3/AArzw7eaV9t/tD7RrOrav5vleVt+26hcXnl43HOz7Rs3Z+bZuwucDqqKACiiigAooooA K5X4o/8ACMHwLqa+Mvn8Nt5SXVt+9b7XmVAlt5UXz3HnOUi+zAN5/meUUkEhRuqooA+N/FmmTNJd +FPFz6xqfiu90y01fwPpMVzH4h1fwvd2l1cnTrm4t9wHniS4jR7+SX7LIIfs11cHy/tN93/h/TfF Nx8PPFPhjSYLf/hY114guNR8TW15rsukTrbXVzLJCYL6O1uJZoDbxxWUNyiRP5MDKrWk9sYYfStU /aA+Gvh/Tre/1vx34f8ADtpcXt9p8Emu6hHp/nz2dw1tdpGJyhfy5UKkrkfdIJDKSaB8fPh74r8C 6j4z0TxZp+seFdNvZLC+1awYzwWskcojkaVkB2RLuEjStiMQkTFvKPmUhnyZpPwh+Lc/x48U6LHB o6aJa6ZpGpTeEV8VW6aRJYS/2lZx6U3/ABTheTT1hglRbMhVjLvMHeaYvH6p8SPB3im3+E3g0+ML q4srnQ/HPh1bSwsPEkuqQ3MT6/pywtdXD2ltLO0KNLEqyBww2yytNOEkj9+ufH3h610rQdUbVreX Sddmgg07Urcma0nadc2585AUVZTtWN2YK7yRIpLyIrVdf+K/gjwp4W07xNrfjHw/o/hvUvL+w6xf 6pBBZ3XmIZI/Kmdgj7kUuu0nKgkcCgD438efCbw94+/aO+LesXPhK38Qalpmp/ZNRlufBh1dodOn 0nw8xurWSWF7ee7tvJn8u0JeQLdzSpDPt+zXPtN3qfhLxdqX7OPi3wklxdabqfiDyLXV9StrlL69 s4fD+ufZzLJdKLiVf3kro8ud3nNIC3mbm6Cx/bU+A2o3kVtF8XfCCSS/atrT6tFCg+zzLDJl3IVc swMeSPNTMke9AWHtNAH58fCL4OeAv+Ee+FV3q3wM0eLUvD3hO1j8Q6TrfhRF1PWoXt449RvobGS3 V7iezvILUFi7TGO4u9sDfabJ7n7S+CXiOx8Y/BjwDr+maLb+G9N1Xw/YX1ro1pt8mwilto3S3Taq jbGrBBhVGFGAOldBrPijTPD+o6FYX9z5F3rl62n6fH5bN586281yUyAQv7q2mbLYHyYzkgGp4n8f eHvBVzaxa/q1voqXUNzPHdX5MNttgj82YNOwEassQeXYzBjHFM4BWKQqAdBRXkGp/tg/AzSbZJ5/ jB4IdHmigAttftZ23SSLGpKxuxChnBZyNqKGZiqqzD1+mIKKKKACiiigAooooAKKKKACiiigAooo oAKKKKACiiigAooooAKKKKACiiigAooooAK5X4o8+BdTT/ioG8zyovI8L/LqNxulRfIik48nzM+W 0+6PyldpPOg2eanVUUAfAfjLxf4yh0n9nLxL4Su/7Hu9c8M3z21npc1lpiadYapq2gRWNghk028i aK1F7ZwllgjZ0tzJlSTE/qnwo8W3fw0/Z60DU9f8deH/AA258ZXd0+v+ItTt4tJ8RWt5qVxdzmG4 aCAy5t7id4ZI4bZZZrVZEVrRgZe0079l5bbSvhPplx4suH03wV4Tl8JX9nFplq8PiC2kXT1ljuEu EmCQSLYYeNBvIlwJV2nfq6l8CtZ1b4a/E3wTqHxE1jWdJ8U6ZcaPo66tbQTtoNtLaNBt81Qk14wd 2YyTys7Ksali4klkQz44+KOn6Fr3xS0m88ceBtQ0q0n8G6XHpOlaNoHhpYtFsvP8QXlvb3ia6jLZ yx6fZ5lEJWNZLeZScCEH16ZZvBP/AATd8JR+HbXWNHTSPD+n3Wp3vhBI42t1tNtzqNwCt7ZGeCdr edTNa3G6dbnzYmkVw5908UfA3/hL/ilqniLUNb/4pvVNGsNNvdChtNk8s1nPezW063gffDse+Mqm FUmSa2t3SZQrI4/wz8dL8Ob/AMOXHxA0/wAYX9/e3P2q+8beF4Ly3l02QOi2RtbOS0RsIUDSOW3n zfkCuqRgH53H4MfErRYrWXxPoPiC5sB9t0HxBYR6tJeJb6lrl9YyiwZI/FyO8Uj3KAu5h3o8UtxH Mz+bF79+3J4c1vxF4W0T/hJvC3hDxR4ksPhP4vvtT+0yulnp10iaR515p/mQTO0sblvKVvLYq3Mq Hr9EeLf2crHW/BpsdK8SaxpHiuKZtSh8UTSLdtPqmYmS9vbNwLW8ZGgh2LJFiBY0W2+zeXEY9X4s fs7eAvjjqum3fjrQrfxJBYaZqGlw2N7Gjwot41uZJkO3fHOotVCSxurIJJMHJBUC54t8V/hnper/ ALQXgTTL638b2SXPiz7WmpweNdaFlcxXGh63IyW4FwiWs8c1q4aK3ACQyQgOFneJbfxX/wCLfa78 cdb0fnWfBvwn0vUdC1HUf9PuLO6gXxIkc4kuPMZ5drOrO5ZnDuGLB2z7n4l+HU3if4h+E/EVzrlw um+HpnvrfR1gj2m8Ntc2qyiXG8KYb2cPGd2Wjt2Qx7JROS/DCxv/AB94t1/Uzb6rpviPw/YeH7rR ru1WSForeW/d9+4kSLIt+UKFcARnJbdgAHzFqPijxtd33iXw54rufF72mn6z8OtQs7bxrHogvI3u PFDRyujaSPKMTC1iADkuGR+ACM/aVeQX/wCzF4OtZNNg8I6Vo/gLSRqdjqWraf4d0S0tRqjWV1Fe Wm90jVlaOeBQDllMU1yuze8csPr9ABRRRTEFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQB5V8Pfiu+qXD21y2q6/ZSXIt49ah8NXtmsV0ZGSS2kieLKokiSASgssarsn ZXVZLjzGX9oHxno3hrVda1yKXSbODxNZ2EVnqFlZWV5HDcXUd0sLyy3uwsunyKjgwoyNKCX/AHUs i9H8MPhH478DeLLa9uYrSTS1ubuU2yeN9UnRftN1LK8jwSwGOZ445FVQdm5xJI7M7qYr0/7O/wDY +v8Ain/hGbDwpYaJ4mtpbO5ifSvJaygeC3ikiAhKPOjmBiFSa2EbTSORM20Lz++0fLSWOq0YtXUl dO11utHrq7PTfTd6bYeu/HPxLoXw0smvb7SrS9vbm5sE8S23m3AiiCKbe9SKeC1hnR2kihNyHjtR LNC+djmNOjsPi54pudWuNci07RL/AMGte6RogFtrDNLHcTyxpLcxD7LmSJjeQhPMaPfHAsqDZOpN hPhD4gg0O/02+uNK8U2EGtXGp2Gn3qm0+1LMqb1uZ1jkKbpJr95FjjKy+aE/dQM9vV64+F2sOnh/ Tme01DyLbRI9U8UXl9N9uum065+0oPspRkPmPvy5mDDz2JD7FDNKZrGGNTu5PRL70mvNNN9d+raX KdHb/FDQ/FUN1beCNf8ADXirXYoxMunx62gXYHVWd2iWVlUbuuwjJUcZyNXwJ4n/AOE18D+HvEX2 b7F/a+nW9/8AZvM8zyvNiV9m7A3Y3YzgZx0FX9bh1O40uaPR7u0sdRO3yri+tWuYU+Ybt0ayRlsr kDDjBIPOMHC+F/hPU/AngfSfDupapaav/ZdtFZW1za2LWmYIokRA6tLJuf5SSwKg5GFGOdNbnsx9 sqqUtY2d7WSvdW6t9/I6uoL+4ks7G4nitZb6WKNnS1gKCSYgZCKXZVDHoNzAZPJA5qeoL9LmSxuE spore8aNhBLPEZY0fHysyBlLKDglQykjjI61R1PbQ8/sPinqfiLQ/BUuh6FaT6x4l0X+3FtNQ1Fr e3t4FW3MimZIZGZw13EAPLAIDklSArdV4W8YWXi7Q9A1Sziu44Na05NTtxNA3yRMsbBZHXKK+JV+ Xdk4YruCsRx2ifCnXPDXh3wXDpviPTxrvhrSpNES9utJeS1ntW8jrAtyrLKPssHzeaV/1nyfMuzs fC3hj/hDtD0DQ7C536PpOnJYKtzHuuJPLWNInMgKqMKj7hs+YspBUKQ0Lm6nn0Hiea9Xay7b2V9v Pmv02scdH8UvEd3q2paNZ+FNPvNdgjinTT4ddVmtEeWFduossJFrL5U3mqiecJBDMEZtql9zwB45 v/FHhJNb1fSYtMWe9a2tU0y4l1BLiHzvJjuFYQIfKkP7xXClfKZZCwUnaaD4K1a38VW+ta7r0Wsy 2FlPp9gYbD7NJ5MzwvI1yRIyyyn7ND80aQqD5nyYZQl7wj4WufBvgLw54ctL+KaXSLKzsWu5rYlZ khVEkIQONrOitj5iFLAkOBgi5r6ipRxPPzTbtZ6Pl8rbdd+ttOhysfxeub34qal4NtIfDSS2N7Fa tFf+IjBqU6NbQ3EksNmLdt6qkrAfvACYmyVHIveBPihc+Lr7R0utHi0+z1/Sn1vRpYbwzyPaqYM/ aUMaCGXF1AdqNKufMG/5VL3vE3grVvE2rQxz69EPDYvbTUH09rDN0s1vLHNGsVwJAqxGSGNmV4pG O6QB1DJ5dHwJ8L7nwjfaO91rEWoWegaU+iaNFDZmCRLVjBn7S5kcTS4tYBuRYlz5h2fMoRe9chLF qru3G7/lWl1p3slez3b3SPQKKKK1PVCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAoorN8Ra2nhvRLzU5LS9v1tk3i1062a4uJT0Coi8kkkDsB1JABImUlCLlLZD3Pl3TP2qv GV1F4TkvYtBsI9cS6lZ3to1ESRM6KymTUUyGZGXMvlcqQnmEV67+z94v8UeMbTxjN4mvI55LDX7n ToLcWiQPbiMKShKSOpA3AAZYjDZkkBBHgug+GNMs/FV3p93bad8LdLf+zp7zRNS8Q31smq6dcQSe ekjO6NLLE3ygKERWMiPv7+l/Arxrpfhnw1rDaF4L1aLwncpLremTaZZ3FxJPiX7M1tIrSS/6SGiB Gx9jIQ7CLDV+dZVicQsRB4qs2lzdZdEk3ay0vreSVm7WejOycVb3Ucjpn7VXjK6i8JyXsWg2EeuJ dSs720aiJImdFZTJqKZDMjLmXyuVITzCK9d/Z+8X+KPGNp4xm8TXkc8lhr9zp0FuLRIHtxGFJQlJ HUgbgAMsRhsySAgjwXQfDGmWfiq70+7ttO+Fulv/AGdPeaJqXiG+tk1XTriCTz0kZ3RpZYm+UBQi KxkR9/f0v4GeJItP8KeIYPB3hWTTdFvLW613RL+S2upYGdWNv5FyBJMxmDwg7YWbfHyERvlJlWJx P1iDxNZyS5tLy1skm+Wy0vr71rN2s9GE4xt7qPoaiuW+GGseIfEHgPSdR8VabHpGvXKNJcWUSFBE C7eX8rMxUlNhKk5BJBAIwLnjm+0bTPCmo3fiC/k0zR4EElxdQ3Uts6AMCNrxMr5JwAqnLZ24OcH7 9VoyoqutE1fXS2l9e3n2OS2tjxzxh8fNc0L4oeKfDaXGi2FjpX2XyJLuODzZfNgWRsmfULYHBP8A AG4Izjjd0fwX+I+q3/wBTxt4svP7VmigvL2V7a2SKUwwvINuAQjNiNsEBBgqCMgsfF/ESeNvD9tp k+oSeK9C0/VvEcV3Bq9/rd48OnaTJKYxa3yC4XyWXdC+S4Zg7L5ishFd0mjeGbDwX8UL3T/F+i+J dcvvDl0ZzpeoXMsrRpA675Vlvbjftyiq2AVBIzhsV8NhsZiniZ1ZSdkpO0na3N70bRe9kuVaap3u tjpcY2SKenftA+Jj4futIm07UZvH3iaBtU8M2ixWzQw2s7hbdFlQtu8pA8xaZE4RgxHBPpfwu+JW qeJPEut+E9W0W9ttQ8O2tmLvU7qS3BuZZIgxLxROyxlsMwCM64ByUOFPhnw30DQPFHim10q7h1ab Tbn4XxJerdQ3M0qyedGS1skysSFIDR+SpTcBsBNd/wDCB7mS8+KHi3w5Nc6tpN3Y2EGi6vq0M0ja hNaWbRu7oqiaT95gMVTLNuC5IIDy7F4qVSlKdVyV2mrp3ioybbVv5uVcystVGy6k4xs7I+gKzfEW o2elaJeXN/q0ehWoTY2oyyxxi3LfKrbpAUB3EY3AgnAIPSsj4Yax4h8QeA9J1HxVpseka9co0lxZ RIUEQLt5fyszFSU2EqTkEkEAjA6mvuYT9vSU46cyurrVXXVaP5HLazsfK/jL9onxZ4Kg8L2013pP iBrPThq+r6loE2+HUk+1PbJEknkOkQ3BWkYquWyiNGdobv8Awt8XP7a+IHxOsNT1u50TQNOgsDYX N/Y/YfsHmRbZGZp4gFYyMhRZs7v4VZQa+TPE3hK+0/wjYaTNZXs/iOxdtElKLHeWaObkzJYwPFAc XZaVpGAlOEDJuJcxJ9Rfs7wWz/Ez4s3mmXGraho8l1YwQ3uriczGWOOTzYGaYByYiwTDfMFCZzkE /m2WY/G4nGQozm0m1o27r93O63TaTSv/AHrPd69s4RjG9v6ujkfGX7RPizwVB4XtprvSfEDWenDV 9X1LQJt8OpJ9qe2SJJPIdIhuCtIxVctlEaM7Q3pfgD4rya98UPiTZX95c2+gaRBZXNmNQ097NbSM wFp2laSNGTLYYCU5KglflBI+QPE3hK+0/wAI2GkzWV7P4jsXbRJSix3lmjm5MyWMDxQHF2WlaRgJ ThAybiXMSfS3wN0DRvEXjz4vL5N74h8M3N1YQK/iOGWYySxI5kgf7Qu5jC5VcOCygJnPBJlmYY7E YyFKU3a60be/s53T62ulzX2lZ7vUnCKjf+t0c7B+0Tr/AIs8S3Fx4a1GS803+3xJ/Z0MNsottFtI lN1PLLNsMYuDKpUybdpjZQ4PB9R8LfH2HxIvjO+/4Ry9g8P+HLX7UdUhura5S5KxebJEpikZPMA6 BHcf3zGSAfn+6gvLBfi5rs1xJo/h+21jxBZXE9uJJDqtzcRGK3t5kjHyxxMxcSSnaHnCrgsxr0bS PD3izwh8IvFVhqEd7P4Zu/Ai3cRv5/n0y9Wy8ue0COxkw2PMx8qR4Kqoya6MDjcdztynJ/E3pdbS to7uMXK/3JJcuopRjbYh079oHxMfD91pE2najN4+8TQNqnhm0WK2aGG1ncLbosqFt3lIHmLTInCM GI4J7rwh8XLi/ufE/hzxLFc+GpvDljZx3viW/uLOLM00QxI0YZ4omZjuRQZE7NtOFPjvw30DQPFH im10q7h1abTbn4XxJerdQ3M0qyedGS1skysSFIDR+SpTcBsBNeo/s+QJqXi7x54k0y4vdU8M6iml 2mnazfhhLfm2tjFM7bwrMQ/BcqAW3Y6HHRl2IxdWpSTq3TbW6eijJttWv8XL7ya6RVt3M1FJ6Gbq Pxf8U+GfDGkC61/w5qWqT6Hf30V9ZWDXljqc1mJHkRJ47mMo3lqhbMQQNv2k8INf4I/EzVfGr69r eseIbafRbaxtJ50TTEtrGyme3WWRIrrz3L+WCRKJACrFcbRkHyn4XWc3iP8AZm1hp9L1ay0/SNA1 JYtSGs3NtDdz77iXalrGwSWNQ4DSP1bKbWCnHt3wk+H2h3fwr8LvewXOqw32h2Xn2WqX095aNmON +LeV2iXDKCNqjbjAwOK1y6pi8VVo1Iz91wUrNz7Ws+/va3tZq3XVqajFNHmfhz46eI/iNpVxoXhf XrL/AIS7X9Ru73SZL0wxDSNMjk+SOdfLYSTMI3AjUSNsfzGYAA17H8L/AIw6D8UdP/0K6toNag3r eaSLqOaWBkIV2VlOJYssu2VMqwYdDkD5/wD2e/8AipJ/gtFpn+mt4ag1q41gxfdsluHkSAO3QM5B IQHdtG7G3mvUf2Zbm7sv2aNDuLCy/tG+igvpLez80RefILmcrHvPC7jgbjwM5oybF4qtOEqlRyUo tvdppRpvTXdSqSTet7WtolEqRik7L+tf8j2mivOfg14z8W+MbLUX8U6F/ZXkfZzb3H2Oaz85nhV5 ovImJf8AdSEp5mdr/wAIG016NX2WHrxxNJVYJ2fdW8v677rQ52rOwUUUV0khRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFF FFABRRRQAUUUUAFFFFAH/9k= --001636283ab21a98ad0496b0c912 Content-Type: image/jpeg; name="=?GB2312?B?v827p7e0wKEwMDAuanBn?=" Content-Disposition: attachment; filename="=?GB2312?B?v827p7e0wKEwMDAuanBn?=" Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAMCAgMCAgMDAwMEAwMEBQgFBQQEBQoHBwYIDAoMDAsK CwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT/2wBDAQMEBAUEBQkFBQkUDQsNFBQUFBQU FBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBT/wAARCADdAL0DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD7f1nx zqFt8THgk1FNJt/sKMmlPqcLSyyxqJPLeFYZmDytcLGFiIdhC7Lv+QVR8I+MfEcXhTUL1bzzbm00 mEyQajbSOsN5GRC3mPJMkg3mNw7eWsKMjkuTHKX9I1vwteatLpl/Hqn2TWLGJovMjhP2abc8TuHj Dh9u6FSFEg9GLqWU0rT4cCy1OS6i1zUQtxbyQ3ar5cTzs0yyb90aKEOPMX5QMea7qUkZ3fPknfc+ YlhsV7VtSbjrbVK1169H5fjY5bw3rGt6/wD2NFY6zPYxLd3kwn12xlaW4l+YfZHAaJWZN8rsqgKp jRY/MEMjDbi+Iial4S0OaHUrGPX7n+yprqygkRpI0nntxJ+7JLKpWbAJ6bhznBrSsPBl5pOnkWVz pceotdrdGR9MJtodsC26rBCJgY8RoozvPV+zADSj8JWcXhrS9DEk/wBk0/7J5Tlh5jfZ3jdNxxjk xrnAHU4xVKMkjelQxMYNXs2n162SVtdHp/w+5t1k+IptSgtvNsrzTtNt4keW5vNRjaVI1UA42B0A GNxLlxt242ndldasTxN4YPiT7EP7VvtOW1l88JaCFlkcfcLiWNwdp+ZR2bDdVUjaW2h6tbmcHyq7 8tDEfxZrcf8AYV7cWkFjb6j9mU6bLbytLGZPLD+ZcnbHCyNIQI2UmQx7VO59q2fE/jd9LuLC20+2 8+aW7gjuWuFdBbwvdx25JGM7nLt5ecKwjdgWC4ayngst9iiutc1S/sbXyGFnctCyyPDtKO7iMSM2 9FkPz8tnI2nbRr/w+0TxSqHV7KDULlJUkW7nt4mmCLN5oh3bP9X1QjupOSSSTnadnY4XHE8klB6+ ffr339Pknq6WleOTrni650+3mtbewtbiS1DPHJI93Ki/Oiv8qQujB/kJd3RS4VUwzRT+M79724u7 dYF0m11Cz057We2kS5lNwLciTcWHl7ftS5jaMn92Rkbvl17TwZbWmqx3Yu7p7eG4lvLewcp5ME8u /wAyRSFDknzZeGcqPMOAMLtiPgeCS9WeXUb6WJ5Ybq5tm8oR3VxEECTORGGDDyojhGVDsHy4LAlp 2DkxLhZvW7/LTrsn96WqvdOz4d1W81C/8QW14YG+wah9nhaCMpmMwQyruBZssPNIJGAcZwOlbdZO i+Hho2oaxdi/urs6ncC5eO4EeyJgioAm1FONiIvzE/cB6kk61aK9tTupKSj7+93913b8AooopmwU UUUAFFFFABRRRQAUUUUAFFFFAHk3xE+MHiHw/YWljo/gvUY/FGqzrb6Xbak9pLHMwIMhZYbouFWP cS/CqSu4gGtyz+JWq6n4qg0i08G3pjhdU1WWbVLDztPDrmJmhjndmDck52naMqH6V418Vvhde3Hx Y8BfbL6PxH4i1t9TM814qQ2qxRQq0UEUUkVykcaBnIykjMzMxbJBXov2evCg8M/Fj4nW11ZWUN/Z ppsStarERGkkLuyo0cECgNhCQsa5KjO4jcfiaWMxksf7Cbkk5qP2dEoOp/K1zPZ2e2z05jqcY8l1 /WtjR8bftM2WmaBNcaNp1wJri9l07StSv/s32C8mjfazqftSOYOxnHyLuBOSNp6HwX8eNO8Y6/pW hppVwup3kDzStY3tnf21tsQFzJJBO5VdxCqzou4sOBzjzf4t2t74t+IGh6PbeCZND13xC8bw+INY 1RPtMCWeZnjtTC04tTjb+8Ucl2yhPzV0PwNvPEnhvWvE3gZtJ0q7k0bUY7q/1WTVJTcTJd5lDu32 f/SJlXILt5e7agwMZqaONxjx/s51HyXUfgdrpc3LZpNNx1vsl1la4OMeS6R2Xj34lahpmuXPhPwx o9xqvi46X/atuHSE2gj80x4kLzxHlhj5ckbgcNgrUXh74s6nqnxGs/B+peDb3RbyTSP7UnllvbeY Q/PsIwjHdHu+UMDvJIzGoyw52HQbb4k/tA6/qkct6ukaDpEehzXNlfT2plvDMZmRJYHXcI1O11Zg VcrlehruND+FOj+HvG7+KLW61WW/bTjphjvtQlu08syiTIMxZwcgcBtvX5ckmvUpvG4iq6tOfuKd t1Zxi3fRx3vdXUtfuM3ypWa1sc9Z/GkX3xjg8Lx2V6ukTaQt2sk2jXsVyLk3HljcGQbYdp5kZQoP Vx0rI+Cv7Qg8e2NhH4jfQtMv7xMwNa6rEDJL57xiBrZ381JCAjLjerBs7lJC1xtxa6Nrv7RWq/8A CceJdG1/TLLw6rXBhYWVlaSR30arbTL5zh8SfMUmZgWkAK8KBh/BPxufCreCNI1rUb2xtbC6On6Z ptgJYzrP26WUx38qzCMNaKOE2qzhzuO3IU+FHNMVHFx9rUSjzTVtNdYLVXdklzNNSbeq30NvZx5d EeqfFn46yeCPEt7pWmPpz/2TolxqmpNdo8hWRikVnCgjbIZppIy4cAeW4IYZzWtoXxws3ufBmjaz pWs2fiPXYAJY/wCx7mGGC4WNWlX94oJUMxG5N4UDLFV+avFfip4Ig8NfG+3tfCenR2uqpoK6lb6n ekTQ2Vx9ud5r+7lnLZCxCUeY+8hjHtG4JjW+Edxe6f8AEDWfFWi2set6NqnjLUtIvpLKzS4mjhl8 uSC4SZV3CEOPnLSFNpUhCxzThmeNjjpU5vTmS0V0ldXttfS19NL82t7JckeS56Hqn7SOk22qX2mW uk3v2q2utQtPtWoMkNmXskEtyS0ZllAWMhlxEdxIGByVm8JfFfxD4k+KOm6FJpujR6JfeHV11Li0 vJ5ZDG8m1HBeGPrlf3ZRSAS2/I2V55/woLxlqnijWL+aHTo9Mk1vXpUtLi7ME01vfQLCJUlRJgPl 5CtGCpTnO75TwPYah4e+PPg2xtdWt9U+zaXd6Lfw2Wpw6i1nZ26AxRTbLSAw4mKDc2WY/KSOjXHH Ziq0PrF4xc4paJXTaXba7fnZByQt7vY9J8U/GXVvCul+INeuvCMkPhrRdRWxlnu7p4Ly4TfGjTwQ GEo8e6Q7SZRuCn7vQep15j44tP7e+MfgKznsdZmstM+0agzpp3naW8rROsRlmLgRyxlCy/IxzIuC uc16dX1OElWlVqqpO8U0lot7Xb0tpqlZ6+7e+pzytZWCiiivUICiiigAooooAKKKKACiiigCpc6R YXmoWd9cWVvPe2W/7LcyRK0kG8YfYxGV3Dg4xkdai0zw5pOi3d9dafpdlYXV8/m3c1tbpG9w+Sd0 jKAWOWY5OfvH1rzHWfHOoW3xMeCTUU0m3+woyaU+pwtLLLGok8t4VhmYPK1wsYWIh2ELsu/5BVHw j4x8RxeFNQvVvPNubTSYTJBqNtI6w3kZELeY8kySDeY3Dt5awoyOS5Mcpfl5qfNfl11/K35aHkf2 pT53TSd1e/yPVte8I6F4q8j+2tF07WPI3eT9vtI5/L3Y3bd4OM7RnHXA9KNB8I6F4V8/+xdF07R/ P2+d9gtI4PM2527tgGcbjjPTJ9a878N6xrev/wBjRWOsz2MS3d5MJ9dsZWluJfmH2RwGiVmTfK7K oCqY0WPzBDIw24viImpeEtDmh1Kxj1+5/sqa6soJEaSNJ57cSfuySyqVmwCem4c5waFGk5+15Vzd 7K+3c2hj4ShzPRWuttdE9NfM7TStIsNBsIrHTLK306yiz5dtaRLFGmSScKoAGSSfqTVuisnxFNqU Ft5tleadptvEjy3N5qMbSpGqgHGwOgAxuJcuNu3G07sr0JKEbJaI7py5U5blu20iws9QvL63sreC 9vdn2q5jiVZJ9gwm9gMttHAznA6VFqfhzSdau7G61DS7K/urF/NtJrm3SR7d8g7o2YEqcqpyMfdH pXMv4s1uP+wr24tILG31H7Mp02W3laWMyeWH8y5O2OFkaQgRspMhj2qdz7Vs+J/G76XcWFtp9t58 0t3BHctcK6C3he7jtySMZ3OXby84VhG7AsFw2bVNxaa03/X89fxOf63TScm7W/r+vx0Oi/siw/tb +1PsVv8A2n5H2b7b5S+d5W7d5e/Gdu7nbnGeaNK0iw0GwisdMsrfTrKLPl21pEsUaZJJwqgAZJJ+ pNczpXjk654uudPt5rW3sLW4ktQzxySPdyovzor/ACpC6MH+Ql3dFLhVTDNFP4zv3vbi7t1gXSbX ULPTntZ7aRLmU3AtyJNxYeXt+1LmNoyf3ZGRu+UXs0+ZLv8A8H8hfW6fLzJ3V7fdu/Rf8Ne6v21V LbSLCz1C8vreyt4L292farmOJVkn2DCb2Ay20cDOcDpWFpGp663ixtPv5dOmtxYm7mitIJFe1Z5A sKGRnIlDBJ/mCJ/qgSF3AV1FaaSs2tjenU9om0rf1/X/AA4UUUVRqFFFFABRRRQAUUUUAFFFFABR RRQBzet+FrzVpdMv49U+yaxYxNF5kcJ+zTbnidw8YcPt3QqQokHoxdSymlafDgWWpyXUWuaiFuLe SG7VfLiedmmWTfujRQhx5i/KBjzXdSkjO78j4p+MeueDNC8QeIzpWleKPCdui3GnazpOorGk264j h+zOv7w+YhaQmRfkOwDCkkDX+H/j/wASeI/iT4z8O6xpmlWVroSWhVrG6lmcPNHvALMihwQCc7U2 4Aw+dw8hZhhZVo0deaXk+0mnfazUHZpu9uxjLBU5N1Gvxfl5m3YeDLzSdPIsrnS49Ra7W6Mj6YTb Q7YFt1WCETAx4jRRneer9mAGlH4Ss4vDWl6GJJ/smn/ZPKcsPMb7O8bpuOMcmNc4A6nGK4H4ifGD xD4fsLSx0fwXqMfijVZ1t9LttSe0ljmYEGQssN0XCrHuJfhVJXcQDW5Z/ErVdT8VQaRaeDb0xwuq arLNqlh52nh1zEzQxzuzBuSc7TtGVD9KpY7D+0dJKV1ZfDLd9Nt7avstXoOOEhBaLRp9enXr1/E7 2sTxN4YPiT7EP7VvtOW1l88JaCFlkcfcLiWNwdp+ZR2bDdVUjl9W8e67P8RJdA8LWOna7DYQBdXi u5pLNtOldRJA5m2v5iyJuG2ONipALMAcDP1j4ieM9H+JPgjw7daJoVva6692JWh1Ka4cJDGrsVYw RhSASQCrbumU+9VTzChFO97KSjdJtXbUd1pu7PXR3T1VjWdH2keWWz87eZ16eCy32KK61zVL+xtf IYWdy0LLI8O0o7uIxIzb0WQ/Py2cjadtGv8Aw+0TxSqHV7KDULlJUkW7nt4mmCLN5oh3bP8AV9UI 7qTkkkk+R+I/2qpvD13qnmeF4xYWOvS6E15NeXCpuQnMrMtoyAYGSiu0nohHNaPhT47+IPGHi7w9 p66Jp2h2WozzLEuoNfeZqdukYf7RaSG1SPaFJbD8sMDCZBPEs6y6c/YxneTaVrPq7dV3/wCBqQ8F FxalG6ffX8/6R6haeDLa01WO7F3dPbw3Et5b2DlPJgnl3+ZIpChyT5svDOVHmHAGF2xHwPBJerPL qN9LE8sN1c2zeUI7q4iCBJnIjDBh5URwjKh2D5cFgfLvHv7Wmi+DItQSHw9qt9dW2o3OlxtK0MNv NPbsgmG8O7gBZFIJj5yBxzg0b4+eJNf+JOieHY/D2lWVrNq+paReM1/LM7PaRo8jxt5SBQA+QGU7 +h8v71N5zl6qexU7yulZJvWTsulv+AH1KPL8Om/9fLS21tNj2iz0iGy1DUL1WeS4vXRnaQg7FVAq xqcZCA7m28/NI5/iNXaKK9/YaioqyCiiigoKKKKACiiigAooooAKKKKACiiigD5Y8V6VJ4l1b4sj Vb3TvAs3h6DT7q2awnd7KK9kb7QbxiI0drp9ixCVED7ZCoEhxu1vhPD4W1/x3J4l8Vy2+jeJE8rT NO8K+IdQlur2zYMsqSk3h8wyuzAx+UAqq3G52bHut14F8N32tLrFz4e0q41dXSUahLZRNcB0xsbz Cu7K7Vwc8YGOlaNzpFheahZ31xZW897Zb/stzJErSQbxh9jEZXcODjGR1r5Snk041lWk4uzb1V7+ 9JpvazipWSSs7a/Z5eh1Vax80fFb4XXtx8WPAX2y+j8R+ItbfUzPNeKkNqsUUKtFBFFJFcpHGgZy MpIzMzMWyQV6L9nrwoPDPxY+J1tdWVlDf2aabErWqxERpJC7sqNHBAoDYQkLGuSozuI3H3W50iwv NQs764sree9st/2W5kiVpIN4w+xiMruHBxjI61FpnhzSdFu7660/S7Kwur5/Nu5ra3SN7h8k7pGU Ascsxyc/ePrWlPJYUsYsVB6c/NbfT2fL11b5vebb/ETq3jy/1ufNHjPwXqvjf4zeN7fS9Kt9Z+x+ IvDl7dWl5KkcLW6WcwfzCwOVO4AgKxwThW6UeFPCv/CD/HXwXpM9xoyX0ut69qbaXo9z5q6fFPZQ mKJgUQrwhx8oBABHoPpy20iws9QvL63sreC9vdn2q5jiVZJ9gwm9gMttHAznA6Uf2RYf2t/an2K3 /tPyPs323yl87yt27y9+M7d3O3OM81l/YMef23N73tObyt7Tnsut9lq2uth+10t5fpY+IJodS8Ye MvFVjdPozaVf/wBorpGt3ul2Vu2pus/lh4Z47KR7mU787YcOxPyspwD6H8B/hNrPhPxR4PbV7LUb G1tp9R1SwmeyLeas8CQeTdBWP2SUJEkgDFw28puDoQfpH/hEdC/sD+wv7F07+xP+gb9kj+zff3/6 vG373zdOvPWs6z+F3gzT7uC6tfCOhW11A6yxTQ6bCjxupyrKwXIIIBBFcVDh2VGtCvOfO009W11U rbO6TWmq87renWurLQ+Qfj58K/GOmaXrmsXejRw6FD4l1TUvtYvI2fyrp7ZImMYOQCUGMEty25VA Bb6M1Twd4B+Emv8AhvWv7J1F9T1DW/sVpOL+4uNl3doyPM6yzY+ZVwzYLHC8HAx6peWcGoWk9rdQ R3NrOjRSwzIHSRGGGVlPBBBIINc7Z/C7wZp93BdWvhHQra6gdZYpodNhR43U5VlYLkEEAgiu2lkU MLXqVqNpOXK7zSbi4t6rTtbs01e76S6vMkmdPRRRX1hzhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA HjPxA8e+IfD/AMTvLjn0zS9Hsre2ie81G5kFnDDeLdlrq6HyqrxzWEMca7gG8508xTODFjaR4t8R +DfBvim/bxJdanq+jaB9rsvDHieSMT+XHGrPeSOtrFPKhztXIBJUiVo5WdLf0bxh4E17xBqE15p3 iuXSmaSNVtTHObb7OtvcRsrLFcRP5jPcl/MV1x5Nvhcx7jS0j4Z+ILfS9bXUfGctxq+rxrb3N/p1 gtkNgihiMyornbdBY5SswYYMqhkdIYkT7Sli8vVCEZKOihdWld2ab15Xa/vXad9Uo6XPmZ4fFurK UebeVnddU7acy8rJq3V9DzmfX/FBQWC+KrrRrjw/9r0uS7hlFxLa2y3KRw6hq0c0EinzIkWRSPLJ AeQOIZZXtfQPjB4gvNG+BOs6no2v2rY0h2XXri4Cs6mBtksRh2K0srmNUKlFDShlDbRG8F78KvFW o6jcJc+Nop9CuLtppbGXTpXn8n7b9qREma5IikjBaJJokRlUqfvRRGPrfEXhK81aw0NrXVtmsaNc C6tr6/thOksnkSQO00UZi3bkmkOEKANtPQFTFfF4J1qE4uLUZNuyfrZ3hfV3/mSVnaTuiqWHxKp1 YNS1SSu16ae9bb0bfVaGn4ZvbjUtBsrq6uLG7lmj3i60xy1tcIfuSx5zgOu1tuW27sB3A3G7evcR 2Vw1nFFPdrGxhinlMcbvj5VZwrFQTgEhWx1welZnhDw5/wAItoa2LXH2uZ7i4vJ5gmxXmnmeeUou TtTfI21SWIXALMQSdO9t3urK4giuZbOWSNkW5gCGSIkYDqHVlyOo3KRxyCOK+Xq8ntpcjvG7t0Vr 9tz3qfN7Jc29vxPP18R+L0l1/SzdaPeXelRwXEusW2l3LQxB0ld4BZpM7zTqscLbBKpK3cbbflVZ bul/EtIvAq63q1vK9wkdyfKsLd83LQz+QqIrH91PMxQLayP5odzGctG+IdB+E9z4b02S0sPHXiZN /lgTSfYZGUKZWY4a2Kl5HmZ5JWUyOyqS5wc7Nt8PdJTQ00a7T+1tJbzpLuy1KGGeK9nlmE7zyqUx v83ewCbUBkOF4Tb7NaeBbtdNcy+FNNpR97orXdrK9l5bvzKUMUlfVOz3d1e+nXWy3e/rsuGn+NOp Wfh7R0ubOxj8Tapqep2QtrYXFzHbw2lzLC80cccZluim2HMaBGfez/ukV2TpvGHjO90f4X61rWk3 tjf6pp2if2ul79ilbT7sCNnzHtkwQ4jbAWVigdGO4EbodO+Cui+HLWCPw3c3Xha5huLyZbvSobZX 2XMqySxFHheMpmOBVOzcqwRqGxuDaerfDey1HwRd+Ere/vtL0KbTI9Ijt7QxMYLdVKMEaRHYl4yE YsW4UFdrZY6VKuWurCVJWXPd3XTm7WeijZJXd9b2drxCnjVCSqO75bLXry99PtX1sraW0val8Udb 8VeHtIuL/QZ9HgWKOOK3h1C1luZL68lkEUMA2yxLCGkaJfMYuP3pJCCPLdzWNe+F4tUg0SK/vLq9 /sy4juiZfLAvJEjZVaZVQKcOyygKFAkjjYY2gVs14tWpB0oU4pXV7tK29reb2b1720senThJVJTb dnbS/r8lvbTtcKKKK4zpCiiigAooooAKKKKACiiigAooooA5Dxf8W/CPgeDU/wC1PEGmx32nwNPJ pgvYRdvhN4RYmcEuwxtBxncPWobP4zeDb+zgkg16yu72WNX/ALL064S/vQSMlRDbNIzled2zcAFY 52gmuK+N2oa5G/h67m1W28MaYNc+zwxXl5BbxS7Le4kW4uJpIZ0X95FGYk2NghWbEjKIIfhh4r1X Wfija2lz4xsvElr/AGNeymDTtbt79I3E9oFZ1gtLcKcMwUtv6vjb82766GVUZYJYi19G3afbovca 6d36n3tPI8PLLo4vlvZSk2p9uiXs2t0+rtfd2PR9Z8dS6d4jm0Wx8N6trt1BaQ3kz2D2qJGkryog JmnjJJMEnQHHHPNY/iX4o6t4c8Oarq0nw+18R2FpLdMZrrT1TCIWO4rdOwHHJVWPopPFc58TtPuN T8SeKILaxvdRk+yeGJDbaa5juHRdWuWfY4ZdhCqx37l24yWUDIx/Eui31j4c+IV23h7X7DTZfCN7 FHP4h1WO+e2lVHLLE32qdwJlZCw+RR9lT7xYbaw2CwslT51FtuOjbu7qDf21/M7Wj06srB5dgpKl 7SMW24qzbTd405P/AJex/ndrQ2ju3oev+NfFtv4N0NryQRzXs0i2un2UkwiN7dvxDbqxBwXbAzjC jLHCqSMe6+MHh6wiWS5h1+3jaRIg8vhrUlBd2CIuTb9WZlUDuSAOTR8VNBsb3wZ4onkeO31C80af SYLm4MjhDMpVURFDHLyNGCI1LyFYxhiqAfMugQWdz4g8GCHR47DUrvWbN4rT+yo4rgGC7iN0oZNG gBMIVxJsnAXa2Sw+VqyrKcNmGHdWXN7rd7WXS/Z6JJ6/N9C8jyHCZrhHWnzXg3zNWWlr9U1ZJN36 at6WPqzxV4zi8K+EZNXubbyr54CbTSbmdEnuboxlktEKlg0rFdoCb8n7u6ptV8Y2enS6NHBHJqja pqTaXEbF42EcqLK0pcs6gCMQS7gMsCuApPFc38W4Li7uvBVvbafZatJNrMsRstSmMVvMjabfB1dh HJxtLcbDnocA5HIfDHwG9xp0bajouk6no9zqWqaXPoxhV7XSoI7+5lUxb8BwZo1RgI13AWx2r9nO /gpYPDPCRxNR2eul9781la99OW625r2vex5dHL8G8DHF1nZ3btfe/OkkuZP3eS6vbmu4817HtVre W9/E0ltPHcRrI8ReJwwDoxR1yO6srKR2IIPIqauK+D9nb6d4NmtLSCO1tYNZ1eKKCFAiRoupXIVV UcAAAAAdK7WvFxNJUa86UXdRbX3Ox85jKMcNialGDuoyaT72dgooormOQKKKKACiiigAooooAKKK KACiiigAooooAztV0G31e+0a7meRZNKu2vIQhADOYJYSGyDkbZmPGOQOcZBzYvCM3/CfyeJbjWLm 5hSxaytNMaKJYrXzGjaZg4UO24wQ4DE7SH5IYBec8S/F5NA+IUHh6PTL6/URpDLHb2bmaW6nSWW1 WFmKo0ey0uhJIfkRmiyyhZimZoXxh1q18Kaxr/ifQbUaPo1gJrnUdCluZmuLlR+9ijtpbeN02EHe XbETZRmzHN5fv08Dj1TU4x0cUle17TbslfW78tWn2bMI51Ck3TU9lKO17LeWtny7u706q9nZ9hrP gWXUfEc2tWPiTVtCup7SGzmSwS1dJEieV0JE0EhBBnk6EZ444rN1n4YX/iDSL7S7/wAeeJJ7G9ge 2uIvJ05d8bqVZci0BGQSMgg1yjfGbxM9rpwsfDtrqV/H9q029t5jcWcd7qkMoieKwl8uUMgKTN+8 CjYQxceRciPs/iR411HwL8NNT10aZ9p1q3sJZltLYNcQRzJC0jF5D5f7pdjEs2wsBhRvZUO3sMwo VKVO0eZu0dIN6O27V0l3eluuh1UeIZRi6kGv3aTu4RbVlpaTi22lole608jQ8S6FrWsahaPY6ppt hZw/MGm0s3F3DIQ6NLBK0oSN/LcqC0TgZbIYErWPbfCGw0vUL3VdK1nW9L1/UNn9oavFdLNLe7Rg eZFMkkI9tka7B8qbVJU9fo2p/wBsabDdm0urF3yr215HslidSVZWGSDgg4ZSysMMrMpDGa9u00+y uLqVZWigjaVlgieWQgDJCogLMeOFUEnoATXlxxWJpfuYu3RpJa67PT3lfWzur6nbSzPEUqSjTnaN rPRWave0tPeV9bSur67nLXPw8/t3QfD9l4h1vUtVvtKn+1tqNrL/AGfLcTGKWMnNvsKJiZsKhBwF DM3zbtLQPCFv4X8My6Lpt7ewxtJcypdyyie4jeaV5WbfIG3lWkOC4bOBu3HJOTF8SWk+1WreF9dj 1yDyW/sXbbPO8cvmbJfMSYwIh8icZeVTmPGMvGH2tI8W6dqvhyTW3k/s+yg89bo3rLH9leF3SdZG yVHlvG6lgxX5SQxXBOtf64octT4brRWtd3aslpZ3drKz1S2OV5tUxEfZOp7t+bltaKabv7tlFWcn pbRO1rWLHh7Qbfw3pUdjbvJKokkmkmmILzSySNJLI2AACzu7EKAo3YUAAAaNcZB8V9HuvDljq8Nr qcn9oX9xpdjYfYnW6uLmJ5lKeWceVn7PI2ZSgUDMhTBxp+JvF48KeCL3xLeaVfNFZWn225sITCbm JAu6QcyCMlF3E4c52naWOM4VMNiZVeWpF88pNa6NyvZ/jo3tc454yFbmrSnf7Te++t/nudBRXJ+K /iRZeE725glsL69isLRdR1O5tBF5en2rGQCaQO6s4PkzHbEsj/uj8uSobrK550alOMZzVlLb+vRp +jT2aHGrCcnGL1X9f5/NNBRRRWBqFFFFABRRRQAUUUUAFFFFABRRRQB5N8SvD2uajrl7fad4X/tC OT7LZi7troxX6COG9cTwsLuAKiy3MUfyyRyOr3SnKFGrM07wj4g1TRPFcr+CYtCXVtMGkweH59TU W8bG3gh3Mls6xNAPmUycXKx2+ELCSOGH2yoby8t9Os57u7njtbWCNpZZ5nCJGijLMzHgAAEknpXv U82rRhGlGC0svtX0t/etrZdPJWR5by2FSo3d630tHrf+7fqzwzU/Dfie/wBY1i0XwFLANRu3jj1i K8gEFmv9oiRbiONrpnQSRLHNKIEglM0O4MHdJIO68deGtR1bwNpGlPp91qNgNkOtaPY6kzXF5bG3 kQwpdSvEz4laJmZ3jLojhs7ijd/RUVM2qzlCXKlyu6tzb2t1k7WSVrWta6s9Qhl9OKlHmb5lbp69 tb9b3vs9Dn/Adpqlj4WtYdYaU3YkmZEuJfNmitzK5t4pZMnfIkJjR23PuZWO987jtXr3EdlcNZxR T3axsYYp5THG74+VWcKxUE4BIVsdcHpRZ3lvqNnBd2k8d1azxrLFPC4dJEYZVlYcEEEEEdamry6s 3OrKclZtt26b7HoxpulFU9dNNd9P1PLNE8P+OoLLWpNb0Lwprd/qkcMN0suqz+XcJiYSoS1owWBQ 8axwBD96Znd3dme7D8LXvvBlv4e1F4rVWjuQ15p7oZLGKS6SdbCESwsj2oRRCysqq0cKKYsNhPRq K9CeZVXLmhFRd09L7pWWjbVkum3R3WhwxwVNLlk29GtbdXd9Ovf9TxNfgfqlrb6fLemx8by2t3rD Npuu3P2e2livLtJ0ZzFbFZCvlKxjeJl8yVmVlEUYrpvEPgLWbn4X6v4btTY6prV34di0Q67qE7xT Xj+XJG7zERyMAvmNIo3PuaRwdv329Goq55viakoynZ8r5uyvzc2y0tdva1763srTHL6EE1G+qt+F t/S2+3Td38z8ffDO/wDiTPYRXsdro1tJbwLq1zYand+bdxiTM1gUj8lZImVpFWWQsVEkm2JS5Yem UUVwVsVUrU4UpP3Y3su17X3v2R106EKU5VF8UrXfe2wUUUVyHQFFFFABRRRQAUUUUAFFFFABRRRQ B8wanp+g2WreILi9sbLXNY0rTfFmrS6PrTtdxW7i/iktXNq7EQiSNtwKBPMVt2TnNbuj+C7C1+IG jxXegeE45tM8VrZRT6LoK2TPjRprvc2ZJM4eSIqARhoQ2SSNvss3gXQbjSr3TpNNje1vI7yKYEtv KXchkuVD53KHc5IUjouMbRjHuPh/b6ZrHhRfDukaTo+j6dqU2pXiWqC3LO1nNbrsjSPaxPmjLMy4 EY+9nj7b+2o1YSpqUk3Ga1emt2tb6dUoruld2R+j/wCscK1KdKMpJuNRatW1vJWd7rrFRV/iSu7I 8417w9oOrfGZLHWo47y6vvE4mXR7+dpIbi0XQSBOLRm8tgJoyvnbCQyFd3GK5bT/AA7Ya/pOmz6j 4W8FRQ3MHhnVAul+HVtpV+26iitEXaV9yBInU/KN4k7AEN9KQeHNMt764vUs4zdT3YvnlkG8ifyF t/MXOdh8pQny44z/AHjnj7/4UaZougafpXg/Q9J0iMalps93KB5LvBa3CTZLKjNNJ+72jeR99iWz 1MPnUbU6fNJNKmrt6Llb5nvpporXv5aIMJxHBKlS5pRcY0optqy5G3N76JqyVk27dNEeg0UUV8Sf nAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQBz+r+O9G0HXodK1C8itJZLSW9ee aVEhhROcSMzDaWVZnXjlbac5xGazPDnxa0HxD9oR01PRLm0sF1K9g1zTLix+xwnPMskqCMYKuMhy D5bkEhSR5n8WP+EZ0Xx/ea7LNa2epRXGmNHcXdnbvYf2jDbalJGLh5J4Q0vkOoUM8ZjZrNtxVsDM tLrw14i+HPjvR9Jv4tY8E3GmbLa4h0pbiaa+a2txGqMPKQTqz24jtSgIZo0ikURGC3+0pZPhp0IT fNqoXdnZXav0d99FdXs3dLf5meY1o1ZRXLo5aX7J26q22rs7Xtqep3Xxv8Oafptjf3cepxW01g+o XRhsJLltMVDtaO8WEO0DhlmX5htDW04LApit/wATeOdL8J+CL3xVqLywaXa2n2xlmj8iZhtyseyX aVkYkKEbadzBTg14BdeIfCFjr+q2em6vYjXo9bubjTNMkt7YXM+oPqipOk5DsZj5kcLRRuLdTGYW MgeAXFt6Z8XJk1f4Zafa6lcWNjFrMbWVz4h1KxeCDSRNZzK9yYZXVoS2TAqvIpVrhVJY5R4r5Vh6 dahHlkoyk73vstdFy9tLpu7TSTa1qlj606dV3i2krW77a699dbWTu2k9PTbK9t9Ssre8s7iK6tLi NZYZ4HDxyIwyrKw4IIIII65qauZ+G+p/2x4Rt7z7Ja2vm3F0d9lH5cF3/pEg+1xrk/JPjzxy2RKD vf7x2tbWzfRr9dQtvttgbeQXFt9nNx5se0708pQxkyMjYAS2cYOcV8vVpezrSpdm13e9j3qdTnpK p3VzLt/iF4VutBudcg8TaPNottIIp9Sjv4mtonO0BWkDbVPzpwT/ABL6itqyvbfUrK3vLO4iurS4 jWWGeBw8ciMMqysOCCCCCOua8f0fxTY67qWt+JtV0XxNpF/Nb2ltaOvhm6klsABeCIxq0DlrhRNO ZHCGFRNHGDJ8zSXbDRfEM/w1fS9KlutO1i//ALReL7UJLQTQzX243UkyxM1tdtDIZEUBQskr/ucR 7I/ZrZZGm+W7i+ZL3tleN3rbXl6taa7JavzKWOlNXspKzem+jsuul+i39XovTW1vTk0251Br+1Ww tfN8+6My+VF5RZZd75wuwowbJ+UqQcYNQXfijRtP0FdcutXsbbRWjSUalNcolsUfARvMJ24bcuDn nIx1rwCz8Kaza6L4XttZ0qXwz4f0rW9avI4dB0t9Uktrj7Yxsnhi+zHywFkutjtC8flhGwkjxGP1 O41iWLw/p134ph1O0182Fq0kOkaNJfrpl7JDMsktuY4ZvnGZUJLOqqIwQBL+8eIyuFGS5J895Nab 2Umlsmm3ZNtN8t1o21dUcfOqnzR5dE9drtJ9bPrZJ2vZ66O2/qvxC8K6DZafean4m0fTrTUI/Ns5 7u/iijuUwp3RszAOMMpyM/eHqK6CvILXwvcXXw6ttJ/siWO78SanLaX13JbFJZtNa8uLmR7o43Qm a3af5QE8ua7CqsOcJ6/Xn4yhRoWjTbbvJdNUmkmrbX1W7va+mx2YarUq6zVlZP5vdfl99gooorzD uCiiigAooooAKKKKACiiigAooooAKK5DXNMuLzxRHaReN9b0i4vIJLmDTrS3smiWOIxJIwaS1dvv SxnDOTlzjgYHOeB9O1PxF4R8F6xrPj/W/tGqQWV8bJfsNvHcTeWtw0K7LdZChCPlQ+SgYEkZr044 JSpe2dRJadJX1v8A3bP4X1tdbnswy5SofWHWilppad9ebb3LO3LJPW11uepUV438T/E/ia08fDTd K1PVtP09Y9FR5dPisWhhN3qEtvI0vno0hJRVCeWCAwywx1h1p9Yh8cWXh220XxJf2M841JINW1G0 e2YWIhiiKSea06RGZ7aeRm3yEx8RP5soHXTymU4xlKpFXTdr62STa1sr2d0r+rSs330shnOEJyrQ XNFytfWySk078q5uWV0r201aVm/aqK5bxrcahqfgxr/wvd3t1dGNbmzGizWYN6GX5FElyjxCM7gx YDOFyufut414KtLvxfa/2peHW72G9vraK9n8QeJA2hlGlRZYbZLadkunkEgj2sogaQMoWID7PUYX LfrFGVadRRSdrac1/Rtf8GzS10MsFk6xWHnialVRUXy205r+jcdO2rvZpa6H0dRXOfEHxPF4S8L3 N82rabo9x922l1Qp5UkmC3lAPNCrOyqwAMigHknANfOOnfFmTUPtX2fVdEgC6q13ax6tdaelk1xx 5k08SakGRFuAzx+WrgKPOIuJnWVdMvyerj6UqsZJJO2t/wCv6ZtlXD9fNKMq8JKMU7ap/wDDfdd6 PTQ+saK841fxRd3Pw7iuNL165lvJdVsLFtZisBCrrPewI72yyxsjxeXMRG48xSuDvkILHhLvxnrz 634U05da8SX99JPr2nyHRFsBPK0V6y2pnWdVgXMNnc7W2qxMcm3+MVNDKK1dOXMlZyTvdW5YuV3d aKy66+RGFyCviYuXPGKUpRd+ZW5YOd3eOkbK2tnd6o+gqK4r4X2uv29tr0mvtqxafUvMsxrUtq9w IPs0C8i2JiQeYsuFXHqRliT2teVXpKhUdNSUrdVqtuh4eKoLDVXSU1K1tYu62vo/LYKKKK5zlCii igAooooAKKKKACiiigAooooA848TeKLfS/itpE8thrc1vY6VfW089pol7cxCSaSyeNQ8cTK2Vik5 UkAqQcHiuc+El54R8D+EfD7f8IjqWleIk0q3tr+4tvB96s7yCNPNV5Utvny65JyQSM817MtzC9zJ brKhuI0WR4gw3qrFgrEdQCVYA99p9DUVhqdnqkRlsruC8iG3LwSBwNyq68g91ZWHqGB6EV7UcfTW HWHcZWsr2la9nJ/y7Xk9PT5/QRzWgsKsI4Ss0k7TSvZye3I9LzemvTzv4x8X/BOr3fi7/hJUtNAj jS70Gz0/ULuN7q7gdNRBJVNsflhmuRu2ynKw7cAyZjzdW+HWl6nq938Q4PCWm+JraGC2WW1tNLi/ 4nY3Tm8uYIZCwO4ywyRuSZJPsxRWKSrI/vKanZyeVtu4G82V7ePEgO+RN29Bzyy7HyOo2Nnoas10 0c8r0qUacVtpo2rxtG60115d09LuyTs124fibEUaMKUF8K5dG1eFo3jpqm+XdSVrtpJ2a4rxns8b aVDoUXh+TVbfUI4Lt5dUtmisrYCQSRmdHKPIQY8mBQSSoWXylcNXCeHPBeleND4puLXSLLWpLDWU gtR44sLi6uPswsbaRrcPdfv4AZZHYMwcLvZhGwYV7hRXJQzKeGpunSuu2r3urtrq2klpay7nDhs3 qYOjKjQTS6e87XbTba2baioprlsu71OWi0jV9Y8OaHbPcSeH4GtEXUrITPc3oOxf3SXnmZBBDK0u GdgSVZGw4+U/G+jeEvD+i+NrC5sf7N1eGfVfs9qIfD0Sopmma32rMBeBDGYyu35tpHlcbK+1aK7c tzueXzb5OZNp2vbZt72be+7u/M9HJ+I6mVVJSdNSi2nZO2qbe9m3va7u7dTnPFXgi08R+FYNAhb+ yrGGezkRbMGLy47eeKURxmNlMeRFtDKQVyCOmK8gg8D/AGHT4PFOj3mtxaZBrm+2nsI/t+oPYk3y eeivHL526fUZ5A/z7rYRuMyZ3fQVFcWFzOthabpXvFu7T2d9Hunq1bV7dtTzsDnWIwVKVC/NCTu0 9ndWlo09WrK7vbXR3ZyHw61mG/g1OxsNA1LR9I0+dY7S61GCWFr7eiySSbJgs2/zHcM7g72+bexL bevoorzq9SNWo5xVr+d35tt7tvV+b0SWh5OJqxr1XUjG1+7bd7att7tvV7K70SWgUUUVgcwUUUUA FFFFABRRRQAUUUUAFFFFAHjHifSr6L4pW11fwPf3U1j5drctBYQ28UqGBIniaYySxhZ7mRicFyzR KFlCc5vhvSb200LXLG5un0/WbDRxYSTLqM0blYJComjcvFGgjULIIzGuUniLzYnc17Hf+FNM1O2t IrmB5HtE2W9158i3UIwAds4bzAWAAYhssMg5yait/BHh+0ura4t9GsbeW2iMEXkwKionmrNjaBji RQ4OOGyRgk55vZO9z5+WWydVzT0d933Sv0+7Xy6s838H6A2sNpkWp2E9nDaXc8P2PRrq5tY7O5eE SiYoixeVG0J2qowU83Em+SaQx6UGs3uo/Dnwsl1ZXzbv7DmbVJ5Injnc3NoT/wAtDIWyxyWUdDz0 z23/AAh2mjTfsSG+iiMvnvLFqNwk8r425eZZBI/y4GGY8Ko6KMaQ0yzWzgsxaQC0g8vyoBGPLj2E FNq4wNpVSMdMDHSqVNpWN6eBnCLje101p10S106W/wCGLNYHi+C0ktrdry41HG8xwWOm3T28t1MR lVDIysSAr8FwgBZn4Tcu/WbrPhrR/EXk/wBq6VY6n5OfK+2W6TbM4zt3A4zgZx6CtpK6PTrRc4OM Un67HHXMOpWen+GtZm1Z7+4lewhur61vW+znzHhjPlW6qsUqSs75d8Mgk3LnaiDS8eQXo0r+1bm4 eDTNMS4ubywsrqaGS4iXlXSaNo2V1jVm8s5RmbaSMLINu28IaFZahFf2+i6dBfQoI47mK0jWVFCb AoYDIAT5cDtx0ol8IaFPfQ3sui6dJeQP5kVw9pGZI23mTcrYyDvZmyP4mJ6ms+V2aOL6tU5JR7+f brtr5p77NtbclpV3cnVdH1E3l09xf69qGnXCPcO0Jgi+2eWqxE7EI+zxfMqhjtOSdzZu64Hj1fTp RqE9vrjy2rywi+f7FaQGREdGX5UfzD5kcZdDIzv8uAmY+pi0PTYNVm1SLT7WPU508uW9SFRNIvHy s+MkfKvBP8I9KojwP4cW9gvB4f0sXcHl+VOLKPzI9gATa23I2hVAx0wMdKOV2sH1eoocl09f0Svt v19XvfU5f4d65favfWd9qyXS3Gs2Mt/Yq13ujitg8Z8poUAQFfOj2yHfI67ixj4jHodUrDQ9N0q5 u7iy0+1s7i7fzLmW3hVHmbJO5yBljlmOT6n1q7VxTSszpw9OdKnyzd33/r+unmFFFFUdQUUUUAFF FFABRRRQAUUUUAFFFFAH/9k= --001636283ab21a98ad0496b0c912-- From lmcilroy@redhat.com Sun Dec 5 19:39:11 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_63 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB61dBMt170725 for ; Sun, 5 Dec 2010 19:39:11 -0600 X-ASG-Debug-ID: 1291599657-31ca00e50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx3-phx2.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 194A61C96474 for ; Sun, 5 Dec 2010 17:40:57 -0800 (PST) Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by cuda.sgi.com with ESMTP id 84TM0j2mSlruQJS8 for ; Sun, 05 Dec 2010 17:40:57 -0800 (PST) X-ASG-Whitelist: Barracuda Reputation Received: from mail05.corp.redhat.com (zmail05.collab.prod.int.phx2.redhat.com [10.5.5.46]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id oB61ekNl002750; Sun, 5 Dec 2010 20:40:46 -0500 Date: Sun, 5 Dec 2010 20:40:46 -0500 (EST) From: Lachlan McIlroy Reply-To: Lachlan McIlroy To: Dave Chinner Cc: xfs@oss.sgi.com Message-ID: <1860606102.27381291599646249.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> In-Reply-To: <2033621546.27171291599487418.JavaMail.root@zmail05.collab.prod.int.phx2.redhat.com> X-ASG-Orig-Subj: Re: [PATCH] xfs: prevent NMI timeouts in cmn_err Subject: Re: [PATCH] xfs: prevent NMI timeouts in cmn_err MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.5.71] X-Mailer: Zimbra 5.0.21_GA_3150.RHEL4_64 (ZimbraWebClient - FF3.0 (Linux)/5.0.21_GA_3150.RHEL4_64) X-Barracuda-Connect: mx3-phx2.redhat.com[209.132.183.24] X-Barracuda-Start-Time: 1291599658 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean ----- "Dave Chinner" wrote: > On Thu, Dec 02, 2010 at 10:51:32PM -0500, Lachlan McIlroy wrote: > > Dave, overall it looks good - just a few minor points below. > > Thanks for doing this. > > > > ----- "Dave Chinner" wrote: > > [snip] > > > > -void > > > -cmn_err(register int level, char *fmt, ...) > > > -{ > > > - char *fp = fmt; > > > - int len; > > > - ulong flags; > > > - va_list ap; > > > - > > > - level &= XFS_ERR_MASK; > > > - if (level > XFS_MAX_ERR_LEVEL) > > > - level = XFS_MAX_ERR_LEVEL; > > > - spin_lock_irqsave(&xfs_err_lock,flags); > > > - va_start(ap, fmt); > > > - if (*fmt == '!') fp++; > > > - len = vsnprintf(message, sizeof(message), fp, ap); > > > - if (len >= sizeof(message)) > > > - len = sizeof(message) - 1; > > > - if (message[len-1] == '\n') > > > - message[len-1] = 0; > ^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > - printk("%s%s\n", err_level[level], message); > > > - va_end(ap); > > > - spin_unlock_irqrestore(&xfs_err_lock,flags); > > > - BUG_ON(level == CE_PANIC); > > > -} > > [snip] > > > > +#define CE_DEBUG KERN_DEBUG > > > +#define CE_CONT KERN_INFO > > > +#define CE_NOTE KERN_NOTICE > > > +#define CE_WARN KERN_WARNING > > > +#define CE_ALERT KERN_ALERT > > > +#define CE_PANIC KERN_EMERG > > > + > > > +#define cmn_err(lvl, fmt, args...) \ > > > + do { \ > > > + printk(lvl fmt, ## args); \ > > > > The old cmn_err() routine would append a newline if one was not > supplied. > > As far as I know printk() will not do the same so either we need to > fix > > all calls to cmn_err() to supply a '\n' or add it here (at the risk > of > > having two newlines) - maybe: > > See above - I think you have it the wrong way around - it looks to > me like the old cmn_err() stripped the newline character if it > existed, then added one itself. That's the same thing - the input may or may not have a newline but the output always will. We should at least try to maintain that behaviour. > > > printk(lvl fmt "\n", ## args); > > printk() is actually pretty tolerant of missing newlines - if it > detects the previous printk() was not newline terminated and the > next one starts with a log level that is not KERN_CONT, it will > print the new message on a new line automatically. This is the code > in vprintk() that handles it: > > /* Do we have a loglevel in the string? */ > if (p[0] == '<') { > unsigned char c = p[1]; > if (c && p[2] == '>') { > switch (c) { > case '0' ... '7': /* loglevel */ > current_log_level = c - '0'; > /* Fallthrough - make sure we're on a new line > */ > case 'd': /* KERN_DEFAULT */ > if (!new_text_line) { > emit_log_char('\n'); > new_text_line = 1; > } > /* Fallthrough - skip the loglevel */ > case 'c': /* KERN_CONT */ > p += 3; > break; > } > } > } > > So we are probably OK not to need additional newlines. Indeed, I > didn't notice the output being screwed up without them. ;) What if the next message after a cmn_err() message doesn't have a log level? There are many users of printk() that don't specify a log level so it could potentially be joined with the previous message. (BTW that code above is not in rhel5). > > I can add them if you want, though. I think we should add them. > > > > > > + BUG_ON(strncmp(lvl, KERN_EMERG, strlen(KERN_EMERG)) == 0); \ > > > + } while (0) > > > + > > > +#define xfs_fs_cmn_err(lvl, mp, fmt, args...) \ > > > + do { \ > > > + printk(lvl "Filesystem %s: " fmt, (mp)->m_fsname, ## args); \ > > > > printk(lvl "Filesystem %s: " fmt "\n", (mp)->m_fsname, ## args); > > > > > + BUG_ON(strncmp(lvl, KERN_EMERG, strlen(KERN_EMERG)) == 0); \ > > > + } while (0) > > > + > > > +/* All callers to xfs_cmn_err use CE_ALERT, so don't bother > testing > > > lvl */ > > > +#define xfs_cmn_err(panic_tag, lvl, mp, fmt, args...) \ > > > + do { \ > > > + int panic = 0; \ > > > + if (xfs_panic_mask && (xfs_panic_mask & panic_tag)) { \ > > > + printk(KERN_ALERT "XFS: Transforming an alert into a BUG."); > \ > > > + panic = 1; \ > > > + } \ > > > + printk(KERN_ALERT "Filesystem %s: " fmt, (mp)->m_fsname, ## > args); > > > \ > > > + BUG_ON(panic); \ > > > + } while (0) > > > > I think we can simplify this case a bit and remove the panic > variable, > > like this: > > > > do { \ > > printk(KERN_ALERT "Filesystem %s: " fmt "\n", (mp)->m_fsname, ## > args); > > if (xfs_panic_mask && (xfs_panic_mask & panic_tag)) { \ > > printk(KERN_ALERT "XFS: Transforming an alert into a BUG.\n"); \ > > BUG_ON(1); \ > > } \ > > } while (0) > > > > This also reorders the messages which I think makes more sense. > > Definitely. That's a vast improvement. ;) > > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From SRS0+fHnJ+9+fromorbit.com=david@internode.on.net Sun Dec 5 22:08:15 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB648ErI186491 for ; Sun, 5 Dec 2010 22:08:15 -0600 X-ASG-Debug-ID: 1291608598-243901750000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6908D1C98E06 for ; Sun, 5 Dec 2010 20:09:58 -0800 (PST) Received: from mail.internode.on.net (bld-mail18.adl2.internode.on.net [150.101.137.103]) by cuda.sgi.com with ESMTP id CdxUFzBvYCWGMECE for ; Sun, 05 Dec 2010 20:09:58 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 48617300-1927428 for multiple; Mon, 06 Dec 2010 14:39:42 +1030 (CDT) Received: from dave by dastard with local (Exim 4.71) (envelope-from ) id 1PPSOS-0004Dx-I6; Mon, 06 Dec 2010 15:09:40 +1100 Date: Mon, 6 Dec 2010 15:09:40 +1100 From: Dave Chinner To: Spelic Cc: "linux-kernel@vger.kernel.org" , xfs@oss.sgi.com, linux-lvm@redhat.com X-ASG-Orig-Subj: Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram Subject: Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram Message-ID: <20101206040940.GA16103@dastard> References: <4CF7A539.1050206@shiftmail.org> <4CF7A9CF.2020904@shiftmail.org> <20101202230743.GZ16922@dastard> <4CF8F9BE.6000604@shiftmail.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4CF8F9BE.6000604@shiftmail.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: bld-mail18.adl2.internode.on.net[150.101.137.103] X-Barracuda-Start-Time: 1291608600 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48600 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Fri, Dec 03, 2010 at 03:07:58PM +0100, Spelic wrote: > On 12/03/2010 12:07 AM, Dave Chinner wrote: > >This is a classic ENOSPC vs NFS client writeback overcommit caching > >issue. Have a look at the block map output - I bet theres holes in > >the file and it's only consuming 1.5GB of disk space. use xfs_bmap > >to check this. du should tell you the same thing. > > > > Yes you are right! .... > root@server:/mnt/ram# xfs_bmap zerofile > zerofile: .... > 30: [3473240..3485567]: 2265328..2277655 > 31: [3485568..3632983]: hole > 32: [3632984..3645311]: 2277656..2289983 > 33: [3645312..3866455]: hole > 34: [3866456..3878783]: 2289984..2302311 > > (many delayed allocation extents cannot be filled because space on > device is finished) > > However ... > > > >Basically, the NFS client overcommits the server filesystem space by > >doing local writeback caching. Hence it caches 1.9GB of data before > >it gets the first ENOSPC error back from the server at around 1.5GB > >of written data. At that point, the data that gets ENOSPC errors is > >tossed by the NFS client, and a ENOSPC error is placed on the > >address space to be reported to the next write/sync call. That gets > >to the dd process when it's 1.9GB into the write. > > I'm no great expert but isn't this a design flaw in NFS? Yes, sure is. [ Well, to be precise the original NFSv2 specification didn't have this flaw because all writes were synchronous. NFSv3 introduced asynchronous writes (writeback caching) and with it this problem. NFSv4 does not fix this flaw. ] > Ok in this case we were lucky it was all zeroes so XFS made a sparse > file and could fit a 1.9GB into 1.5GB device size. > > In general with nonzero data it seems to me you will get data > corruption because the NFS client thinks it has written the data > while the NFS server really can't write more data than the device > size. Yup, well known issue. Simple rule: don't run your NFS server out of space. > It's nice that the NFS server does local writeback caching but it > should also cache the filesystem's free space (and check it > periodically, since nfs-server is presumably not the only process > writing in that filesystem) so that it doesn't accept more data than > it can really write. Alternatively, when free space drops below 1GB > (or a reasonable size based on network speed), nfs-server should > turn off filesystem writeback caching. This isn't a NFS server problem, or one that canbe worked around at the server. it's a NFS _client_ problem in that it does not get synchronous ENOSPC errors when using writeback caching. There is no way for the NFS client to know the server is near ENOSPC conditions prior to writing the data to the server as clients operate independently. If you really want your NFS clients to behave correctly when the server goes ENOSPC, turn off writeback caching at the client side, not the server (i.e. use sync mounts on the client side). Write performance will suck, but if you want sane ENOSPC behaviour... ..... > Holes in a random file! > This is data corruption, and nobody is notified of this data > corruption: no error at client side or server side! > Is it good semantics? How could client get notified of this? Some > kind of fsync maybe? Use wireshark to determine if the server sends an ENOSPC to the client when the first background write fails. I bet it does and that your dd write failed with ENOSPC, too. Something stopped it writing at 1.9GB.... What happens to the remaining cached writeback data in the NFS client once the server runs out of space is NFS client specific behaviour. If you end up with only bits of the file on the server, ending up on the server, then that's a result of NFS client behaviour, not a NFS server problem. Cheers, Dave. -- Dave Chinner david@fromorbit.com From lczerner@redhat.com Mon Dec 6 04:18:58 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,J_CHICKENPOX_43, J_CHICKENPOX_44,J_CHICKENPOX_64,J_CHICKENPOX_66,J_CHICKENPOX_73 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB6AIwUj228103 for ; Mon, 6 Dec 2010 04:18:58 -0600 X-ASG-Debug-ID: 1291630844-1b1a02be0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1689D1C9876B for ; Mon, 6 Dec 2010 02:20:44 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 0LZDVRkFeaPSlfd2 for ; Mon, 06 Dec 2010 02:20:44 -0800 (PST) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oB6AKY2M000619 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 6 Dec 2010 05:20:34 -0500 Received: from dhcp-lab-213.englab.brq.redhat.com (dhcp-27-109.brq.redhat.com [10.34.27.109]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id oB6AKWO4015641 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 6 Dec 2010 05:20:33 -0500 Date: Mon, 6 Dec 2010 11:20:31 +0100 (CET) From: Lukas Czerner X-X-Sender: lukas@dhcp-lab-213.englab.brq.redhat.com To: Lukas Czerner cc: xfs@oss.sgi.com, esandeen@redhat.com, hch@infradead.org X-ASG-Orig-Subj: Re: [PATCH] Add test 248: Check filesystem FITRIM implementation Subject: Re: [PATCH] Add test 248: Check filesystem FITRIM implementation In-Reply-To: <1290780743-12112-1-git-send-email-lczerner@redhat.com> Message-ID: References: <1290780743-12112-1-git-send-email-lczerner@redhat.com> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1291630845 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Fri, 26 Nov 2010, Lukas Czerner wrote: > FITRIM ioctl is used on a mounted filesystem to discard (or "trim") > blocks which are not in use by the filesystem. This is useful for > solid-state drives (SSDs) and thinly-provi-sioned storage. This test > helps to verify filesystem FITRIM implementation to assure that it > does not corrupts data. > > This test creates checksums of all files in /usr/share/doc directory and > run several processes which clear its working directory on SCRATCH_MNT, > then copy everything from /usr/share/doc into its working directory, create > list of files in working directory and its checksums and compare it with the > original list of checksums. Every process works in the loop so it repeat > remove->copy->check, while fstrim tool is running simultaneously. > > Fstrim is just a helper tool which uses FITRIM ioctl to actually do the > filesystem discard. > > I found this very useful because when the FITRIM is really buggy (thus > data-destroying) the 248 test will notice, because checksums will most > likely change. Hello, what is the status of this patch ? It would be nice to get some response before someone add a new test and the patch becomes obsolete :). Thanks! -Lukas > > Signed-off-by: Lukas Czerner > --- > 248 | 163 +++++++++++++++++++++++++++++++++++++ > 248.out | 3 + > group | 1 + > src/Makefile | 2 +- > src/fstrim.c | 257 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 5 files changed, 425 insertions(+), 1 deletions(-) > create mode 100755 248 > create mode 100644 248.out > create mode 100644 src/fstrim.c > > diff --git a/248 b/248 > new file mode 100755 > index 0000000..0d2f17f > --- /dev/null > +++ b/248 > @@ -0,0 +1,163 @@ > +#!/bin/bash > +# FS QA Test No. 248 > +# > +# This test was created in order to verify filesystem FITRIM implementation. > +# By many concurrent copy and remove operations and checking that files > +# does not change after copied into SCRATCH_MNT test if FITIM implementation > +# corrupts the filesystem (data/metadata). > +# > +#----------------------------------------------------------------------- > +# Copyright 2010 (C) Red Hat, Inc., Lukas Czerner > +# > +# This program is free software; you can redistribute it and/or > +# modify it under the terms of the GNU General Public License as > +# published by the Free Software Foundation. > +# > +# This program is distributed in the hope that it would be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program; if not, write the Free Software Foundation, > +# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA > +#----------------------------------------------------------------------- > + > +owner=lczerner@redhat.com > + > +seq=`basename $0` > +echo "QA output created by $seq" > + > +here=`pwd` > +tmp=`mktemp -d` > +status=1 # failure is the default! > +trap "_cleanup; exit \$status" 0 1 3 > +trap "_destroy; exit \$status" 2 15 > +chpid=0 > +mypid=$$ > + > +# get standard environment, filters and checks > +. ./common.rc > +. ./common.filter > + > +# real QA test starts here > +_supported_fs generic > +_supported_os Linux > +_require_scratch > +_scratch_mkfs >/dev/null 2>&1 > +_scratch_mount > + > +_cleanup() > +{ > + rm -rf $tmp > +} > + > +_destroy() > +{ > + kill $pids $fstrim_pid > + wait $pids $fstrim_pid > + rm -rf $tmp > +} > + > +_destroy_fstrim() > +{ > + kill $fpid > + wait $fpid > +} > + > +fstrim_loop() > +{ > + trap "_destroy_fstrim; exit \$status" 2 15 > + fsize=$(df | grep $SCRATCH_MNT | grep $SCRATCH_DEV | awk '{print $2}') > + > + while true ; do > + step=1048576 > + start=0 > + $here/src/fstrim $SCRATCH_MNT & > + fpid=$! > + wait $fpid > + while [ $start -lt $fsize ] ; do > + $here/src/fstrim -s ${start}k -l ${step}k $SCRATCH_MNT & > + fpid=$! > + wait $fpid > + start=$(( $start + $step )) > + done > + done > +} > + > +function check_sums() { > + dir=$1 > + > + ( > + cd $SCRATCH_MNT/$p > + find -P . -xdev -type f -print0 | xargs -0 md5sum | sort -o $tmp/stress.$$.$p > + ) > + > + diff $tmp/content.sums $tmp/stress.$$.$p > + if [ $? -ne 0 ]; then > + echo "!!!Checksums has changed - Filesystem possibly corrupted!!!\n" > + kill $mypid > + fi > + rm -f $tmp/stress.$$.$p > +} > + > +function run_process() { > + local p=$1 > + repeat=10 > + > + sleep $((5*$p))s & > + export chpid=$! && wait $chpid &> /dev/null > + chpid=0 > + > + while [ $repeat -gt 0 ]; do > + > + # Remove old directories. > + rm -rf $SCRATCH_MNT/$p > + export chpid=$! && wait $chpid &> /dev/null > + > + # Copy content -> partition. > + mkdir $SCRATCH_MNT/$p > + cp -ax $content/* $SCRATCH_MNT/$p > + export chpid=$! && wait $chpid &> /dev/null > + > + check_sums > + repeat=$(( $repeat - 1 )) > + done > +} > + > +nproc=20 > +content=/usr/share/doc > + > +# Check for FITRIM support > +echo -n "Checking FITRIM support: " > +$here/src/fstrim -l 10M $SCRATCH_MNT > +[ $? -ne 0 ] && exit > +echo "done." > + > +mkdir -p $tmp > + > +( > +cd $content > +find -P . -xdev -type f -print0 | xargs -0 md5sum | sort -o $tmp/content.sums > +) > + > +echo -n "Running the test: " > +pids="" > +fstrim_loop & > +fstrim_pid=$! > +p=1 > +while [ $p -le $nproc ]; do > + run_process $p & > + pids="$pids $!" > + p=$(($p+1)) > +done > +echo "done." > + > +wait $pids > +kill $fstrim_pid > +wait $fstrim_pid > + > +status=0 > +_check_scratch_fs > + > +exit > diff --git a/248.out b/248.out > new file mode 100644 > index 0000000..880d9c7 > --- /dev/null > +++ b/248.out > @@ -0,0 +1,3 @@ > +QA output created by 248 > +Checking FITRIM support: done. > +Running the test: done. > diff --git a/group b/group > index 0f94dd9..fea84ed 100644 > --- a/group > +++ b/group > @@ -361,3 +361,4 @@ deprecated > 245 auto quick dir > 246 auto quick rw > 247 auto quick rw > +248 ioctl > diff --git a/src/Makefile b/src/Makefile > index b827bd0..885fd65 100644 > --- a/src/Makefile > +++ b/src/Makefile > @@ -17,7 +17,7 @@ LINUX_TARGETS = xfsctl bstat t_mtab getdevicesize preallo_rw_pattern_reader \ > preallo_rw_pattern_writer ftrunc trunc fs_perms testx looptest \ > locktest unwritten_mmap bulkstat_unlink_test t_stripealign \ > bulkstat_unlink_test_modified t_dir_offset t_futimens t_immutable \ > - stale_handle > + stale_handle fstrim > > SUBDIRS = > > diff --git a/src/fstrim.c b/src/fstrim.c > new file mode 100644 > index 0000000..6686c99 > --- /dev/null > +++ b/src/fstrim.c > @@ -0,0 +1,257 @@ > +/* > + * fstrim.c -- discard the part (or whole) of mounted filesystem. > + * > + * Copyright (C) 2009 Red Hat, Inc., Lukas Czerner > + * > + * This program is free software: you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation, either version 2 of the License, or > + * (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program. If not, see . > + * > + * This program uses FITRIM ioctl to discard parts or the whole filesystem > + * online (mounted). You can specify range (start and lenght) to be > + * discarded, or simply discard while filesystem. > + * > + * Usage: fstrim [options] > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > + > +#ifndef FITRIM > +struct fstrim_range { > + uint64_t start; > + uint64_t len; > + uint64_t minlen; > +}; > +#define FITRIM _IOWR('X', 121, struct fstrim_range) > +#endif > + > +const char *program_name = "fstrim"; > + > +struct options { > + struct fstrim_range *range; > + char mpoint[PATH_MAX]; > + char verbose; > +}; > + > +static void usage(void) > +{ > + fprintf(stderr, > + "Usage: %s [-s start] [-l length] [-m minimum-extent]" > + " [-v] {mountpoint}\n\t" > + "-s Starting Byte to discard from\n\t" > + "-l Number of Bytes to discard from the start\n\t" > + "-m Minimum extent length to discard\n\t" > + "-v Verbose - number of discarded bytes\n", > + program_name); > +} > + > +static void err_exit(const char *fmt, ...) > +{ > + va_list pvar; > + va_start(pvar, fmt); > + vfprintf(stderr, fmt, pvar); > + va_end(pvar); > + usage(); > + exit(EXIT_FAILURE); > +} > + > +/** > + * Get the number from argument. It can be number followed by > + * units: k|K, m|M, g|G, t|T > + */ > +static unsigned long long get_number(char **optarg) > +{ > + char *opt, *end; > + unsigned long long number, max; > + > + /* get the max to avoid overflow */ > + max = ULLONG_MAX / 1024; > + number = 0; > + opt = *optarg; > + > + if (*opt == '-') { > + err_exit("%s: %s (%s)\n", program_name, > + strerror(ERANGE), *optarg); > + } > + > + errno = 0; > + number = strtoul(opt, &end , 0); > + if (errno) > + err_exit("%s: %s (%s)\n", program_name, > + strerror(errno), *optarg); > + > + /* > + * Convert units to numbers. Fall-through stack is used for units > + * so absence of breaks is intentional. > + */ > + switch (*end) { > + case 'T': /* terabytes */ > + case 't': > + if (number > max) > + err_exit("%s: %s (%s)\n", program_name, > + strerror(ERANGE), *optarg); > + number *= 1024; > + case 'G': /* gigabytes */ > + case 'g': > + if (number > max) > + err_exit("%s: %s (%s)\n", program_name, > + strerror(ERANGE), *optarg); > + number *= 1024; > + case 'M': /* megabytes */ > + case 'm': > + if (number > max) > + err_exit("%s: %s (%s)\n", program_name, > + strerror(ERANGE), *optarg); > + number *= 1024; > + case 'K': /* kilobytes */ > + case 'k': > + if (number > max) > + err_exit("%s: %s (%s)\n", program_name, > + strerror(ERANGE), *optarg); > + number *= 1024; > + end++; > + case '\0': /* end of the string */ > + break; > + default: > + err_exit("%s: %s (%s)\n", program_name, > + strerror(EINVAL), *optarg); > + return 0; > + } > + > + if (*end != '\0') { > + err_exit("%s: %s (%s)\n", program_name, > + strerror(EINVAL), *optarg); > + } > + > + return number; > +} > + > +static int parse_opts(int argc, char **argv, struct options *opts) > +{ > + int c; > + > + while ((c = getopt(argc, argv, "s:l:m:v")) != EOF) { > + switch (c) { > + case 's': /* starting point */ > + opts->range->start = get_number(&optarg); > + break; > + case 'l': /* length */ > + opts->range->len = get_number(&optarg); > + break; > + case 'm': /* minlen */ > + opts->range->minlen = get_number(&optarg); > + break; > + case 'v': /* verbose */ > + opts->verbose = 1; > + break; > + default: > + return EXIT_FAILURE; > + } > + } > + > + return 0; > +} > + > +int main(int argc, char **argv) > +{ > + struct options *opts; > + struct stat sb; > + int fd, err = 0, ret = EXIT_FAILURE; > + > + opts = malloc(sizeof(struct options)); > + if (!opts) > + err_exit("%s: malloc(): %s\n", program_name, strerror(errno)); > + > + opts->range = NULL; > + opts->verbose = 0; > + > + if (argc > 1) > + strncpy(opts->mpoint, argv[argc - 1], sizeof(opts->mpoint)); > + > + opts->range = calloc(1, sizeof(struct fstrim_range)); > + if (!opts->range) { > + fprintf(stderr, "%s: calloc(): %s\n", program_name, > + strerror(errno)); > + goto free_opts; > + } > + > + opts->range->len = ULLONG_MAX; > + > + if (argc > 2) > + err = parse_opts(argc, argv, opts); > + > + if (err) { > + usage(); > + goto free_opts; > + } > + > + if (strnlen(opts->mpoint, 1) < 1) { > + fprintf(stderr, "%s: You have to specify mount point.\n", > + program_name); > + usage(); > + goto free_opts; > + } > + > + if (stat(opts->mpoint, &sb) == -1) { > + fprintf(stderr, "%s: %s: %s\n", program_name, > + opts->mpoint, strerror(errno)); > + usage(); > + goto free_opts; > + } > + > + if (!S_ISDIR(sb.st_mode)) { > + fprintf(stderr, "%s: %s: (%s)\n", program_name, > + opts->mpoint, strerror(ENOTDIR)); > + usage(); > + goto free_opts; > + } > + > + fd = open(opts->mpoint, O_RDONLY); > + if (fd < 0) { > + fprintf(stderr, "%s: open(%s): %s\n", program_name, > + opts->mpoint, strerror(errno)); > + goto free_opts; > + } > + > + if (ioctl(fd, FITRIM, opts->range)) { > + fprintf(stderr, "%s: FSTRIM: %s\n", program_name, > + strerror(errno)); > + goto free_opts; > + } > + > + if ((opts->verbose) && (opts->range)) > + fprintf(stdout, "%llu Bytes was trimmed\n", opts->range->len); > + > + ret = EXIT_SUCCESS; > + > +free_opts: > + if (opts) { > + if (opts->range) > + free(opts->range); > + free(opts); > + } > + > + return ret; > +} > -- From spelic@shiftmail.org Mon Dec 6 06:19:26 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,J_CHICKENPOX_43, J_CHICKENPOX_45 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB6CJQZi239796 for ; Mon, 6 Dec 2010 06:19:26 -0600 X-ASG-Debug-ID: 1291638071-568101090000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx2.isti.cnr.it (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id ADAC51C9397 for ; Mon, 6 Dec 2010 04:21:11 -0800 (PST) Received: from mx2.isti.cnr.it (mx2.isti.cnr.it [194.119.192.4]) by cuda.sgi.com with ESMTP id N6wdpLr4AeKLLJZB for ; Mon, 06 Dec 2010 04:21:11 -0800 (PST) Received: from SCRIPT-SPFWL-DAEMON.mx.isti.cnr.it by mx.isti.cnr.it (PMDF V6.5 #31825) id <01NV3O6KBVIOLS8X2Z@mx.isti.cnr.it> for xfs@oss.sgi.com; Mon, 06 Dec 2010 13:20:00 +0100 (MET) Received: from conversionlocal.isti.cnr.it by mx.isti.cnr.it (PMDF V6.5 #31825) id <01NV3O6JBJIOLVX0OJ@mx.isti.cnr.it> for xfs@oss.sgi.com; Mon, 06 Dec 2010 13:19:55 +0100 (MET) Received: from [10.0.0.61] (dynamic-adsl-84-220-171-138.clienti.tiscali.it [84.220.171.138]) by mx.isti.cnr.it (PMDF V6.5 #31826) with ESMTPSA id <01NV3O6IFH12LZNASB@mx.isti.cnr.it>; Mon, 06 Dec 2010 13:19:54 +0100 (MET) Date: Mon, 06 Dec 2010 13:20:02 +0100 From: Spelic X-ASG-Orig-Subj: NFS corruption on ENOSPC (was: Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram) Subject: NFS corruption on ENOSPC (was: Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram) In-reply-to: <20101206040940.GA16103@dastard> To: Dave Chinner Cc: "linux-kernel@vger.kernel.org" , xfs@oss.sgi.com, linux-lvm@redhat.com, linux-nfs@vger.kernel.org Message-id: <4CFCD4F2.10300@shiftmail.org> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 X-INSM-ip-source: 84.220.171.138 Auth Done References: <4CF7A539.1050206@shiftmail.org> <4CF7A9CF.2020904@shiftmail.org> <20101202230743.GZ16922@dastard> <4CF8F9BE.6000604@shiftmail.org> <20101206040940.GA16103@dastard> X-Barracuda-Connect: mx2.isti.cnr.it[194.119.192.4] X-Barracuda-Start-Time: 1291638072 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48633 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 12/06/2010 05:09 AM, Dave Chinner wrote: >> [Files become sparse at nfs-server-side upon hitting ENOSPC if NFS client uses local writeback caching] >> >> >> It's nice that the NFS server does local writeback caching but it >> should also cache the filesystem's free space (and check it >> periodically, since nfs-server is presumably not the only process >> writing in that filesystem) so that it doesn't accept more data than >> it can really write. Alternatively, when free space drops below 1GB >> (or a reasonable size based on network speed), nfs-server should >> turn off filesystem writeback caching. >> > This isn't a NFS server problem, or one that canbe worked around at > the server. it's a NFS _client_ problem in that it does not get > synchronous ENOSPC errors when using writeback caching. There is no > way for the NFS client to know the server is near ENOSPC conditions > prior to writing the data to the server as clients operate > independently. > > If you really want your NFS clients to behave correctly when the > server goes ENOSPC, turn off writeback caching at the client side, > not the server (i.e. use sync mounts on the client side). > Write performance will suck, but if you want sane ENOSPC behaviour... > > [adding NFS ML in cc] Thank you for your very clear explanation. Going without writeback cache is a problem (write performance sucks as you say), but guaranteeing to never reach ENOSPC also is hardly feasible, especially if humans are logged at client side and they are doing "whatever they want". I would suggest that either be the NFS client to do polling to see if it's near an ENOSPC and if yes disable writeback caching, or be the server to do the polling and if it finds out it's near-ENOSPC condition it sends a specific message to clients to warn them so that they can disable caching. Performed at client side wouldn't change the NFS protocol and can be good enough if one can specify how often freespace should be polled and what is the freespace threshold. Or with just one value: specify what is the max speed at which server disk can fill (next polling period can be inferred from current free space), and maybe also specify a minimum polling period (just in case). Regarding the last part of the email, perhaps I was not clear: > ..... > >> Holes in a random file! >> This is data corruption, and nobody is notified of this data >> corruption: no error at client side or server side! >> Is it good semantics? How could client get notified of this? Some >> kind of fsync maybe? >> > Use wireshark to determine if the server sends an ENOSPC to the > client when the first background write fails. I bet it does and that > your dd write failed with ENOSPC, too. Something stopped it writing > at 1.9GB.... > No, in that case I had written 15x100MB which was more than the available space but less than available+writeback_cache. So "cat" ended by itself and never got an ENOSPC error but data never reached the disk at the other side. However today I found that by using fsync, the problem is fortunately detected: # time cat randfile{001..015} | pv -b | dd conv=fsync of=/mnt/nfsram/randfile 1.46GB dd: fsync failed for `/mnt/nfsram/randfile': Input/output error 3072000+0 records in 3072000+0 records out 1572864000 bytes (1.6 GB) copied, 20.9101 s, 75.2 MB/s real 0m21.364s user 0m0.470s sys 0m11.440s so ok I understand that processes needing guarantees on written data should use fsync/fdatasync (which is good practice also for a local filesystem actually...) Thank you From trond.myklebust@fys.uio.no Mon Dec 6 07:32:22 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB6DWLMU247343 for ; Mon, 6 Dec 2010 07:32:22 -0600 X-ASG-Debug-ID: 1291642447-26d700bb0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-out1.uio.no (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1425E1C9A27 for ; Mon, 6 Dec 2010 05:34:07 -0800 (PST) Received: from mail-out1.uio.no (mail-out1.uio.no [129.240.10.57]) by cuda.sgi.com with ESMTP id HdtDnezJSwJ8nhO1 for ; Mon, 06 Dec 2010 05:34:07 -0800 (PST) Received: from mail-mx5.uio.no ([129.240.10.46]) by mail-out1.uio.no with esmtp (Exim 4.69) (envelope-from ) id 1PPbCc-00017V-S9; Mon, 06 Dec 2010 14:34:02 +0100 Received: from c-68-40-206-115.hsd1.mi.comcast.net ([68.40.206.115] helo=[192.168.1.12]) by mail-mx5.uio.no with esmtpsa (SSLv3:CAMELLIA256-SHA:256) user trondmy (Exim 4.69) (envelope-from ) id 1PPbCb-0004CF-Va; Mon, 06 Dec 2010 14:34:02 +0100 X-ASG-Orig-Subj: Re: NFS corruption on ENOSPC (was: Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram) Subject: Re: NFS corruption on ENOSPC (was: Re: Bugs in mkfs.xfs, device mapper, xfs, and /dev/ram) From: Trond Myklebust To: Spelic Cc: Dave Chinner , "linux-kernel@vger.kernel.org" , xfs@oss.sgi.com, linux-lvm@redhat.com, linux-nfs@vger.kernel.org In-Reply-To: <4CFCD4F2.10300@shiftmail.org> References: <4CF7A539.1050206@shiftmail.org> <4CF7A9CF.2020904@shiftmail.org> <20101202230743.GZ16922@dastard> <4CF8F9BE.6000604@shiftmail.org> <20101206040940.GA16103@dastard> <4CFCD4F2.10300@shiftmail.org> Content-Type: text/plain; charset="UTF-8" Date: Mon, 06 Dec 2010 08:33:55 -0500 Message-ID: <1291642435.3990.8.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 (2.32.1-1.fc14) Content-Transfer-Encoding: 7bit X-UiO-Ratelimit-Test: rcpts/h 6 msgs/h 1 sum rcpts/h 6 sum msgs/h 1 total rcpts 1231 max rcpts/h 20 ratelimit 0 X-UiO-Spam-info: not spam, SpamAssassin (score=-5.0, required=5.0, autolearn=disabled, UIO_MAIL_IS_INTERNAL=-5, uiobl=NO, uiouri=NO) X-UiO-Scanned: DD6A827C3B7EFB58D1A1EA143A7B28E6DA7DFADD X-UiO-SPAM-Test: remote_host: 68.40.206.115 spam_score: -49 maxlevel 80 minaction 2 bait 0 mail/h: 1 total 485 max/h 7 blacklist 0 greylist 0 ratelimit 0 X-Barracuda-Connect: mail-out1.uio.no[129.240.10.57] X-Barracuda-Start-Time: 1291642448 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48638 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mon, 2010-12-06 at 13:20 +0100, Spelic wrote: > On 12/06/2010 05:09 AM, Dave Chinner wrote: > >> [Files become sparse at nfs-server-side upon hitting ENOSPC if NFS client uses local writeback caching] > >> > >> > >> It's nice that the NFS server does local writeback caching but it > >> should also cache the filesystem's free space (and check it > >> periodically, since nfs-server is presumably not the only process > >> writing in that filesystem) so that it doesn't accept more data than > >> it can really write. Alternatively, when free space drops below 1GB > >> (or a reasonable size based on network speed), nfs-server should > >> turn off filesystem writeback caching. > >> > > This isn't a NFS server problem, or one that canbe worked around at > > the server. it's a NFS _client_ problem in that it does not get > > synchronous ENOSPC errors when using writeback caching. There is no > > way for the NFS client to know the server is near ENOSPC conditions > > prior to writing the data to the server as clients operate > > independently. > > > > If you really want your NFS clients to behave correctly when the > > server goes ENOSPC, turn off writeback caching at the client side, > > not the server (i.e. use sync mounts on the client side). > > Write performance will suck, but if you want sane ENOSPC behaviour... > > > > > > [adding NFS ML in cc] > > Thank you for your very clear explanation. > > Going without writeback cache is a problem (write performance sucks as > you say), but guaranteeing to never reach ENOSPC also is hardly > feasible, especially if humans are logged at client side and they are > doing "whatever they want". > > I would suggest that either be the NFS client to do polling to see if > it's near an ENOSPC and if yes disable writeback caching, or be the > server to do the polling and if it finds out it's near-ENOSPC condition > it sends a specific message to clients to warn them so that they can > disable caching. > Performed at client side wouldn't change the NFS protocol and can be > good enough if one can specify how often freespace should be polled and > what is the freespace threshold. Or with just one value: specify what is > the max speed at which server disk can fill (next polling period can be > inferred from current free space), and maybe also specify a minimum > polling period (just in case). You can just as easily do this at the application level. The kernel can't do it any more reliably than the application can, so there really is no point in doing it there. We already ensure that when the server does send us an error, we switch to synchronous operation until the error clears. Trond From BATV+97ff857f1b70a67ae353+2661+infradead.org+hch@bombadil.srs.infradead.org Mon Dec 6 08:31:26 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB6EVPfD253779 for ; Mon, 6 Dec 2010 08:31:26 -0600 X-ASG-Debug-ID: 1291645991-3c7401ec0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D6C06141E06F for ; Mon, 6 Dec 2010 06:33:12 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id LBcv47EQwPNQ9gxW for ; Mon, 06 Dec 2010 06:33:12 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PPc7o-0002pv-AV; Mon, 06 Dec 2010 14:33:08 +0000 Date: Mon, 6 Dec 2010 09:33:08 -0500 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 6/8] xfs: remove all the inodes on a buffer from the AIL in bulk Subject: Re: [PATCH 6/8] xfs: remove all the inodes on a buffer from the AIL in bulk Message-ID: <20101206143308.GA31100@infradead.org> References: <1290993152-20999-1-git-send-email-david@fromorbit.com> <1290993152-20999-7-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1290993152-20999-7-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291645992 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean While the patch looks good for the ail lock contetion removal, I don't quite like the model with the double iteration over the log item list on the buffer. What do you think about the following plan: (1) merge xfs_istale_done into xfs_iflush_done by checking for XFS_ISTALE (2) convert not only the inode log item completion to your new scheme, but also the dquots (3) replace xfs_buf_do_callbacks with a callback in the buffer, which now points to the inode and dqout routines, or calls the completion for the only items in "normal" buf items. From BATV+97ff857f1b70a67ae353+2661+infradead.org+hch@bombadil.srs.infradead.org Mon Dec 6 08:34:00 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB6EY0C2254237 for ; Mon, 6 Dec 2010 08:34:00 -0600 X-ASG-Debug-ID: 1291646147-16f103620000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CC4B11C99F6D for ; Mon, 6 Dec 2010 06:35:47 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 4daKGhDhP2kgfAff for ; Mon, 06 Dec 2010 06:35:47 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PPcAL-0003fV-Ag; Mon, 06 Dec 2010 14:35:45 +0000 Date: Mon, 6 Dec 2010 09:35:45 -0500 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 7/8] xfs: use AIL bulk update function to implement single updates Subject: Re: [PATCH 7/8] xfs: use AIL bulk update function to implement single updates Message-ID: <20101206143545.GB31100@infradead.org> References: <1290993152-20999-1-git-send-email-david@fromorbit.com> <1290993152-20999-8-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1290993152-20999-8-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291646147 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mon, Nov 29, 2010 at 12:12:31PM +1100, Dave Chinner wrote: > From: Dave Chinner > > We now have two copies of AIL insert operations that are mostly > duplicate functionality. The single log item updates can be > implemented via the bulk updates by turning xfs_trans_ail_update() > into a simple wrapper. This removes all the duplicate insert > functionality and associated helpers. Looks good, although the comment above xfs_trans_ail_update_bulk, stating it's the bulk version of xfs_trans_ail_update isn't too helpful any more after this patch. From BATV+97ff857f1b70a67ae353+2661+infradead.org+hch@bombadil.srs.infradead.org Mon Dec 6 08:35:45 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB6EZjdK254396 for ; Mon, 6 Dec 2010 08:35:45 -0600 X-ASG-Debug-ID: 1291646252-2721031c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0B9CD1C9E60 for ; Mon, 6 Dec 2010 06:37:32 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id N78lAO2PE4GdFk5P for ; Mon, 06 Dec 2010 06:37:32 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PPcC4-0003gP-Ec; Mon, 06 Dec 2010 14:37:32 +0000 Date: Mon, 6 Dec 2010 09:37:32 -0500 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 8/8] xfs: use AIL bulk delete function to implement single delete Subject: Re: [PATCH 8/8] xfs: use AIL bulk delete function to implement single delete Message-ID: <20101206143732.GC31100@infradead.org> References: <1290993152-20999-1-git-send-email-david@fromorbit.com> <1290993152-20999-9-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1290993152-20999-9-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291646253 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean > -/* > * Bulk update version of xfs_trans_ail_delete > * > * This version takes an array of log items that all need to removed from the > * AIL. The caller is already holding the AIL lock, and done all the checks Not overly useful now that the non-bulk version is gone. > * necessary to ensure the items passed in via @lgia are ready for deletion. > + * If an item we delete in the AIL is the minimum one, update the tail lsn in > + * the log manager. > * > * This function will not drop the AIL lock until all items are removed from > * the AIL to minimise the amount of lock traffic on the AIL. This does not > * greatly increase the AIL hold time, but does significantly reduce the amount > * of traffic on the lock, especially during IO completion. > + * > + * This function must be called with the AIL lock held. The lock is dropped > + * before returning. These should be in the patch introducing xfs_trans_ail_delete_bulk. Otherwise looks good. From SRS0+od1M+10+fromorbit.com=david@internode.on.net Mon Dec 6 21:43:21 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB73hIL9080590 for ; Mon, 6 Dec 2010 21:43:20 -0600 X-ASG-Debug-ID: 1291693501-5ff8039a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8C97E14223AA for ; Mon, 6 Dec 2010 19:45:01 -0800 (PST) Received: from mail.internode.on.net (bld-mail15.adl6.internode.on.net [150.101.137.100]) by cuda.sgi.com with ESMTP id UCW5xyiDAmzbiR6G for ; Mon, 06 Dec 2010 19:45:01 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 37555951-1927428 for multiple; Tue, 07 Dec 2010 14:14:59 +1030 (CDT) Received: from dave by dastard with local (Exim 4.71) (envelope-from ) id 1PPoU4-00067W-IC; Tue, 07 Dec 2010 14:44:56 +1100 Date: Tue, 7 Dec 2010 14:44:56 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 6/8] xfs: remove all the inodes on a buffer from the AIL in bulk Subject: Re: [PATCH 6/8] xfs: remove all the inodes on a buffer from the AIL in bulk Message-ID: <20101207034456.GB29856@dastard> References: <1290993152-20999-1-git-send-email-david@fromorbit.com> <1290993152-20999-7-git-send-email-david@fromorbit.com> <20101206143308.GA31100@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101206143308.GA31100@infradead.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: bld-mail15.adl6.internode.on.net[150.101.137.100] X-Barracuda-Start-Time: 1291693503 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48695 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Mon, Dec 06, 2010 at 09:33:08AM -0500, Christoph Hellwig wrote: > While the patch looks good for the ail lock contetion removal, I don't > quite like the model with the double iteration over the log item list > on the buffer. What do you think about the following plan: > > (1) merge xfs_istale_done into xfs_iflush_done by checking for > XFS_ISTALE > (2) convert not only the inode log item completion to your new scheme, > but also the dquots > (3) replace xfs_buf_do_callbacks with a callback in the buffer, which > now points to the inode and dqout routines, or calls the completion > for the only items in "normal" buf items. Seems like a reasonable approach. However, what I'd prefer to do is make these changes as a separate set of changes on top of this patch series rather than try to integrate them into the existing series. If there are problems, that should make it more bisectable. Do you have any concerns with such an approach? Cheers, Dave. -- Dave Chinner david@fromorbit.com From BATV+4931a86851e2f3a4cf07+2662+infradead.org+hch@bombadil.srs.infradead.org Tue Dec 7 01:37:42 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB77beIw110659 for ; Tue, 7 Dec 2010 01:37:42 -0600 X-ASG-Debug-ID: 1291707567-68e502950000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DCFD31CCE47 for ; Mon, 6 Dec 2010 23:39:27 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 6bCEHQveucwoZ16s for ; Mon, 06 Dec 2010 23:39:27 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PPs8z-0006Bx-HJ; Tue, 07 Dec 2010 07:39:25 +0000 Date: Tue, 7 Dec 2010 02:39:25 -0500 From: Christoph Hellwig To: Dave Chinner Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 6/8] xfs: remove all the inodes on a buffer from the AIL in bulk Subject: Re: [PATCH 6/8] xfs: remove all the inodes on a buffer from the AIL in bulk Message-ID: <20101207073925.GA25617@infradead.org> References: <1290993152-20999-1-git-send-email-david@fromorbit.com> <1290993152-20999-7-git-send-email-david@fromorbit.com> <20101206143308.GA31100@infradead.org> <20101207034456.GB29856@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101207034456.GB29856@dastard> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291707567 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Tue, Dec 07, 2010 at 02:44:56PM +1100, Dave Chinner wrote: > On Mon, Dec 06, 2010 at 09:33:08AM -0500, Christoph Hellwig wrote: > > While the patch looks good for the ail lock contetion removal, I don't > > quite like the model with the double iteration over the log item list > > on the buffer. What do you think about the following plan: > > > > (1) merge xfs_istale_done into xfs_iflush_done by checking for > > XFS_ISTALE > > (2) convert not only the inode log item completion to your new scheme, > > but also the dquots > > (3) replace xfs_buf_do_callbacks with a callback in the buffer, which > > now points to the inode and dqout routines, or calls the completion > > for the only items in "normal" buf items. > > Seems like a reasonable approach. However, what I'd prefer to do is > make these changes as a separate set of changes on top of this patch > series rather than try to integrate them into the existing series. > If there are problems, that should make it more bisectable. Do you > have any concerns with such an approach? Sounds fine, although I think getting rid of xfs_istale_done might be worth doing before this patch. From BATV+4931a86851e2f3a4cf07+2662+infradead.org+hch@bombadil.srs.infradead.org Tue Dec 7 04:14:55 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB7AEsZv130564 for ; Tue, 7 Dec 2010 04:14:55 -0600 X-ASG-Debug-ID: 1291717002-1c93015b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6FEEA1423160 for ; Tue, 7 Dec 2010 02:16:42 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id JVaSI3a18hijb6ys for ; Tue, 07 Dec 2010 02:16:42 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PPubB-0006lK-PW for xfs@oss.sgi.com; Tue, 07 Dec 2010 10:16:41 +0000 Date: Tue, 7 Dec 2010 05:16:41 -0500 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH] xfs: log timestamp changes to the source inode in rename Subject: [PATCH] xfs: log timestamp changes to the source inode in rename Message-ID: <20101207101641.GA25995@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291717002 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Now that we don't mark VFS inodes dirty anymore for internal timestamp changes, but rely on the transaction subsystem to push them out, we need to explicitly log the source inode in rename after updating it's timestamps to make sure the changes actually get forced out by sync/fsync or an AIL push. We already account for the fourth inode in the log reservation, as a rename of directories needs to update the nlink field, so just adding the xfs_trans_log_inode call is enough. This fixes the xfsqa 065 regression introduced by: "xfs: don't use vfs writeback for pure metadata modifications" Signed-off-by: Christoph Hellwig Index: xfs/fs/xfs/xfs_rename.c =================================================================== --- xfs.orig/fs/xfs/xfs_rename.c 2010-12-07 11:05:15.661253391 +0100 +++ xfs/fs/xfs/xfs_rename.c 2010-12-07 11:05:25.139275042 +0100 @@ -297,6 +297,7 @@ xfs_rename( * it and some incremental backup programs won't work without it. */ xfs_trans_ichgtime(tp, src_ip, XFS_ICHGTIME_CHG); + xfs_trans_log_inode(tp, src_ip, XFS_ILOG_CORE); /* * Adjust the link count on src_dp. This is necessary when From BATV+4931a86851e2f3a4cf07+2662+infradead.org+hch@bombadil.srs.infradead.org Tue Dec 7 04:16:01 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB7AG0P5130685 for ; Tue, 7 Dec 2010 04:16:01 -0600 X-ASG-Debug-ID: 1291717068-146d01750000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BE3EF1C9DEC0 for ; Tue, 7 Dec 2010 02:17:48 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id zgCck5NhE37CF9WS for ; Tue, 07 Dec 2010 02:17:48 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PPucE-0006mA-IV; Tue, 07 Dec 2010 10:17:46 +0000 Date: Tue, 7 Dec 2010 05:17:46 -0500 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/2] xfs: dynamic speculative EOF preallocation Subject: Re: [PATCH 1/2] xfs: dynamic speculative EOF preallocation Message-ID: <20101207101746.GB25995@infradead.org> References: <1290991431-20519-1-git-send-email-david@fromorbit.com> <1290991431-20519-2-git-send-email-david@fromorbit.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1290991431-20519-2-git-send-email-david@fromorbit.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291717068 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean I need the patch below to make the new code link on 32-bit systems: Index: xfs/fs/xfs/xfs_mount.c =================================================================== --- xfs.orig/fs/xfs/xfs_mount.c 2010-12-07 11:01:50.394021585 +0100 +++ xfs/fs/xfs/xfs_mount.c 2010-12-07 11:02:46.231256257 +0100 @@ -1111,7 +1111,10 @@ xfs_set_low_space_thresholds( int i; for (i = 0; i < XFS_LOWSP_MAX; i++) { - mp->m_low_space[i] = mp->m_sb.sb_dblocks / 100 * (i + 1); + __uint64_t space = mp->m_sb.sb_dblocks; + do_div(space, 100); + + mp->m_low_space[i] = space * (i + 1); } } From SRS0+8zW4+10+fromorbit.com=david@internode.on.net Tue Dec 7 04:48:11 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB7AmA6Y135501 for ; Tue, 7 Dec 2010 04:48:11 -0600 X-ASG-Debug-ID: 1291718996-5bec00060000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B616A1C9E0C9 for ; Tue, 7 Dec 2010 02:49:56 -0800 (PST) Received: from mail.internode.on.net (bld-mail12.adl6.internode.on.net [150.101.137.97]) by cuda.sgi.com with ESMTP id x5az2KiRp6qBzdy4 for ; Tue, 07 Dec 2010 02:49:56 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 49102023-1927428 for multiple; Tue, 07 Dec 2010 21:19:54 +1030 (CDT) Received: from dave by dastard with local (Exim 4.71) (envelope-from ) id 1PPv7I-0006d3-Rt; Tue, 07 Dec 2010 21:49:52 +1100 Date: Tue, 7 Dec 2010 21:49:52 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 1/2] xfs: dynamic speculative EOF preallocation Subject: Re: [PATCH 1/2] xfs: dynamic speculative EOF preallocation Message-ID: <20101207104952.GC16103@dastard> References: <1290991431-20519-1-git-send-email-david@fromorbit.com> <1290991431-20519-2-git-send-email-david@fromorbit.com> <20101207101746.GB25995@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101207101746.GB25995@infradead.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: bld-mail12.adl6.internode.on.net[150.101.137.97] X-Barracuda-Start-Time: 1291718997 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48724 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Tue, Dec 07, 2010 at 05:17:46AM -0500, Christoph Hellwig wrote: > I need the patch below to make the new code link on 32-bit systems: > > Index: xfs/fs/xfs/xfs_mount.c > =================================================================== > --- xfs.orig/fs/xfs/xfs_mount.c 2010-12-07 11:01:50.394021585 +0100 > +++ xfs/fs/xfs/xfs_mount.c 2010-12-07 11:02:46.231256257 +0100 > @@ -1111,7 +1111,10 @@ xfs_set_low_space_thresholds( > int i; > > for (i = 0; i < XFS_LOWSP_MAX; i++) { > - mp->m_low_space[i] = mp->m_sb.sb_dblocks / 100 * (i + 1); > + __uint64_t space = mp->m_sb.sb_dblocks; > + do_div(space, 100); > + > + mp->m_low_space[i] = space * (i + 1); > } > } Yes, makes sense. I'll fold that into the latest version of the patch. Thanks. Cheers, Dave. -- Dave Chinner david@fromorbit.com From SRS0+h4DP+10+fromorbit.com=david@internode.on.net Tue Dec 7 05:18:48 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB7BIlMh139444 for ; Tue, 7 Dec 2010 05:18:47 -0600 X-ASG-Debug-ID: 1291720832-5bec014e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 119A31C9DEDD for ; Tue, 7 Dec 2010 03:20:32 -0800 (PST) Received: from mail.internode.on.net (bld-mail19.adl2.internode.on.net [150.101.137.104]) by cuda.sgi.com with ESMTP id RvH89D5X3JzyN0tm for ; Tue, 07 Dec 2010 03:20:32 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 48482674-1927428 for multiple; Tue, 07 Dec 2010 21:50:31 +1030 (CDT) Received: from dave by dastard with local (Exim 4.71) (envelope-from ) id 1PPvav-0006hA-Tr; Tue, 07 Dec 2010 22:20:29 +1100 Date: Tue, 7 Dec 2010 22:20:24 +1100 From: Dave Chinner To: Ajeet Yadav Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS mount fail: XFS_WANT_CORRUPTED_GOTO fs/xfs/xfs_alloc.c Subject: Re: XFS mount fail: XFS_WANT_CORRUPTED_GOTO fs/xfs/xfs_alloc.c Message-ID: <20101207112024.GD16103@dastard> References: <20101202224506.GY16922@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: bld-mail19.adl2.internode.on.net[150.101.137.104] X-Barracuda-Start-Time: 1291720835 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48726 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Sat, Dec 04, 2010 at 09:49:25AM +0530, Ajeet Yadav wrote: > Our test case is automated: > 1. Create large number of file of 6KB sizes ( 6KB is taken, we wanted to > increase journal load, and file size not in multiple of file system block > size) > 2. Set target to reboot at random seconds seconds. > 3. Next boot do "ls" of all files in XFS partition. > 4. Remove all files in XFS. > 5. Go back to step 1 > > The purpose of this test is to test journal and stability of XFS filestem. > > Do you think, we should consider this test case ? Are you running with barriers enabled? What are your mkfs and mount options? Also, does the problem exist on a current kernel? We've fixed lots of writeback related problems since 2.6.30, so I'd suggest that you need to reproduce this on a current kernel before anyone will spend large amounts of time trying to track it down. Especially as xfstests 136-140 do similar testing (just without the reboots) and don't show any problems. > Other is when we should run xfs_repair ? because if mount fails and journal > contain dirty logs then xfs_repair does not run, we are forced to use (-L) > option but its description say that (-L) can corrupt the file system. Yes, it can. > Other case even if xfs mount successfully, even in that case accessing some > files give IO input/ output error. Which means something got corrupted. Look in dmesg for reasons why. > 1. I recommend the following usage for xfs_repair so that we do not come > accross these problem > Mount Success -> Umount -> run xfs_repair -> mount > Mount fails -> try xfs_repair -> xfs_repair fails -> finally xfs_repair > -L -> mount > > Adding above mount + xfs_repair procedure to script makes file system > stable. But other member of my team do not agree as it increases mount time. I agree with your team members. All you are proposing to do is to hide failures that need further investigation... Cheers, Dave. -- Dave Chinner david@fromorbit.com From lists@nabble.com Tue Dec 7 05:48:04 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, T_TO_NO_BRKTS_FREEMAIL autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB7Bm4nq142847 for ; Tue, 7 Dec 2010 05:48:04 -0600 X-ASG-Debug-ID: 1291722589-747a01590000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from kuber.nabble.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E38A21420CC4 for ; Tue, 7 Dec 2010 03:49:49 -0800 (PST) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by cuda.sgi.com with ESMTP id 4YfOpZ4QxrDUPZdy for ; Tue, 07 Dec 2010 03:49:49 -0800 (PST) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1PPw3J-0000DU-CT for xfs@oss.sgi.com; Tue, 07 Dec 2010 03:49:49 -0800 Message-ID: <30395558.post@talk.nabble.com> Date: Tue, 7 Dec 2010 03:49:49 -0800 (PST) From: blacknred To: xfs@oss.sgi.com X-ASG-Orig-Subj: possible xfs corruption Subject: possible xfs corruption MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: leo1783@hotmail.co.uk X-Barracuda-Connect: kuber.nabble.com[216.139.236.158] X-Barracuda-Start-Time: 1291722590 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48727 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hi... I'm stuck with a storage issue on reboot. Initially doubted the storage, but dmesg throws these errors. Now wondering whether this is a fs issue? Any thoughts as to whats going on here? XFS: failed to locate log tail XFS: log mount/recovery failed: error 117 XFS: log mount failed XFS mounting filesystem cciss/c0d0 Filesystem "cciss/c0d0": XFS internal error xlog_clear_stale_blocks(2) at line 1237 of file /home/buildsvn/rpmbuild/BUILD/xfs-kmod-0.4/_kmod_build_PAE/xfs_log_recover.c. Caller 0xf8aa7892 [] xlog_find_tail+0x91b/0xa4a [xfs] [] xlog_recover+0x15/0x20b [xfs] [] xlog_recover+0x15/0x20b [xfs] [] xfs_buf_get_empty+0x2a/0x33 [xfs] [] xfs_log_mount+0x467/0x4ab [xfs] [] kmem_zalloc+0xd/0x34 [xfs] [] xfs_mountfs+0x9f5/0xdfb [xfs] [] xfs_fs_vcmn_err+0x5f/0x83 [xfs] [] xfs_mountfs_check_barriers+0xb8/0xd0 [xfs] [] xfs_mount+0x75e/0x82a [xfs] [] xfs_mount+0x0/0x82a [xfs] [] vfs_mount+0x17/0x1a [xfs] [] xfs_fs_fill_super+0x68/0x1a5 [xfs] [] snprintf+0x1c/0x1f [] disk_name+0x56/0x60 [] get_sb_bdev+0xc6/0x113 [] xfs_fs_get_sb+0x12/0x16 [xfs] [] xfs_fs_fill_super+0x0/0x1a5 [xfs] [] vfs_kern_mount+0x7d/0xf2 [] do_kern_mount+0x25/0x36 [] do_mount+0x5fb/0x66b [] avc_has_perm+0x3c/0x46 [] avc_has_perm+0x3c/0x46 [] selinux_inode_alloc_security+0x50/0x7b [] inode_doinit_with_dentry+0x8a/0x495 [] get_page_from_freelist+0x96/0x370 [] __alloc_pages+0x69/0x2cf [] copy_mount_options+0x26/0x109 [] sys_mount+0x6d/0xa5 [] sysenter_past_esp+0x56/0x79 Thanks in advance David -- View this message in context: http://old.nabble.com/possible-xfs-corruption-tp30395558p30395558.html Sent from the Xfs - General mailing list archive at Nabble.com. From btharindu@gmail.com Tue Dec 7 06:55:36 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_00,FREEMAIL_FROM, HTML_MESSAGE,T_DKIM_INVALID,T_TO_NO_BRKTS_FREEMAIL autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB7CtaG2150672 for ; Tue, 7 Dec 2010 06:55:36 -0600 X-ASG-Debug-ID: 1291726643-52c203e60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-iw0-f181.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CFA491CDA77 for ; Tue, 7 Dec 2010 04:57:23 -0800 (PST) Received: from mail-iw0-f181.google.com (mail-iw0-f181.google.com [209.85.214.181]) by cuda.sgi.com with ESMTP id 2GbNeLkF4qPrSo0n for ; Tue, 07 Dec 2010 04:57:23 -0800 (PST) Received: by iwn3 with SMTP id 3so17007803iwn.26 for ; Tue, 07 Dec 2010 04:57:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:from:date :message-id:subject:to:content-type; bh=RbW+Ep3b0vEEDqooeiC1RmPIWtg5SlNw0Cfne/Bnueo=; b=jYjHcbAz8mAB7g7KMJEnpduCsJX0GHasHwJGbANcQoaxWm1C5ngT7yCAE+XsrrO4Mp encXXh9d+ciJAYiMFzrub+kxL0zjPuiYeFfmEo0rxnVbe/zgnzuzz2pfRy91TGI3Dxnx hqPImwI2KkMIKhq9Dx0wtAxJ8GNpyBYKgsJqo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=tO0UJggW0wHptJG6G7gWND3JraB1B9kZW1rhWfQLxnncH4GMx/J+HGeD8den3ohler tgGxx5nt0qwtM2Eh1eZeYnd6nCsMoVAxSRVnCIj2dn0Cqe/Q8wcuHwpzwTZH3NzmvhFN baNbJtO8GIbfpGeOcE4folnaPBz9g4g03R8EM= Received: by 10.231.20.70 with SMTP id e6mr7418786ibb.199.1291726642964; Tue, 07 Dec 2010 04:57:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.12.4 with HTTP; Tue, 7 Dec 2010 04:56:52 -0800 (PST) From: Tharindu Rukshan Bamunuarachchi Date: Tue, 7 Dec 2010 18:26:52 +0530 Message-ID: X-ASG-Orig-Subj: xfs_count_page_state inside kswapd Subject: xfs_count_page_state inside kswapd To: xfs@oss.sgi.com Content-Type: multipart/alternative; boundary=000325576092b36b900496d18bf6 X-Barracuda-Connect: mail-iw0-f181.google.com[209.85.214.181] X-Barracuda-Start-Time: 1291726643 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M, DKIM_SIGNED, DKIM_VERIFIED, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48732 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.00 HTML_MESSAGE BODY: HTML included in message 0.50 BSF_RULE7568M Custom Rule 7568M X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --000325576092b36b900496d18bf6 Content-Type: text/plain; charset=UTF-8 Dear All, We got following oops in one of our SLES 11 server. This occurred inside swapd and we running our server swap turned off.. Could this be memory corruption or possible old bug in code ? Please help. Thanks Dec 6 22:55:46 tm-spes-md102 kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 Dec 6 22:55:46 tm-spes-md102 kernel: IP: [] xfs_count_page_state+0x25/0x66 [xfs] Dec 6 22:55:46 tm-spes-md102 kernel: PGD 37dc4e067 PUD 16f631067 PMD 0 Dec 6 22:55:46 tm-spes-md102 kernel: Oops: 0000 [1] SMP Dec 6 22:55:46 tm-spes-md102 kernel: last sysfs file: /sys/devices/pci0000:00/0000:00:03.0/0000:15:00.0/infiniband/mlx4_0/node_type Dec 6 22:55:46 tm-spes-md102 kernel: CPU 2 Dec 6 22:55:46 tm-spes-md102 kernel: Modules linked in: af_packet st ide_disk ide_cd_mod lp parport_pc ppdev parport nfs lockd nfs_acl sunrpc ipmi_devintf ipmi_si ipmi_msghandler bonding microcode binfmt_misc rdma_ucm(N) ib_sdp(N) rdma_cm(N) iw_cm(N) ib_addr(N) ib_ipoib( N) ib_cm(N) ib_sa(N) ipv6 ib_uverbs(N) ib_umad(N) mlx4_en(N) mlx4_ib(N) ib_mthca(N) ib_mad(N) ib_core(N) fuse ext2 xfs loop dm_mod joyde v cdc_ether rtc_cmos usbhid usbnet rtc_core mlx4_core(N) hid shpchp i2c_i801 pci_hotplug button pcspkr mii sr_mod i2c_core rtc_lib ff_me mless cdrom sg uhci_hcd sd_mod ehci_hcd crc_t10dif usbcore edd ext3 mbcache jbd fan thermal processor thermal_sys hwmon ide_pci_generic ide_core ata_generic ata_piix libata dock megaraid_sas scsi_mod [last unloaded: parport_pc] Dec 6 22:55:46 tm-spes-md102 kernel: Supported: No, Unsupported modules are loaded Dec 6 22:55:46 tm-spes-md102 kernel: Pid: 58, comm: kswapd0 Tainted: G 2.6.27.45-0.1-default #1 Dec 6 22:55:46 tm-spes-md102 kernel: RIP: 0010:[] [] xfs_count_page_state+0x25/0x66 [xfs] Dec 6 22:55:46 tm-spes-md102 kernel: RSP: 0018:ffff88037cdcbbe8 EFLAGS: 00010207 Dec 6 22:55:46 tm-spes-md102 kernel: RAX: ffff88038ceff610 RBX: ffffe20012c30b40 RCX: ffff88037cdcbc34 Dec 6 22:55:46 tm-spes-md102 kernel: RDX: ffff88037cdcbc38 RSI: ffff88037cdcbc3c RDI: ffffe20012c30b40 Dec 6 22:55:46 tm-spes-md102 kernel: RBP: 0000000000000000 R08: 0000000000000021 R09: 0000000000000000 Dec 6 22:55:46 tm-spes-md102 kernel: R10: ffff88038ceff678 R11: ffffffffa0251b18 R12: ffff880517690480 Dec 6 22:55:46 tm-spes-md102 kernel: R13: ffff88037cdcbce0 R14: 00000000002548c2 R15: ffff880517690590 Dec 6 22:55:46 tm-spes-md102 kernel: FS: 0000000000000000(0000) GS:ffff88037e520e40(0000) knlGS:0000000000000000 Dec 6 22:55:46 tm-spes-md102 kernel: CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b Dec 6 22:55:46 tm-spes-md102 kernel: CR2: 0000000000000000 CR3: 000000016f670000 CR4: 00000000000006e0 Dec 6 22:55:46 tm-spes-md102 kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 Dec 6 22:55:46 tm-spes-md102 kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Dec 6 22:55:46 tm-spes-md102 kernel: Process kswapd0 (pid: 58, threadinfo ffff88037cdca000, task ffff88037cdc8780) Dec 6 22:55:47 tm-spes-md102 kernel: Stack: ffffffffa0251b68 0000000000000000 0000000000000001 0000000000000000 Dec 6 22:55:47 tm-spes-md102 kernel: 0000000000000001 0000000000000000 0000000000000000 0000000000000000 Dec 6 22:55:47 tm-spes-md102 kernel: 0000000000000000 00000000002acfa4 0000000000000000 ffffe20012c30b40 Dec 6 22:55:47 tm-spes-md102 kernel: Call Trace: Dec 6 22:55:47 tm-spes-md102 kernel: [] xfs_vm_releasepage+0x50/0xa5 [xfs] Dec 6 22:55:47 tm-spes-md102 kernel: [] __invalidate_mapping_pages+0x98/0x12d Dec 6 22:55:47 tm-spes-md102 kernel: [] prune_icache+0xe7/0x1f7 Dec 6 22:55:47 tm-spes-md102 kernel: [] shrink_icache_memory+0x15/0x32 Dec 6 22:55:47 tm-spes-md102 kernel: [] shrink_slab+0xe4/0x157 Dec 6 22:55:47 tm-spes-md102 kernel: [] balance_pgdat+0x292/0x3d6 Dec 6 22:55:53 tm-spes-md102 kernel: [] kswapd+0x12a/0x12c Dec 6 22:55:53 tm-spes-md102 kernel: [] kthread+0x47/0x73 Dec 6 22:55:53 tm-spes-md102 kernel: [] child_rip+0xa/0x11 Dec 6 22:55:53 tm-spes-md102 kernel: Dec 6 22:55:53 tm-spes-md102 kernel: Dec 6 22:55:53 tm-spes-md102 kernel: Code: 1f eb ef 90 90 90 c7 01 00 00 00 00 c7 02 00 00 00 00 c7 06 00 00 00 00 48 8b 07 f6 c4 10 75 04 0f 0b eb fe 48 8b 47 10 49 89 c1 <4d> 8b 01 41 f6 c0 01 74 0e 41 f6 c0 20 75 08 c7 02 01 00 00 00 Dec 6 22:55:53 tm-spes-md102 kernel: RIP [] xfs_count_page_state+0x25/0x66 [xfs] Dec 6 22:55:53 tm-spes-md102 kernel: RSP Dec 6 22:55:53 tm-spes-md102 kernel: CR2: 0000000000000000 __ Tharindu *R* Bamunuarachchi. --000325576092b36b900496d18bf6 Content-Type: text/html; charset=UTF-8 Dear All,

We got following oops in one of our SLES 11 server. This occurred inside swapd and we running our server swap turned off..

Could this be memory corruption or possible old bug in code ?

Please help.
Thanks

Dec 6 22:55:46 tm-spes-md102 kernel: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
Dec 6 22:55:46 tm-spes-md102 kernel: IP: [<ffffffffa0250659>] xfs_count_page_state+0x25/0x66 [xfs]
Dec 6 22:55:46 tm-spes-md102 kernel: PGD 37dc4e067 PUD 16f631067 PMD 0
Dec 6 22:55:46 tm-spes-md102 kernel: Oops: 0000 [1] SMP
Dec 6 22:55:46 tm-spes-md102 kernel: last sysfs file: /sys/devices/pci0000:00/0000:00:03.0/0000:15:00.0/infiniband/mlx4_0/node_type
Dec 6 22:55:46 tm-spes-md102 kernel: CPU 2
Dec 6 22:55:46 tm-spes-md102 kernel: Modules linked in: af_packet st ide_disk ide_cd_mod lp parport_pc ppdev parport nfs lockd nfs_acl
sunrpc ipmi_devintf ipmi_si ipmi_msghandler bonding microcode binfmt_misc rdma_ucm(N) ib_sdp(N) rdma_cm(N) iw_cm(N) ib_addr(N) ib_ipoib(
N) ib_cm(N) ib_sa(N) ipv6 ib_uverbs(N) ib_umad(N) mlx4_en(N) mlx4_ib(N) ib_mthca(N) ib_mad(N) ib_core(N) fuse ext2 xfs loop dm_mod joyde
v cdc_ether rtc_cmos usbhid usbnet rtc_core mlx4_core(N) hid shpchp i2c_i801 pci_hotplug button pcspkr mii sr_mod i2c_core rtc_lib ff_me
mless cdrom sg uhci_hcd sd_mod ehci_hcd crc_t10dif usbcore edd ext3 mbcache jbd fan thermal processor thermal_sys hwmon ide_pci_generic
ide_core ata_generic ata_piix libata dock megaraid_sas scsi_mod [last unloaded: parport_pc]
Dec 6 22:55:46 tm-spes-md102 kernel: Supported: No, Unsupported modules are loaded
Dec 6 22:55:46 tm-spes-md102 kernel: Pid: 58, comm: kswapd0 Tainted: G 2.6.27.45-0.1-default #1
Dec 6 22:55:46 tm-spes-md102 kernel: RIP: 0010:[<ffffffffa0250659>] [<ffffffffa0250659>] xfs_count_page_state+0x25/0x66 [xfs]
Dec 6 22:55:46 tm-spes-md102 kernel: RSP: 0018:ffff88037cdcbbe8 EFLAGS: 00010207
Dec 6 22:55:46 tm-spes-md102 kernel: RAX: ffff88038ceff610 RBX: ffffe20012c30b40 RCX: ffff88037cdcbc34
Dec 6 22:55:46 tm-spes-md102 kernel: RDX: ffff88037cdcbc38 RSI: ffff88037cdcbc3c RDI: ffffe20012c30b40
Dec 6 22:55:46 tm-spes-md102 kernel: RBP: 0000000000000000 R08: 0000000000000021 R09: 0000000000000000
Dec 6 22:55:46 tm-spes-md102 kernel: R10: ffff88038ceff678 R11: ffffffffa0251b18 R12: ffff880517690480
Dec 6 22:55:46 tm-spes-md102 kernel: R13: ffff88037cdcbce0 R14: 00000000002548c2 R15: ffff880517690590
Dec 6 22:55:46 tm-spes-md102 kernel: FS: 0000000000000000(0000) GS:ffff88037e520e40(0000) knlGS:0000000000000000
Dec 6 22:55:46 tm-spes-md102 kernel: CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
Dec 6 22:55:46 tm-spes-md102 kernel: CR2: 0000000000000000 CR3: 000000016f670000 CR4: 00000000000006e0
Dec 6 22:55:46 tm-spes-md102 kernel: DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Dec 6 22:55:46 tm-spes-md102 kernel: DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Dec 6 22:55:46 tm-spes-md102 kernel: Process kswapd0 (pid: 58, threadinfo ffff88037cdca000, task ffff88037cdc8780)
Dec 6 22:55:47 tm-spes-md102 kernel: Stack: ffffffffa0251b68 0000000000000000 0000000000000001 0000000000000000
Dec 6 22:55:47 tm-spes-md102 kernel: 0000000000000001 0000000000000000 0000000000000000 0000000000000000
Dec 6 22:55:47 tm-spes-md102 kernel: 0000000000000000 00000000002acfa4 0000000000000000 ffffe20012c30b40
Dec 6 22:55:47 tm-spes-md102 kernel: Call Trace:
Dec 6 22:55:47 tm-spes-md102 kernel: [<ffffffffa0251b68>] xfs_vm_releasepage+0x50/0xa5 [xfs]
Dec 6 22:55:47 tm-spes-md102 kernel: [<ffffffff8028bf57>] __invalidate_mapping_pages+0x98/0x12d
Dec 6 22:55:47 tm-spes-md102 kernel: [<ffffffff802c4ca1>] prune_icache+0xe7/0x1f7
Dec 6 22:55:47 tm-spes-md102 kernel: [<ffffffff802c4dc6>] shrink_icache_memory+0x15/0x32
Dec 6 22:55:47 tm-spes-md102 kernel: [<ffffffff8028dc59>] shrink_slab+0xe4/0x157
Dec 6 22:55:47 tm-spes-md102 kernel: [<ffffffff8028e173>] balance_pgdat+0x292/0x3d6
Dec 6 22:55:53 tm-spes-md102 kernel: [<ffffffff8028e3e1>] kswapd+0x12a/0x12c
Dec 6 22:55:53 tm-spes-md102 kernel: [<ffffffff8024fb2f>] kthread+0x47/0x73
Dec 6 22:55:53 tm-spes-md102 kernel: [<ffffffff8020cfb9>] child_rip+0xa/0x11
Dec 6 22:55:53 tm-spes-md102 kernel:
Dec 6 22:55:53 tm-spes-md102 kernel:
Dec 6 22:55:53 tm-spes-md102 kernel: Code: 1f eb ef 90 90 90 c7 01 00 00 00 00 c7 02 00 00 00 00 c7 06 00 00 00 00 48 8b 07 f6 c4 10 75
04 0f 0b eb fe 48 8b 47 10 49 89 c1 <4d> 8b 01 41 f6 c0 01 74 0e 41 f6 c0 20 75 08 c7 02 01 00 00 00
Dec 6 22:55:53 tm-spes-md102 kernel: RIP [<ffffffffa0250659>] xfs_count_page_state+0x25/0x66 [xfs]
Dec 6 22:55:53 tm-spes-md102 kernel: RSP <ffff88037cdcbbe8>
Dec 6 22:55:53 tm-spes-md102 kernel: CR2: 0000000000000000

__
Tharindu R Bamunuarachchi.

--000325576092b36b900496d18bf6-- From eflorac@intellique.com Tue Dec 7 08:08:57 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB7E8uqQ158213 for ; Tue, 7 Dec 2010 08:08:56 -0600 X-ASG-Debug-ID: 1291731038-78a201a00000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4E2131C9EA96 for ; Tue, 7 Dec 2010 06:10:41 -0800 (PST) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by cuda.sgi.com with ESMTP id QsUtZ6AdEOBh3REs for ; Tue, 07 Dec 2010 06:10:41 -0800 (PST) Received: from harpe.intellique.com (unknown [82.225.196.72]) by smtp4-g21.free.fr (Postfix) with ESMTP id 4CC694C80C9; Tue, 7 Dec 2010 15:10:34 +0100 (CET) Date: Tue, 7 Dec 2010 15:10:39 +0100 From: Emmanuel Florac To: blacknred Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: possible xfs corruption Subject: Re: possible xfs corruption Message-ID: <20101207151039.25d45cb5@harpe.intellique.com> In-Reply-To: <30395558.post@talk.nabble.com> References: <30395558.post@talk.nabble.com> Organization: Intellique X-Mailer: Claws Mail 3.7.3 (GTK+ 2.16.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: smtp4-g21.free.fr[212.27.42.4] X-Barracuda-Start-Time: 1291731044 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.82 X-Barracuda-Spam-Status: No, SCORE=-1.82 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA620b, MAILTO_TO_SPAM_ADDR X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48736 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email 0.20 BSF_SC0_SA620b Custom Rule SA620b X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Le Tue, 7 Dec 2010 03:49:49 -0800 (PST) blacknred =E9crivait: > I'm stuck with a storage issue on reboot. Initially doubted the > storage, but dmesg throws these errors. Now wondering whether this is > a fs issue? Any thoughts as to whats going on here? >=20 It looks like a part of the filesystem is physically missing. What is the underlying device? Apparently it's a SmartArray in some HP server, did you had a power failure?=20 --=20 ------------------------------------------------------------------------ Emmanuel Florac | Direction technique | Intellique | | +33 1 78 94 84 02 ------------------------------------------------------------------------ From lists@nabble.com Tue Dec 7 09:09:18 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, T_TO_NO_BRKTS_FREEMAIL autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB7F9H63167789 for ; Tue, 7 Dec 2010 09:09:18 -0600 X-ASG-Debug-ID: 1291734664-735600aa0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from kuber.nabble.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2E24D1CED62 for ; Tue, 7 Dec 2010 07:11:04 -0800 (PST) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by cuda.sgi.com with ESMTP id I4U6yPb5HWEvTut4 for ; Tue, 07 Dec 2010 07:11:04 -0800 (PST) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1PPzC4-0001fw-5W for xfs@oss.sgi.com; Tue, 07 Dec 2010 07:11:04 -0800 Message-ID: <30397173.post@talk.nabble.com> Date: Tue, 7 Dec 2010 07:11:04 -0800 (PST) From: blacknred To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: possible xfs corruption Subject: Re: possible xfs corruption In-Reply-To: <20101207151039.25d45cb5@harpe.intellique.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Nabble-From: leo1783@hotmail.co.uk References: <30395558.post@talk.nabble.com> <20101207151039.25d45cb5@harpe.intellique.com> X-Barracuda-Connect: kuber.nabble.com[216.139.236.158] X-Barracuda-Start-Time: 1291734665 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MAILTO_TO_SPAM_ADDR X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48740 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Yes, It's a Smart Array in HP Proliant Server. No power failure, just upgraded the controller firmware and rebooted the server..... Emmanuel Florac wrote: >=20 > Le Tue, 7 Dec 2010 03:49:49 -0800 (PST) > blacknred =C3=A9crivait: >=20 >> I'm stuck with a storage issue on reboot. Initially doubted the >> storage, but dmesg throws these errors. Now wondering whether this is >> a fs issue? Any thoughts as to whats going on here? >>=20 >=20 > It looks like a part of the filesystem is physically missing. What is > the underlying device? Apparently it's a SmartArray in some HP server, > did you had a power failure?=20 >=20 > --=20 > ------------------------------------------------------------------------ > Emmanuel Florac | Direction technique > | Intellique > |=09 > | +33 1 78 94 84 02 > ------------------------------------------------------------------------ >=20 > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs >=20 >=20 --=20 View this message in context: http://old.nabble.com/possible-xfs-corruption= -tp30395558p30397173.html Sent from the Xfs - General mailing list archive at Nabble.com. From eflorac@intellique.com Tue Dec 7 09:40:43 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_74 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB7Fehfj172239 for ; Tue, 7 Dec 2010 09:40:43 -0600 X-ASG-Debug-ID: 1291736545-735701520000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1F6961CEFC7 for ; Tue, 7 Dec 2010 07:42:29 -0800 (PST) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by cuda.sgi.com with ESMTP id bukVvV3Ym26ayXRm for ; Tue, 07 Dec 2010 07:42:29 -0800 (PST) Received: from harpe.intellique.com (unknown [82.225.196.72]) by smtp4-g21.free.fr (Postfix) with ESMTP id B57194C8180; Tue, 7 Dec 2010 16:42:21 +0100 (CET) Date: Tue, 7 Dec 2010 16:42:27 +0100 From: Emmanuel Florac To: blacknred Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: possible xfs corruption Subject: Re: possible xfs corruption Message-ID: <20101207164227.152cef01@harpe.intellique.com> In-Reply-To: <30397173.post@talk.nabble.com> References: <30395558.post@talk.nabble.com> <20101207151039.25d45cb5@harpe.intellique.com> <30397173.post@talk.nabble.com> Organization: Intellique X-Mailer: Claws Mail 3.7.3 (GTK+ 2.16.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: smtp4-g21.free.fr[212.27.42.4] X-Barracuda-Start-Time: 1291736551 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.82 X-Barracuda-Spam-Status: No, SCORE=-1.82 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA620b, MAILTO_TO_SPAM_ADDR X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48742 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email 0.20 BSF_SC0_SA620b Custom Rule SA620b X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Le Tue, 7 Dec 2010 07:11:04 -0800 (PST) blacknred =E9crivait: > Yes, It's a Smart Array in HP Proliant Server. > No power failure, just upgraded the controller firmware and rebooted > the server..... >=20 Hu oh, that stinks. Nothing in the firmware release notes? Do you have any other filesystem on this array?=20 First you could try to backup the filesystem metadata using xfs_metadump -o -w /dev/DEVICE outfile.meta It can be useful later in case things turn bad. Does it output any errors? IO errors particularly ? --=20 ------------------------------------------------------------------------ Emmanuel Florac | Direction technique | Intellique | | +33 1 78 94 84 02 ------------------------------------------------------------------------ From lists@nabble.com Tue Dec 7 09:41:10 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, T_TO_NO_BRKTS_FREEMAIL autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB7FfA17172276 for ; Tue, 7 Dec 2010 09:41:10 -0600 X-ASG-Debug-ID: 1291736577-3ce701010000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from kuber.nabble.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7F7DB1C9F690 for ; Tue, 7 Dec 2010 07:42:57 -0800 (PST) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by cuda.sgi.com with ESMTP id N5Fbyj51slMyuJZR for ; Tue, 07 Dec 2010 07:42:57 -0800 (PST) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1PPzgu-0004cE-TT for xfs@oss.sgi.com; Tue, 07 Dec 2010 07:42:56 -0800 Message-ID: <30397503.post@talk.nabble.com> Date: Tue, 7 Dec 2010 07:42:56 -0800 (PST) From: blacknred To: xfs@oss.sgi.com X-ASG-Orig-Subj: kernel panic-xfs errors Subject: kernel panic-xfs errors MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: leo1783@hotmail.co.uk X-Barracuda-Connect: kuber.nabble.com[216.139.236.158] X-Barracuda-Start-Time: 1291736577 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48742 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hi..... I get a kernel panic on my HP Proliant Server. here's trace: BUG: unable to handle kernel NULL pointer dereference at virtual address 00000052 printing eip: *pde = 2c731001 Oops: 0000 [#1] SMP CPU: 2 EIP: 0060:[] Tainted: GF VLI EFLAGS: 00010272 (2.6.33.3-85.fc13.x86_64 #1) EIP is at do_page_fault+0x245/0x617 eax: ec5ee000 ebx: 00000000 ecx: eb5de084 edx: 0000000e esi: 00013103 edi: ec5de0b3 ebp: 00000023 esp: ec5de024 ds: 008b es: 008b ss: 0078 Process bm (pid: 3210, ti=ec622000 task=ec5e3450 task.ti=ec6ee000) Stack: 00000000 00000000 ecd5e0a4 00000024 00000093 f7370000 00000007 00000000 ed6ef0a4 c0639569 00000000 0000000f 0000000b 00000000 00000000 00000000 00015106 c0629b9d 00000014 c0305b83 00000000 ec3d40f7 0000000e 00013006 Call Trace: [] do_page_fault+0x0/0x607 [] error_code+0x49/0x50 [] do_page_fault+0x204/00x607 [] elv_next_request+0x137/0x234 [] do_cciss_request+0x397/0x3a3 [cciss] [] do_page_fault+0x0/0x607 [] error_code+0x49/0x40 [] do_page_fault+0x215/0x607 [] deadline_set_request+0x26/0x57 [] do_page_fault+0x0/0x607 [] error_code+0x39/0x40 [] __down+0x2b/0xbb [] default_wake_function+0x0/0xc [] __down_failed+0x7/0xc [] .text.lock.xfs_buf+0x17/0x5f [xfs] [] xfs_buf_read_flags+0x48/0x76 [xfs] [] xfs_trans_read_buf+0x1bb/0x2c0 [xfs] [] xfs_btree_read_bufl+0x96/0xb3 [xfs] [] xfs_bmbt_lookup+0x135/0x478 [xfs] [] xfs_bmap_add_extent+0xd2b/0x1e30 [xfs] [] xfs_alloc_update+0x3a/0xbc [xfs] [] xfs_alloc_fixup_trees+0x217/0x29a [xfs] [] xfs_trans_log_buf+0x49/0x6c [xfs] [] xfs_alloc_search_busy+0x20/0xae [xfs] [] xfs_iext_bno_to_ext+0xd8/0x191 [xfs] [] kmem_zone_zalloc+0x1d/0x41 [xfs] [] xfs_bmapi+0x15fe/0x2016 [xfs] [] xfs_iext_bno_to_ext+0x48/0x191 [xfs] [] xfs_bmap_search_multi_extents+0x8a/0xc5 [xfs] [] xfs_iomap_write_allocate+0x29c/0x469 [xfs] [] lock_timer_base+0x15/0x2f [] del_timer+0x41/0x47 [] xfs_iomap+0x409/0x71d [xfs] [] xfs_map_blocks+0x29/0x52 [xfs] [] xfs_page_state_convert+0x37b/0xd2e [xfs] [] xfs_bmap_add_extent+0x1dcf/0x1e30 [xfs] [] xfs_bmap_search_multi_extents+0x8a/0xc5 [xfs] [] xfs_bmapi+0x272/0x2017 [xfs] [] xfs_bmapi+0x1853/0x2017 [xfs] [] find_get_pages_tag+0x40/0x75 [] xfs_vm_writepage+0x8f/0xd2 [xfs] [] mpage_writepages+0x1b7/0x310 [] xfs_vm_writepage+0x0/0xc4 [xfs] [] do_writepages+0x20/0x42 [] __writeback_single_inode+0x180/0x2af [] write_inode_now+0x67/0xa7 [] file_fsync+0xf/0x6c [] moddw_ioctl+0x420/0x679 [mod_dw] [] __cond_resched+0x16/0x54 [] do_ioctl+0x47/0x5d [] vfs_ioctl+0x47b/0x4d3 [] sys_ioctl+0x48/0x4f [] sysenter_past_esp+0x46/0x79 dmesg shows: XFS: bad magic number XFS: SB validate failed I rebooted the server, now xfs_repair comes clean. But the server has hung again after an hour. No panic this time, checked dmesg output and it again shows same XFS: bad magic number XFS: SB validate failed messages.. Any thoughts?? Thanks in advance David -- View this message in context: http://old.nabble.com/kernel-panic-xfs-errors-tp30397503p30397503.html Sent from the Xfs - General mailing list archive at Nabble.com. From eflorac@intellique.com Tue Dec 7 09:57:33 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB7FvW1w175576 for ; Tue, 7 Dec 2010 09:57:33 -0600 X-ASG-Debug-ID: 1291737554-731301af0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6CA5A1CEC33 for ; Tue, 7 Dec 2010 07:59:18 -0800 (PST) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by cuda.sgi.com with ESMTP id wLH9ftkdwLZUsaVo for ; Tue, 07 Dec 2010 07:59:18 -0800 (PST) Received: from harpe.intellique.com (unknown [82.225.196.72]) by smtp4-g21.free.fr (Postfix) with ESMTP id BCB7E4C80E1; Tue, 7 Dec 2010 16:59:10 +0100 (CET) Date: Tue, 7 Dec 2010 16:59:17 +0100 From: Emmanuel Florac To: blacknred Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: kernel panic-xfs errors Subject: Re: kernel panic-xfs errors Message-ID: <20101207165917.0c96dd95@harpe.intellique.com> In-Reply-To: <30397503.post@talk.nabble.com> References: <30397503.post@talk.nabble.com> Organization: Intellique X-Mailer: Claws Mail 3.7.3 (GTK+ 2.16.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: smtp4-g21.free.fr[212.27.42.4] X-Barracuda-Start-Time: 1291737560 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.82 X-Barracuda-Spam-Status: No, SCORE=-1.82 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA620b, MAILTO_TO_SPAM_ADDR X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48744 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email 0.20 BSF_SC0_SA620b Custom Rule SA620b X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Le Tue, 7 Dec 2010 07:42:56 -0800 (PST) blacknred =E9crivait: > But the server has hung again after an hour. No panic this time, > checked dmesg output and it again > shows same=20 > XFS: bad magic number > XFS: SB validate failed=20 > messages.. Any thoughts?? >=20 What is the kernel version, distro, and xfs_progs? You didn't update anything but the controller firmware? Is the new firmware compatible with the previous driver? This one is intriguing : [] do_cciss_request+0x397/0x3a3 [cciss] --=20 ------------------------------------------------------------------------ Emmanuel Florac | Direction technique | Intellique | | +33 1 78 94 84 02 ------------------------------------------------------------------------ From lists@nabble.com Tue Dec 7 11:18:30 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, T_TO_NO_BRKTS_FREEMAIL autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB7HIUBH187790 for ; Tue, 7 Dec 2010 11:18:30 -0600 X-ASG-Debug-ID: 1291742417-3ca502670000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from kuber.nabble.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E31701C9FC8F for ; Tue, 7 Dec 2010 09:20:17 -0800 (PST) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by cuda.sgi.com with ESMTP id KZtkzx6xeB4stmff for ; Tue, 07 Dec 2010 09:20:17 -0800 (PST) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1PQ1D7-0005xH-6i for xfs@oss.sgi.com; Tue, 07 Dec 2010 09:20:17 -0800 Message-ID: <30398448.post@talk.nabble.com> Date: Tue, 7 Dec 2010 09:20:17 -0800 (PST) From: blacknred To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: kernel panic-xfs errors Subject: Re: kernel panic-xfs errors In-Reply-To: <20101207165917.0c96dd95@harpe.intellique.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Nabble-From: leo1783@hotmail.co.uk References: <30397503.post@talk.nabble.com> <20101207165917.0c96dd95@harpe.intellique.com> X-Barracuda-Connect: kuber.nabble.com[216.139.236.158] X-Barracuda-Start-Time: 1291742417 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MAILTO_TO_SPAM_ADDR X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48750 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean kernel-2.6.18-164.el5 rhel 5.0 xfs_progs ver: 2.9.4 I haven't updated the controller on this server, it just panicked while doing I/O [] do_cciss_request+0x397/0x3a3 [cciss] looks like the controller was wedged there? Emmanuel Florac wrote: >=20 > Le Tue, 7 Dec 2010 07:42:56 -0800 (PST) > blacknred =C3=A9crivait: >=20 >> But the server has hung again after an hour. No panic this time, >> checked dmesg output and it again >> shows same=20 >> XFS: bad magic number >> XFS: SB validate failed=20 >> messages.. Any thoughts?? >>=20 >=20 > What is the kernel version, distro, and xfs_progs? You didn't update > anything but the controller firmware? Is the new firmware compatible > with the previous driver? >=20 > This one is intriguing : >=20 > [] do_cciss_request+0x397/0x3a3 [cciss] >=20 > --=20 > ------------------------------------------------------------------------ > Emmanuel Florac | Direction technique > | Intellique > |=09 > | +33 1 78 94 84 02 > ------------------------------------------------------------------------ >=20 > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs >=20 >=20 --=20 View this message in context: http://old.nabble.com/kernel-panic-xfs-errors= -tp30397503p30398448.html Sent from the Xfs - General mailing list archive at Nabble.com. From lists@nabble.com Tue Dec 7 11:28:36 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,FREEMAIL_FROM, J_CHICKENPOX_74,T_TO_NO_BRKTS_FREEMAIL autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB7HSatG189222 for ; Tue, 7 Dec 2010 11:28:36 -0600 X-ASG-Debug-ID: 1291743023-3cb9028e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from kuber.nabble.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id EBC9B1C9FD85 for ; Tue, 7 Dec 2010 09:30:23 -0800 (PST) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by cuda.sgi.com with ESMTP id nJ00jgujgPIC6EEU for ; Tue, 07 Dec 2010 09:30:23 -0800 (PST) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1PQ1Mt-0006nX-K7 for xfs@oss.sgi.com; Tue, 07 Dec 2010 09:30:23 -0800 Message-ID: <30398538.post@talk.nabble.com> Date: Tue, 7 Dec 2010 09:30:23 -0800 (PST) From: blacknred To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: possible xfs corruption Subject: Re: possible xfs corruption In-Reply-To: <20101207164227.152cef01@harpe.intellique.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Nabble-From: leo1783@hotmail.co.uk References: <30395558.post@talk.nabble.com> <20101207151039.25d45cb5@harpe.intellique.com> <30397173.post@talk.nabble.com> <20101207164227.152cef01@harpe.intellique.com> X-Barracuda-Connect: kuber.nabble.com[216.139.236.158] X-Barracuda-Start-Time: 1291743023 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MAILTO_TO_SPAM_ADDR X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48750 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean It's all xfs..... and didn't see any I/O errors as well...except that dmesg is flooded with similar traces to one i posted.... Emmanuel Florac wrote: >=20 > Le Tue, 7 Dec 2010 07:11:04 -0800 (PST) > blacknred =C3=A9crivait: >=20 >> Yes, It's a Smart Array in HP Proliant Server. >> No power failure, just upgraded the controller firmware and rebooted >> the server..... >>=20 >=20 > Hu oh, that stinks. Nothing in the firmware release notes? Do you have > any other filesystem on this array?=20 >=20 > First you could try to backup the filesystem metadata using >=20 > xfs_metadump -o -w /dev/DEVICE outfile.meta >=20 > It can be useful later in case things turn bad. > Does it output any errors? IO errors particularly ? >=20 > --=20 > ------------------------------------------------------------------------ > Emmanuel Florac | Direction technique > | Intellique > |=09 > | +33 1 78 94 84 02 > ------------------------------------------------------------------------ >=20 > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs >=20 >=20 --=20 View this message in context: http://old.nabble.com/possible-xfs-corruption= -tp30395558p30398538.html Sent from the Xfs - General mailing list archive at Nabble.com. From eflorac@intellique.com Tue Dec 7 11:58:54 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB7Hwsbe194335 for ; Tue, 7 Dec 2010 11:58:54 -0600 X-ASG-Debug-ID: 1291744834-1d3501220000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 46F841CF6C6 for ; Tue, 7 Dec 2010 10:00:35 -0800 (PST) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by cuda.sgi.com with ESMTP id BizM1J0JydViSYtp for ; Tue, 07 Dec 2010 10:00:35 -0800 (PST) Received: from harpe.intellique.com (unknown [82.225.196.72]) by smtp4-g21.free.fr (Postfix) with ESMTP id EB0BC4C81A4; Tue, 7 Dec 2010 19:00:30 +0100 (CET) Date: Tue, 7 Dec 2010 19:00:38 +0100 From: Emmanuel Florac To: blacknred Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: kernel panic-xfs errors Subject: Re: kernel panic-xfs errors Message-ID: <20101207190038.61e9dbb7@harpe.intellique.com> In-Reply-To: <30398448.post@talk.nabble.com> References: <30397503.post@talk.nabble.com> <20101207165917.0c96dd95@harpe.intellique.com> <30398448.post@talk.nabble.com> Organization: Intellique X-Mailer: Claws Mail 3.7.3 (GTK+ 2.16.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: smtp4-g21.free.fr[212.27.42.4] X-Barracuda-Start-Time: 1291744838 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.82 X-Barracuda-Spam-Status: No, SCORE=-1.82 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA620b, MAILTO_TO_SPAM_ADDR X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48752 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email 0.20 BSF_SC0_SA620b Custom Rule SA620b X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Le Tue, 7 Dec 2010 09:20:17 -0800 (PST) blacknred =E9crivait: > [] do_cciss_request+0x397/0x3a3 [cciss] > looks like the controller was wedged there? >=20 Yes, apparently your controller wrote garbage at the beginning of the filesystem... you have lots of trouble with these controllers, has anything special happened? that's weird. You should try using a newer xfs_repair (> 3.x), for instance by booting from an Ubuntu 10.10 live CD, and see if it fares any better from there. --=20 ------------------------------------------------------------------------ Emmanuel Florac | Direction technique | Intellique | | +33 1 78 94 84 02 ------------------------------------------------------------------------ From stan@hardwarefreak.com Tue Dec 7 12:14:07 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB7IE72F196704 for ; Tue, 7 Dec 2010 12:14:07 -0600 X-ASG-Debug-ID: 1291745754-1d3501c30000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from greer.hardwarefreak.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 183E61CFE4E for ; Tue, 7 Dec 2010 10:15:54 -0800 (PST) Received: from greer.hardwarefreak.com (mo-65-41-216-221.sta.embarqhsd.net [65.41.216.221]) by cuda.sgi.com with ESMTP id P6ctnKQk9F0NOil0 for ; Tue, 07 Dec 2010 10:15:54 -0800 (PST) Received: from [192.168.100.53] (gffx.hardwarefreak.com [192.168.100.53]) by greer.hardwarefreak.com (Postfix) with ESMTP id 494246C14E for ; Tue, 7 Dec 2010 12:15:54 -0600 (CST) Message-ID: <4CFE79DA.9080400@hardwarefreak.com> Date: Tue, 07 Dec 2010 12:15:54 -0600 From: Stan Hoeppner User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: possible xfs corruption Subject: Re: possible xfs corruption References: <30395558.post@talk.nabble.com> <20101207151039.25d45cb5@harpe.intellique.com> <30397173.post@talk.nabble.com> <20101207164227.152cef01@harpe.intellique.com> <30398538.post@talk.nabble.com> In-Reply-To: <30398538.post@talk.nabble.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mo-65-41-216-221.sta.embarqhsd.net[65.41.216.221] X-Barracuda-Start-Time: 1291745755 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0451 1.0000 -1.7306 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.13 X-Barracuda-Spam-Status: No, SCORE=-1.13 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC5_MJ1963, RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48752 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS 0.50 BSF_SC5_MJ1963 Custom Rule MJ1963 X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean blacknred put forth on 12/7/2010 11:30 AM: > > It's all xfs..... and didn't see any I/O errors as well...except that dmesg > is flooded with similar traces to one i posted.... Out of the blue, one OP, with two Proliant servers having storage problems, within hours of one another, the same day? Long odds, that. Did you walk a mile, flat footed, on deep shag carpet, while wearing a wool sweater, in a room with zero humidity, then walk into the DC and touch each of these servers, or something? ;) -- Stan From stan@hardwarefreak.com Tue Dec 7 12:17:02 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB7IH1av197241 for ; Tue, 7 Dec 2010 12:17:02 -0600 X-ASG-Debug-ID: 1291745929-3cde03410000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from greer.hardwarefreak.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B713C1CA0A0D for ; Tue, 7 Dec 2010 10:18:49 -0800 (PST) Received: from greer.hardwarefreak.com (mo-65-41-216-221.sta.embarqhsd.net [65.41.216.221]) by cuda.sgi.com with ESMTP id PFSDrdEeJ9KqC9MP for ; Tue, 07 Dec 2010 10:18:49 -0800 (PST) Received: from [192.168.100.53] (gffx.hardwarefreak.com [192.168.100.53]) by greer.hardwarefreak.com (Postfix) with ESMTP id 27A686C14E for ; Tue, 7 Dec 2010 12:18:49 -0600 (CST) Message-ID: <4CFE7A89.2010307@hardwarefreak.com> Date: Tue, 07 Dec 2010 12:18:49 -0600 From: Stan Hoeppner User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: kernel panic-xfs errors Subject: Re: kernel panic-xfs errors References: <30397503.post@talk.nabble.com> <20101207165917.0c96dd95@harpe.intellique.com> <30398448.post@talk.nabble.com> <20101207190038.61e9dbb7@harpe.intellique.com> In-Reply-To: <20101207190038.61e9dbb7@harpe.intellique.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Barracuda-Connect: mo-65-41-216-221.sta.embarqhsd.net[65.41.216.221] X-Barracuda-Start-Time: 1291745929 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.22 X-Barracuda-Spam-Status: No, SCORE=-1.22 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA620b, BSF_SC5_MJ1963, MAILTO_TO_SPAM_ADDR, RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48752 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS 0.50 BSF_SC5_MJ1963 Custom Rule MJ1963 0.20 BSF_SC0_SA620b Custom Rule SA620b X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Emmanuel Florac put forth on 12/7/2010 12:00 PM: > Le Tue, 7 Dec 2010 09:20:17 -0800 (PST) > blacknred écrivait: > >> [] do_cciss_request+0x397/0x3a3 [cciss] >> looks like the controller was wedged there? >> > > Yes, apparently your controller wrote garbage at the beginning of the > filesystem... you have lots of trouble with these controllers, has > anything special happened? that's weird. > > You should try using a newer xfs_repair (> 3.x), for instance by booting > from an Ubuntu 10.10 live CD, and see if it fares any better from there. The answer for the one server is simple: back out the firmware--flash it with the previously installed version. BTW, what need prompted the new flash in the first place? I _never_ flash controller firmware unless absolutely necessary. You've demonstrated today why I practice that faith. -- Stan From michael.monnerie@is.it-management.at Tue Dec 7 13:31:12 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB7JVBnR207746 for ; Tue, 7 Dec 2010 13:31:12 -0600 X-ASG-Debug-ID: 1291750376-332701380000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mailsrv14.zmi.at (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E26A4160F3F5 for ; Tue, 7 Dec 2010 11:32:56 -0800 (PST) Received: from mailsrv14.zmi.at (mailsrv1.zmi.at [212.69.164.54]) by cuda.sgi.com with ESMTP id tpIThEkXFI12uJuA for ; Tue, 07 Dec 2010 11:32:56 -0800 (PST) Received: from mailsrv.i.zmi.at (h081217106033.dyn.cm.kabsi.at [81.217.106.33]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mailsrv2.i.zmi.at", Issuer "power4u.zmi.at" (not verified)) by mailsrv14.zmi.at (Postfix) with ESMTPSA id 480EA144; Tue, 7 Dec 2010 20:32:55 +0100 (CET) Received: from saturn.localnet (saturn.i.zmi.at [10.72.27.2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mailsrv.i.zmi.at (Postfix) with ESMTPSA id 6E9B6401C3E; Tue, 7 Dec 2010 20:32:54 +0100 (CET) From: Michael Monnerie Organization: it-management http://it-management.at To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: possible xfs corruption Subject: Re: possible xfs corruption Date: Tue, 7 Dec 2010 20:32:53 +0100 User-Agent: KMail/1.13.5 (Linux/2.6.34.7-0.5-desktop; KDE/4.4.4; x86_64; ; ) Cc: blacknred References: <30395558.post@talk.nabble.com> <20101207151039.25d45cb5@harpe.intellique.com> <30397173.post@talk.nabble.com> In-Reply-To: <30397173.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart7703918.QEWK9RTnrp"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201012072032.54069@zmi.at> X-Barracuda-Connect: mailsrv1.zmi.at[212.69.164.54] X-Barracuda-Start-Time: 1291750377 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48757 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --nextPart7703918.QEWK9RTnrp Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Dienstag, 7. Dezember 2010 blacknred wrote: > Yes, It's a Smart Array in HP Proliant Server. > No power failure, just upgraded the controller firmware and rebooted > the server..... What Server, controller, and from which firmware version did you go to=20 which one? =2D-=20 mit freundlichen Gr=C3=BCssen, Michael Monnerie, Ing. BSc it-management Internet Services: Prot=C3=A9ger http://proteger.at [gesprochen: Prot-e-schee] Tel: +43 660 / 415 6531 // ****** Radiointerview zum Thema Spam ****** // http://www.it-podcast.at/archiv.html#podcast-100716 //=20 // Haus zu verkaufen: http://zmi.at/langegg/ --nextPart7703918.QEWK9RTnrp Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) iEYEABECAAYFAkz+i+YACgkQzhSR9xwSCbTfOwCcDMY9VzesWwignv1DVKO1O42b VTYAoOjO0jRWFnJEjmtMCg2QFeL8bWDs =uAsw -----END PGP SIGNATURE----- --nextPart7703918.QEWK9RTnrp-- From eflorac@intellique.com Tue Dec 7 15:50:49 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB7Lom7M228447 for ; Tue, 7 Dec 2010 15:50:49 -0600 X-ASG-Debug-ID: 1291758752-1e9e01410000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp3-g21.free.fr (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7BA121426BA0 for ; Tue, 7 Dec 2010 13:52:33 -0800 (PST) Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by cuda.sgi.com with ESMTP id us05kPch6PutdLK5 for ; Tue, 07 Dec 2010 13:52:33 -0800 (PST) Received: from galadriel.home (unknown [82.235.234.79]) by smtp3-g21.free.fr (Postfix) with ESMTP id 88E9EA62AC; Tue, 7 Dec 2010 22:52:28 +0100 (CET) Date: Tue, 7 Dec 2010 22:52:26 +0100 From: Emmanuel Florac To: Stan Hoeppner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: kernel panic-xfs errors Subject: Re: kernel panic-xfs errors Message-ID: <20101207225226.55be2b4d@galadriel.home> In-Reply-To: <4CFE7A89.2010307@hardwarefreak.com> References: <30397503.post@talk.nabble.com> <20101207165917.0c96dd95@harpe.intellique.com> <30398448.post@talk.nabble.com> <20101207190038.61e9dbb7@harpe.intellique.com> <4CFE7A89.2010307@hardwarefreak.com> Organization: Intellique X-Mailer: Claws Mail 3.7.3 (GTK+ 2.20.1; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: smtp3-g21.free.fr[212.27.42.3] X-Barracuda-Start-Time: 1291758756 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48767 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Le Tue, 07 Dec 2010 12:18:49 -0600 vous =E9criviez: > The answer for the one server is simple: back out the firmware--flash > it with the previously installed version. >=20 > BTW, what need prompted the new flash in the first place? I _never_ > flash controller firmware unless absolutely necessary. You've > demonstrated today why I practice that faith. I've experienced myself some very convincing reasons, for instance a RAID array with a performance varying by 1000% with a new firmware. However the kernel panic occured on another that apparently wasn't firmware-flashed. --=20 ------------------------------------------------------------------------ Emmanuel Florac | Direction technique | Intellique | | +33 1 78 94 84 02 ------------------------------------------------------------------------ From SRS0+8zW4+10+fromorbit.com=david@internode.on.net Tue Dec 7 16:08:27 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB7M8QUg231574 for ; Tue, 7 Dec 2010 16:08:26 -0600 X-ASG-Debug-ID: 1291759812-270801d90000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5CDB214260FE for ; Tue, 7 Dec 2010 14:10:13 -0800 (PST) Received: from mail.internode.on.net (bld-mail12.adl6.internode.on.net [150.101.137.97]) by cuda.sgi.com with ESMTP id iW0yk5sNTwfz01iR for ; Tue, 07 Dec 2010 14:10:13 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 49149054-1927428 for multiple; Wed, 08 Dec 2010 08:40:11 +1030 (CDT) Received: from dave by dastard with local (Exim 4.71) (envelope-from ) id 1PQ5je-0007dr-0N; Wed, 08 Dec 2010 09:10:10 +1100 Date: Wed, 8 Dec 2010 09:10:09 +1100 From: Dave Chinner To: blacknred Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: possible xfs corruption Subject: Re: possible xfs corruption Message-ID: <20101207221009.GA29333@dastard> References: <30395558.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30395558.post@talk.nabble.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: bld-mail12.adl6.internode.on.net[150.101.137.97] X-Barracuda-Start-Time: 1291759814 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0058 1.0000 -1.9830 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.48 X-Barracuda-Spam-Status: No, SCORE=-1.48 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48769 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Tue, Dec 07, 2010 at 03:49:49AM -0800, blacknred wrote: > > Hi... > > I'm stuck with a storage issue on reboot. Initially doubted the storage, but > dmesg throws these errors. Now wondering whether this is a fs issue? Any > thoughts as to whats going on here? > > > XFS: failed to locate log tail > XFS: log mount/recovery failed: error 117 > XFS: log mount failed > XFS mounting filesystem cciss/c0d0 > Filesystem "cciss/c0d0": XFS internal error xlog_clear_stale_blocks(2) at > line 1237 of file Which indicates that the head and/or the tail of the log are not valid. Can you provide the output of: # xfs_logprint -d /dev/cciss/c0d0 So we can see what the head/tail values are in the log? > /home/buildsvn/rpmbuild/BUILD/xfs-kmod-0.4/_kmod_build_PAE/xfs_log_recover.c. CentOS kernel? How old? Cheers, Dave. -- Dave Chinner david@fromorbit.com From SRS0+8zW4+10+fromorbit.com=david@internode.on.net Tue Dec 7 16:12:59 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB7MCxTa232191 for ; Tue, 7 Dec 2010 16:12:59 -0600 X-ASG-Debug-ID: 1291760085-2c1302c20000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 479BA1CA2F15 for ; Tue, 7 Dec 2010 14:14:46 -0800 (PST) Received: from mail.internode.on.net (bld-mail12.adl6.internode.on.net [150.101.137.97]) by cuda.sgi.com with ESMTP id ZLHrCStwSBJbsx1F for ; Tue, 07 Dec 2010 14:14:46 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 49149753-1927428 for multiple; Wed, 08 Dec 2010 08:44:45 +1030 (CDT) Received: from dave by dastard with local (Exim 4.71) (envelope-from ) id 1PQ5o3-0007eO-MW; Wed, 08 Dec 2010 09:14:43 +1100 Date: Wed, 8 Dec 2010 09:14:43 +1100 From: Dave Chinner To: Tharindu Rukshan Bamunuarachchi Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs_count_page_state inside kswapd Subject: Re: xfs_count_page_state inside kswapd Message-ID: <20101207221443.GB29333@dastard> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: bld-mail12.adl6.internode.on.net[150.101.137.97] X-Barracuda-Start-Time: 1291760087 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0208 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48768 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Tue, Dec 07, 2010 at 06:26:52PM +0530, Tharindu Rukshan Bamunuarachchi wrote: > Dear All, > > We got following oops in one of our SLES 11 server. This occurred inside > swapd and we running our server swap turned off.. > > Could this be memory corruption or possible old bug in code ? No idea - the SLES11 kernel is lots of non-standard stuff in it compared to mainline (e.g. the XFS code has DMAPI support) and you are running a kernel with Novell supported kernel modules loaded (all the IB stuff). Your best bet is to contact your SLES support representative to see if they know of such a problem... Cheers, Dave. -- Dave Chinner david@fromorbit.com From SRS0+8zW4+10+fromorbit.com=david@internode.on.net Tue Dec 7 16:24:16 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB7MOFv7234234 for ; Tue, 7 Dec 2010 16:24:15 -0600 X-ASG-Debug-ID: 1291760761-5aff00670000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0DBC914262B4 for ; Tue, 7 Dec 2010 14:26:01 -0800 (PST) Received: from mail.internode.on.net (bld-mail12.adl6.internode.on.net [150.101.137.97]) by cuda.sgi.com with ESMTP id M7tIUP3CZbkVnxYi for ; Tue, 07 Dec 2010 14:26:01 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 49151090-1927428 for multiple; Wed, 08 Dec 2010 08:56:00 +1030 (CDT) Received: from dave by dastard with local (Exim 4.71) (envelope-from ) id 1PQ5yw-0007fb-6G; Wed, 08 Dec 2010 09:25:58 +1100 Date: Wed, 8 Dec 2010 09:25:58 +1100 From: Dave Chinner To: blacknred Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: kernel panic-xfs errors Subject: Re: kernel panic-xfs errors Message-ID: <20101207222558.GC29333@dastard> References: <30397503.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30397503.post@talk.nabble.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: bld-mail12.adl6.internode.on.net[150.101.137.97] X-Barracuda-Start-Time: 1291760763 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48769 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Tue, Dec 07, 2010 at 07:42:56AM -0800, blacknred wrote: > > Hi..... > > I get a kernel panic on my HP Proliant Server. > > here's trace: > > BUG: unable to handle kernel NULL pointer dereference at virtual address > 00000052 > printing eip: > *pde = 2c731001 > Oops: 0000 [#1] > SMP > > CPU: 2 > EIP: 0060:[] Tainted: GF VLI ^^^^^^^^^^^ You've done a forced module load. No guarantee your kernel is in any sane shape if you've done that.... > EFLAGS: 00010272 (2.6.33.3-85.fc13.x86_64 #1) > EIP is at do_page_fault+0x245/0x617 > eax: ec5ee000 ebx: 00000000 ecx: eb5de084 edx: 0000000e > esi: 00013103 edi: ec5de0b3 ebp: 00000023 esp: ec5de024 > ds: 008b es: 008b ss: 0078 > Process bm (pid: 3210, ti=ec622000 task=ec5e3450 task.ti=ec6ee000) > Stack: 00000000 00000000 ecd5e0a4 00000024 00000093 f7370000 00000007 > 00000000 > ed6ef0a4 c0639569 00000000 0000000f 0000000b 00000000 00000000 > 00000000 > 00015106 c0629b9d 00000014 c0305b83 00000000 ec3d40f7 0000000e > 00013006 > Call Trace: > [] do_page_fault+0x0/0x607 > [] error_code+0x49/0x50 > [] do_page_fault+0x204/00x607 > [] elv_next_request+0x137/0x234 > [] do_cciss_request+0x397/0x3a3 [cciss] > [] do_page_fault+0x0/0x607 > [] error_code+0x49/0x40 > [] do_page_fault+0x215/0x607 > [] deadline_set_request+0x26/0x57 > [] do_page_fault+0x0/0x607 > [] error_code+0x39/0x40 > [] __down+0x2b/0xbb > [] default_wake_function+0x0/0xc > [] __down_failed+0x7/0xc > [] .text.lock.xfs_buf+0x17/0x5f [xfs] > [] xfs_buf_read_flags+0x48/0x76 [xfs] > [] xfs_trans_read_buf+0x1bb/0x2c0 [xfs] > [] xfs_btree_read_bufl+0x96/0xb3 [xfs] > [] xfs_bmbt_lookup+0x135/0x478 [xfs] > [] xfs_bmap_add_extent+0xd2b/0x1e30 [xfs] > [] xfs_alloc_update+0x3a/0xbc [xfs] > [] xfs_alloc_fixup_trees+0x217/0x29a [xfs] > [] xfs_trans_log_buf+0x49/0x6c [xfs] > [] xfs_alloc_search_busy+0x20/0xae [xfs] > [] xfs_iext_bno_to_ext+0xd8/0x191 [xfs] > [] kmem_zone_zalloc+0x1d/0x41 [xfs] > [] xfs_bmapi+0x15fe/0x2016 [xfs] > [] xfs_iext_bno_to_ext+0x48/0x191 [xfs] > [] xfs_bmap_search_multi_extents+0x8a/0xc5 [xfs] > [] xfs_iomap_write_allocate+0x29c/0x469 [xfs] > [] lock_timer_base+0x15/0x2f > [] del_timer+0x41/0x47 > [] xfs_iomap+0x409/0x71d [xfs] > [] xfs_map_blocks+0x29/0x52 [xfs] > [] xfs_page_state_convert+0x37b/0xd2e [xfs] > [] xfs_bmap_add_extent+0x1dcf/0x1e30 [xfs] > [] xfs_bmap_search_multi_extents+0x8a/0xc5 [xfs] > [] xfs_bmapi+0x272/0x2017 [xfs] > [] xfs_bmapi+0x1853/0x2017 [xfs] > [] find_get_pages_tag+0x40/0x75 > [] xfs_vm_writepage+0x8f/0xd2 [xfs] > [] mpage_writepages+0x1b7/0x310 > [] xfs_vm_writepage+0x0/0xc4 [xfs] > [] do_writepages+0x20/0x42 > [] __writeback_single_inode+0x180/0x2af > [] write_inode_now+0x67/0xa7 > [] file_fsync+0xf/0x6c > [] moddw_ioctl+0x420/0x679 [mod_dw] > [] __cond_resched+0x16/0x54 > [] do_ioctl+0x47/0x5d > [] vfs_ioctl+0x47b/0x4d3 > [] sys_ioctl+0x48/0x4f > [] sysenter_past_esp+0x46/0x79 Strange failure. Hmmm - i386 arch and fedora - are you running with 4k stacks? If so, maybe it blew the stack... > > dmesg shows: > XFS: bad magic number > XFS: SB validate failed > > I rebooted the server, now xfs_repair comes clean. > > But the server has hung again after an hour. No panic this time, checked > dmesg output and it again > shows same > XFS: bad magic number > XFS: SB validate failed > messages.. Any thoughts?? What does this give you before and after the failure: # dd if= bs=512 count=1 | od -c Cheers, Dave. -- Dave Chinner david@fromorbit.com From lists@nabble.com Wed Dec 8 03:37:24 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, T_TO_NO_BRKTS_FREEMAIL autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB89bOC8091327 for ; Wed, 8 Dec 2010 03:37:24 -0600 X-ASG-Debug-ID: 1291801151-074e01500000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from kuber.nabble.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D3E241D34E0 for ; Wed, 8 Dec 2010 01:39:11 -0800 (PST) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by cuda.sgi.com with ESMTP id AaOlAr3OyY1orAEz for ; Wed, 08 Dec 2010 01:39:11 -0800 (PST) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1PQGUQ-0002dP-PC for xfs@oss.sgi.com; Wed, 08 Dec 2010 01:39:10 -0800 Message-ID: <30403823.post@talk.nabble.com> Date: Wed, 8 Dec 2010 01:39:10 -0800 (PST) From: blacknred To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: kernel panic-xfs errors Subject: Re: kernel panic-xfs errors In-Reply-To: <20101207222558.GC29333@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: leo1783@hotmail.co.uk References: <30397503.post@talk.nabble.com> <20101207222558.GC29333@dastard> X-Barracuda-Connect: kuber.nabble.com[216.139.236.158] X-Barracuda-Start-Time: 1291801151 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48814 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean >You've done a forced module load. No guarantee your kernel is in any >sane shape if you've done that.... Agree, but I'm reasonably convinced that module isn't the issue, because it works fine with my other servers...... >Strange failure. Hmmm - i386 arch and fedora - are you running with 4k stacks? If so, maybe it blew the stack... i386 arch, rhel 5.0 ># dd if= bs=512 count=1 | od -c This is what i get now, but now server's been rebooted and running OK, what should i be expecting or rather what are we looking for in this output at point of failure? 1+0 records in 1+0 records out 0000000 X F S B \0 \0 020 \0 \0 \0 \0 \0 025 324 304 \0 512 bytes (512 B) copied0000020 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000040 330 k 004 8 A 365 F 023 221 035 215 E 277 + v 256 0000060 \0 \0 \0 \0 020 \0 \0 @ \0 \0 \0 \0 \0 \0 \0 200 , 3.8e-05 seconds, 13.5 MB/s 0000100 \0 \0 \0 \0 \0 \0 \0 201 \0 \0 \0 \0 \0 \0 \0 202 0000120 \0 \0 \0 001 \0 256 246 @ \0 \0 \0 \0 \0 \0 \0 0000140 \0 \0 200 \0 261 204 002 \0 \b \0 \0 002 \0 \0 \0 \0 0000160 \0 \0 \0 \0 \0 \0 \0 \0 \b \t \v 001 030 \0 \0 \0 0000200 \0 \0 \0 \0 \0 023 240 @ \0 \0 \0 \0 \0 004 264 344 0000220 \0 \0 \0 \0 \b 346 311 ( \0 \0 \0 \0 \0 \0 \0 \0 0000240 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000260 \0 \0 \0 \0 \0 \0 \0 002 \0 \0 \0 @ \0 \0 001 \0 0000300 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \b \0 \0 \0 \b 0000320 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0001000 >why did I flash the controller I was on 5.22 fw version which has a known 'lockup' issue which is fixed in 7.x ver. This is a critical fix. So initially i was thinking the lockup caused the xfs errors in dmesg on the panicked server. But now its hung with the 7.x fw as well and same error shows in dmesg which makes me worried about the fs more.... Dave Chinner wrote: > > On Tue, Dec 07, 2010 at 07:42:56AM -0800, blacknred wrote: >> >> Hi..... >> >> I get a kernel panic on my HP Proliant Server. >> >> here's trace: >> >> BUG: unable to handle kernel NULL pointer dereference at virtual address >> 00000052 >> printing eip: >> *pde = 2c731001 >> Oops: 0000 [#1] >> SMP >> >> CPU: 2 >> EIP: 0060:[] Tainted: GF VLI > ^^^^^^^^^^^ > > You've done a forced module load. No guarantee your kernel is in any > sane shape if you've done that.... > >> EFLAGS: 00010272 (2.6.33.3-85.fc13.x86_64 #1) >> EIP is at do_page_fault+0x245/0x617 >> eax: ec5ee000 ebx: 00000000 ecx: eb5de084 edx: 0000000e >> esi: 00013103 edi: ec5de0b3 ebp: 00000023 esp: ec5de024 >> ds: 008b es: 008b ss: 0078 >> Process bm (pid: 3210, ti=ec622000 task=ec5e3450 task.ti=ec6ee000) >> Stack: 00000000 00000000 ecd5e0a4 00000024 00000093 f7370000 00000007 >> 00000000 >> ed6ef0a4 c0639569 00000000 0000000f 0000000b 00000000 00000000 >> 00000000 >> 00015106 c0629b9d 00000014 c0305b83 00000000 ec3d40f7 0000000e >> 00013006 >> Call Trace: >> [] do_page_fault+0x0/0x607 >> [] error_code+0x49/0x50 >> [] do_page_fault+0x204/00x607 >> [] elv_next_request+0x137/0x234 >> [] do_cciss_request+0x397/0x3a3 [cciss] >> [] do_page_fault+0x0/0x607 >> [] error_code+0x49/0x40 >> [] do_page_fault+0x215/0x607 >> [] deadline_set_request+0x26/0x57 >> [] do_page_fault+0x0/0x607 >> [] error_code+0x39/0x40 >> [] __down+0x2b/0xbb >> [] default_wake_function+0x0/0xc >> [] __down_failed+0x7/0xc >> [] .text.lock.xfs_buf+0x17/0x5f [xfs] >> [] xfs_buf_read_flags+0x48/0x76 [xfs] >> [] xfs_trans_read_buf+0x1bb/0x2c0 [xfs] >> [] xfs_btree_read_bufl+0x96/0xb3 [xfs] >> [] xfs_bmbt_lookup+0x135/0x478 [xfs] >> [] xfs_bmap_add_extent+0xd2b/0x1e30 [xfs] >> [] xfs_alloc_update+0x3a/0xbc [xfs] >> [] xfs_alloc_fixup_trees+0x217/0x29a [xfs] >> [] xfs_trans_log_buf+0x49/0x6c [xfs] >> [] xfs_alloc_search_busy+0x20/0xae [xfs] >> [] xfs_iext_bno_to_ext+0xd8/0x191 [xfs] >> [] kmem_zone_zalloc+0x1d/0x41 [xfs] >> [] xfs_bmapi+0x15fe/0x2016 [xfs] >> [] xfs_iext_bno_to_ext+0x48/0x191 [xfs] >> [] xfs_bmap_search_multi_extents+0x8a/0xc5 [xfs] >> [] xfs_iomap_write_allocate+0x29c/0x469 [xfs] >> [] lock_timer_base+0x15/0x2f >> [] del_timer+0x41/0x47 >> [] xfs_iomap+0x409/0x71d [xfs] >> [] xfs_map_blocks+0x29/0x52 [xfs] >> [] xfs_page_state_convert+0x37b/0xd2e [xfs] >> [] xfs_bmap_add_extent+0x1dcf/0x1e30 [xfs] >> [] xfs_bmap_search_multi_extents+0x8a/0xc5 [xfs] >> [] xfs_bmapi+0x272/0x2017 [xfs] >> [] xfs_bmapi+0x1853/0x2017 [xfs] >> [] find_get_pages_tag+0x40/0x75 >> [] xfs_vm_writepage+0x8f/0xd2 [xfs] >> [] mpage_writepages+0x1b7/0x310 >> [] xfs_vm_writepage+0x0/0xc4 [xfs] >> [] do_writepages+0x20/0x42 >> [] __writeback_single_inode+0x180/0x2af >> [] write_inode_now+0x67/0xa7 >> [] file_fsync+0xf/0x6c >> [] moddw_ioctl+0x420/0x679 [mod_dw] >> [] __cond_resched+0x16/0x54 >> [] do_ioctl+0x47/0x5d >> [] vfs_ioctl+0x47b/0x4d3 >> [] sys_ioctl+0x48/0x4f >> [] sysenter_past_esp+0x46/0x79 > > Strange failure. Hmmm - i386 arch and fedora - are you running with > 4k stacks? If so, maybe it blew the stack... > >> >> dmesg shows: >> XFS: bad magic number >> XFS: SB validate failed >> >> I rebooted the server, now xfs_repair comes clean. >> >> But the server has hung again after an hour. No panic this time, checked >> dmesg output and it again >> shows same >> XFS: bad magic number >> XFS: SB validate failed >> messages.. Any thoughts?? > > What does this give you before and after the failure: > > # dd if= bs=512 count=1 | od -c > > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > > -- View this message in context: http://old.nabble.com/kernel-panic-xfs-errors-tp30397503p30403823.html Sent from the Xfs - General mailing list archive at Nabble.com. From eflorac@intellique.com Wed Dec 8 04:55:40 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB8Atei9106466 for ; Wed, 8 Dec 2010 04:55:40 -0600 X-ASG-Debug-ID: 1291805845-1de2006e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 42EFC1CA59C7 for ; Wed, 8 Dec 2010 02:57:26 -0800 (PST) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by cuda.sgi.com with ESMTP id fI1CNF4dHqnLMPXY for ; Wed, 08 Dec 2010 02:57:26 -0800 (PST) Received: from harpe.intellique.com (unknown [82.225.196.72]) by smtp4-g21.free.fr (Postfix) with ESMTP id 723284C81A3; Wed, 8 Dec 2010 11:57:21 +0100 (CET) Date: Wed, 8 Dec 2010 11:57:24 +0100 From: Emmanuel Florac To: blacknred Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: kernel panic-xfs errors Subject: Re: kernel panic-xfs errors Message-ID: <20101208115724.0b2c210a@harpe.intellique.com> In-Reply-To: <30403823.post@talk.nabble.com> References: <30397503.post@talk.nabble.com> <20101207222558.GC29333@dastard> <30403823.post@talk.nabble.com> Organization: Intellique X-Mailer: Claws Mail 3.7.3 (GTK+ 2.16.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: smtp4-g21.free.fr[212.27.42.4] X-Barracuda-Start-Time: 1291805848 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.82 X-Barracuda-Spam-Status: No, SCORE=-1.82 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA620b, MAILTO_TO_SPAM_ADDR X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48820 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email 0.20 BSF_SC0_SA620b Custom Rule SA620b X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Le Wed, 8 Dec 2010 01:39:10 -0800 (PST) blacknred =E9crivait: > But now its hung with the 7.x fw as well and same error shows in > dmesg which makes me worried about the fs more.... >=20 Maybe there's a remaining hidden corruption. Could you try with latest xfs_repair ? --=20 ------------------------------------------------------------------------ Emmanuel Florac | Direction technique | Intellique | | +33 1 78 94 84 02 ------------------------------------------------------------------------ From lists@nabble.com Wed Dec 8 07:59:40 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, T_TO_NO_BRKTS_FREEMAIL autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB8DxeTh125525 for ; Wed, 8 Dec 2010 07:59:40 -0600 X-ASG-Debug-ID: 1291816887-2c8401580000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from kuber.nabble.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 21176152A356 for ; Wed, 8 Dec 2010 06:01:27 -0800 (PST) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by cuda.sgi.com with ESMTP id 3GOiO1YTHcoNa4Ay for ; Wed, 08 Dec 2010 06:01:27 -0800 (PST) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1PQKaE-0004m6-IQ for xfs@oss.sgi.com; Wed, 08 Dec 2010 06:01:26 -0800 Message-ID: <30405587.post@talk.nabble.com> Date: Wed, 8 Dec 2010 06:01:26 -0800 (PST) From: blacknred To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: kernel panic-xfs errors Subject: Re: kernel panic-xfs errors In-Reply-To: <20101208115724.0b2c210a@harpe.intellique.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Nabble-From: leo1783@hotmail.co.uk References: <30397503.post@talk.nabble.com> <20101207222558.GC29333@dastard> <30403823.post@talk.nabble.com> <20101208115724.0b2c210a@harpe.intellique.com> X-Barracuda-Connect: kuber.nabble.com[216.139.236.158] X-Barracuda-Start-Time: 1291816888 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=MAILTO_TO_SPAM_ADDR X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48831 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean >Yes, apparently your controller wrote garbage at the beginning of the >filesystem... on that, just wondering if you could provide more info.....=20 As in -is controller writing data in a different location which is not intended to be written to? Or is it case of writing incorrect data causing corruption?.... or could it be an application sw thats gone rogue? but that's a long shot, isn't it.... Emmanuel Florac wrote: >=20 > Le Wed, 8 Dec 2010 01:39:10 -0800 (PST) > blacknred =C3=A9crivait: >=20 >> But now its hung with the 7.x fw as well and same error shows in >> dmesg which makes me worried about the fs more.... >>=20 >=20 > Maybe there's a remaining hidden corruption. Could you try with latest > xfs_repair ? >=20 > --=20 > ------------------------------------------------------------------------ > Emmanuel Florac | Direction technique > | Intellique > |=09 > | +33 1 78 94 84 02 > ------------------------------------------------------------------------ >=20 > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs >=20 >=20 --=20 View this message in context: http://old.nabble.com/kernel-panic-xfs-errors= -tp30397503p30405587.html Sent from the Xfs - General mailing list archive at Nabble.com. From eflorac@intellique.com Wed Dec 8 08:32:44 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB8EWhNi127062 for ; Wed, 8 Dec 2010 08:32:44 -0600 X-ASG-Debug-ID: 1291818869-495b034b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp4-g21.free.fr (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3B39F1D4211 for ; Wed, 8 Dec 2010 06:34:30 -0800 (PST) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by cuda.sgi.com with ESMTP id 4iRW93YAWRhjG0GC for ; Wed, 08 Dec 2010 06:34:30 -0800 (PST) Received: from harpe.intellique.com (unknown [82.225.196.72]) by smtp4-g21.free.fr (Postfix) with ESMTP id 652654C8123; Wed, 8 Dec 2010 15:34:25 +0100 (CET) Date: Wed, 8 Dec 2010 15:34:30 +0100 From: Emmanuel Florac To: blacknred Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: kernel panic-xfs errors Subject: Re: kernel panic-xfs errors Message-ID: <20101208153430.3f5831b3@harpe.intellique.com> In-Reply-To: <30405587.post@talk.nabble.com> References: <30397503.post@talk.nabble.com> <20101207222558.GC29333@dastard> <30403823.post@talk.nabble.com> <20101208115724.0b2c210a@harpe.intellique.com> <30405587.post@talk.nabble.com> Organization: Intellique X-Mailer: Claws Mail 3.7.3 (GTK+ 2.16.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Barracuda-Connect: smtp4-g21.free.fr[212.27.42.4] X-Barracuda-Start-Time: 1291818872 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.82 X-Barracuda-Spam-Status: No, SCORE=-1.82 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA620b, MAILTO_TO_SPAM_ADDR X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48834 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 MAILTO_TO_SPAM_ADDR URI: Includes a link to a likely spammer email 0.20 BSF_SC0_SA620b Custom Rule SA620b X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Le Wed, 8 Dec 2010 06:01:26 -0800 (PST) blacknred =E9crivait: > As in -is controller writing data in a different location which is not > intended to be written to? > Or is it case of writing incorrect data causing corruption?.... >=20 This: XFS: bad magic number XFS: SB validate failed=20 Seems to indicate that the beginning of the filesystem was somehow corrupted. Just like the log was apparently truncated on the other server. That's why I though that you had a power failure and that an incomplete write operation was the culprit. --=20 ------------------------------------------------------------------------ Emmanuel Florac | Direction technique | Intellique | | +33 1 78 94 84 02 ------------------------------------------------------------------------ From jensen_lorn@ns2.pagdigit.com.ar Wed Dec 8 10:15:58 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: **** X-Spam-Status: No, score=4.0 required=5.0 tests=BAYES_99 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB8GFwvq131771 for ; Wed, 8 Dec 2010 10:15:58 -0600 X-ASG-Debug-ID: 1291825064-3b7b01f00000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from paginadigital.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BDF6B1CA6D58 for ; Wed, 8 Dec 2010 08:17:45 -0800 (PST) Received: from paginadigital.net (ns2.pagdigit.com.ar [190.111.202.203]) by cuda.sgi.com with ESMTP id 0NRnbe0sCUYDwoL6 for ; Wed, 08 Dec 2010 08:17:45 -0800 (PST) Received: from pummel ([212.95.43.194]) by paginadigital.net (paginadigital.net) (MDaemon.PRO.v7.2.0.R) with ESMTP id md50012828377.msg for ; Wed, 08 Dec 2010 13:28:31 -0300 To: 20hbreslin@whag.com, xfs@oss.sgi.com, info@queensgatehypnotherapy.co.uk, sanjuan.escherick@state.ut.us, info@hotel-marzia.it X-ASG-Orig-Subj: [rft 86] : business list Subject: [rft 86] : business list Reply-To: jensen_lorn@ns2.pagdigit.com.ar From: "lindholm" X-Lookup-Warning: MAIL lookup on jensen_lorn@ns2.pagdigit.com.ar does not match 212.95.43.194 X-MDRemoteIP: 212.95.43.194 X-Return-Path: jensen_lorn@ns2.pagdigit.com.ar X-MDaemon-Deliver-To: xfs@oss.sgi.com X-Barracuda-Connect: ns2.pagdigit.com.ar[190.111.202.203] X-Barracuda-Start-Time: 1291825065 Message-Id: <20101208161745.BDF6B1CA6D58@cuda.sgi.com> Date: Wed, 8 Dec 2010 08:17:45 -0800 (PST) X-Barracuda-Bayes: INNOCENT GLOBAL 0.5173 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.89 X-Barracuda-Spam-Status: No, SCORE=0.89 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_MISSING_MID X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48840 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.14 BSF_SC0_MISSING_MID BODY: Custom Rule BSF_SC0_MISSING_MID X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean We have the following high-quality lists: ( HEALTHCARE ) - Doctors (34 different specialties) - Chiropractors - Alternative Medicine - Dentists - Dentists with Specialties - Veterinarians - Hospitals - National Health Service Corp Clinics - Nursing Homes - Pharmaceutical Companies - Physical Therapists - Oncology Doctors - US Surgery Centers - Massage Therapists - Acupuncturists - Medical Equipment Suppliers - Mental Health Counselors - Visiting Nurses & RN's - Optometrists - Psychologists ( BUSINESS LISTS ) - Hotels - Real Estate Agents - American Business Email List - US New Business Database - Manufacturers Database - Financial Planners Database - Finance and Money Professionals Database - Insurance Agents - Canadian Businesses - United Kingdom Business Database - Media Outlet Contacts ( CONSUMER LISTS ) - American Consumer Database - Credit Inquiries Database - American Homeowners ( PROFESSIONALS LISTS ) - USA Lawyers Database - Police and Sheriff Services - Criminal Attorneys - 142,906 Email me here for counts and samples: masterlists@gmx.us If the above email bounces please call 1-206-338-9752 instead. ramove me from your list please send an email to getridofit@gmx.com From whitewolf573@gmail.com Wed Dec 8 13:30:43 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.3 required=5.0 tests=BAYES_40,FREEMAIL_FROM, HTML_MESSAGE,J_CHICKENPOX_36,J_CHICKENPOX_43,J_CHICKENPOX_54,T_DKIM_INVALID, T_TO_NO_BRKTS_FREEMAIL autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB8JUh5c140869 for ; Wed, 8 Dec 2010 13:30:43 -0600 X-ASG-Debug-ID: 1291836749-4b7a03640000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-ey0-f179.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 341741431218 for ; Wed, 8 Dec 2010 11:32:29 -0800 (PST) Received: from mail-ey0-f179.google.com (mail-ey0-f179.google.com [209.85.215.179]) by cuda.sgi.com with ESMTP id hWfGWacONSYFAf1A for ; Wed, 08 Dec 2010 11:32:29 -0800 (PST) Received: by eyg24 with SMTP id 24so1137538eyg.38 for ; Wed, 08 Dec 2010 11:32:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=u1mzth+HJLjS74h3hLIto87PEZpTuswgkAMbwuCnYgA=; b=EqSdm8apt0W4/eade4Z4Mfsvlueefd4cbVnPBADcOW+Og2tmFnaPQ2dEEx5Ohh5Diu s92x/89qRvanrSU00dscfreSbefdCrZchO8lcTk17omKwPNChHcIbz1vkIRPsnyrOPlw J8GOmSCqKJaOeYagAnxop3Mi0jLhybDF+f9YU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=qT2TiwH9N46XtBcC5+Kkj4z0Cipq3HYqLt4wkTecIGm9o0gfGpwhXPN02SSIHF050x 9NyGE/DRByXQwjhnkCMyhjX2JwJD6M659Ya9RdkZNa6t/H+yQQ5rRgmE3xnsRvAamziX T1WnKX8z2xdji9Gy3+cYQjCVe6RRAOP4EKmV4= MIME-Version: 1.0 Received: by 10.213.30.20 with SMTP id s20mr9975063ebc.16.1291836748617; Wed, 08 Dec 2010 11:32:28 -0800 (PST) Received: by 10.213.33.146 with HTTP; Wed, 8 Dec 2010 11:32:28 -0800 (PST) Date: Wed, 8 Dec 2010 20:32:28 +0100 Message-ID: X-ASG-Orig-Subj: xfs tuning for a 830 GB partition (mkfs.xfs options) Subject: xfs tuning for a 830 GB partition (mkfs.xfs options) From: Abel Coto To: xfs@oss.sgi.com Content-Type: multipart/alternative; boundary=000e0cd1e32a82577f0496eb2e94 X-Barracuda-Connect: mail-ey0-f179.google.com[209.85.215.179] X-Barracuda-Start-Time: 1291836751 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.61 X-Barracuda-Spam-Status: No, SCORE=-1.61 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=DKIM_SIGNED, DKIM_VERIFIED, HTML_MESSAGE, SUBJECT_FUZZY_TION X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48853 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.41 SUBJECT_FUZZY_TION Attempt to obfuscate words in Subject: -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean --000e0cd1e32a82577f0496eb2e94 Content-Type: text/plain; charset=ISO-8859-1 I want to create a 830 GB partition, to mount as /home in my Centos 5.4 workstation. Actually i have /home not mounted ,so i would have to create the new partition in the lvm,format it and use rsync to copy /home directory to it. for a 830 GB partition that i will use to save my data in general and also 3d / CG projects and renders once finished them what agcount value should be used. I have read that mkfs default option creates 1 allocation group each 4G , so i understand that for a 830 GB partition agcount should be 208. It is this correct ? so i would use for format the partition mkfs.xfs -l lazy-count=1,version=2,size=128m -i attr=2 -d agcount=208 -L VolumeName I have read that some people instead use a 8GB allocation size , and agcount Size partition / 8 GB (in my case 104) , but i don't know if that would be good , as would result in less allocation groups. i understand if agcount > 208 (for example 416 ) , the allocation size (2GB for agcount=416) would be less than 4 GB , to have in total 830 GB. I have read that too much allocation groups are bad , but i don't now if 416 are too much for a 830 GB partition (and shoukd use 208 to 300) or not. I will mount the partition with logbufs=8. (i use a 128m journal and logbufs=8 to improve a bit deleting performance). I will perhaps use noatime too ,but i have to see if my backup app, uses atime or not. I have another 1,5 TB HDD where i want to create a 350 GB xfs partition to save the 3d projects and render output when working with the 3d software i use (Maya 2011). My thoughts are to use /home to save both music , photography,isos,etc also of finished 3d / cg work and iso dvd / tutorials and video-tutorials ,and this 350 GB partition use it only for data and projects that i am still working with,and once finished copy to /home. for this partition , that will handle mostly big files (500 MB to 2-3 GB at least) what mkfs.xfs options should i use ? something like: mkfs.xfs -l lazy-count=1,version=2,size=128m -i attr=2 -d agcount=90 -L VolumeName (350/4 --> 88) I prefer to have a separate partition to save projects at least when i am working with them , although 3d modelling is not too much filesystem bounded , and then copy it to /home , as i think having a good backup strategy shoud not be a problem to have my music and data along with 3d work finished in the same partition (3d is for me a hobby,that i like a lot but a hobby) I will have to compile a custom kernel from kernel.org because my centos kernel is 2.6.18,and there is no higher one available, only compiling it, but this shouldn't be a problem. --000e0cd1e32a82577f0496eb2e94 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I want to create a 830 GB partition, to mount as /home in my Centos 5.4 wor= kstation.

Actually i have /home not mounted ,so i would have to cre= ate the new partition in the lvm,format it and use rsync to copy /home dire= ctory to it.

for a 830 GB partition that i will use to save my data in general and a= lso 3d / CG projects and renders once finished them what agcount value shou= ld be used. I have read that mkfs default option creates 1 allocation group= each 4G , so i understand that for a 830 GB partition agcount should be 20= 8.

It is this correct ?

so i would use for format the partition
mkfs.xfs -l lazy-count=3D1,version=3D2,size=3D128m -i attr=3D2 -d agc= ount=3D208 -L VolumeName <dev>

I have read that some people in= stead use a 8GB allocation size , and agcount Size partition / 8 GB (in my = case 104) , but i don't know if that would be good , as would result in= less allocation groups.

i understand if agcount > 208=A0 (for example 416 ) , the allocation= size (2GB for agcount=3D416) would be less than 4 GB , to have in total 83= 0 GB.

I have read that too much allocation groups are bad , but i do= n't now if 416 are=A0 too much for a 830 GB partition (and shoukd use 2= 08 to 300) or not.

I will mount the partition with logbufs=3D8. (i use a 128m journal and = logbufs=3D8 to improve a bit deleting performance). I will perhaps use noat= ime too ,but i have to see if my backup app, uses atime or not.


I have another 1,5 TB HDD where i want to create a 350 GB xfs partition to = save the 3d projects and render output when working with the 3d software i = use (Maya 2011). My thoughts are to use /home to save both music , photogra= phy,isos,etc also of finished 3d / cg work and iso dvd / tutorials and vide= o-tutorials ,and this 350 GB partition use it only for data and projects th= at i am still working with,and once finished copy to /home.

for this partition , that will handle mostly big files (500 MB to 2-3 G= B at least) what mkfs.xfs options should i use ?

something like:
=
mkfs.xfs -l lazy-count=3D1,version=3D2,size=3D128m -i attr=3D2 -d agcou= nt=3D90 -L VolumeName <dev>=A0 (350/4 --> 88)

I prefer to have a separate partition to save projects at least when i = am working with them , although 3d modelling is not too much filesystem bou= nded , and then copy it to /home , as i think having a good backup strategy= shoud not be a problem to have my music and data along with 3d work finish= ed in the same partition (3d is for me a hobby,that i like a lot but a hobb= y)

I will have to compile a custom kernel from kernel.org because my centos kernel is 2.6.18,and there is no higher= one available, only compiling it, but this shouldn't be a problem.
--000e0cd1e32a82577f0496eb2e94-- From eparis@redhat.com Wed Dec 8 13:46:02 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,J_CHICKENPOX_25, J_CHICKENPOX_26,J_CHICKENPOX_66,J_CHICKENPOX_73 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB8Jk1bD141667 for ; Wed, 8 Dec 2010 13:46:02 -0600 X-ASG-Debug-ID: 1291837669-1e1800ed0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A8AE81CA7B05; Wed, 8 Dec 2010 11:47:49 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id yfFhfqanUD4ZiYA6; Wed, 08 Dec 2010 11:47:49 -0800 (PST) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oB8Jk1lX031193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 8 Dec 2010 14:46:01 -0500 Received: from paris.rdu.redhat.com (paris.rdu.redhat.com [10.11.231.241]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id oB8Jjqe9004807; Wed, 8 Dec 2010 14:45:52 -0500 From: Eric Paris X-ASG-Orig-Subj: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation Subject: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation To: xfs-masters@oss.sgi.com, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, cluster-devel@redhat.com, linux-mtd@lists.infradead.org, jfs-discussion@lists.sourceforge.net, ocfs2-devel@oss.oracle.com, reiserfs-devel@vger.kernel.org, xfs@oss.sgi.com, linux-mm@kvack.org, linux-security-module@vger.kernel.org Cc: chris.mason@oracle.com, jack@suse.cz, akpm@linux-foundation.org, adilger.kernel@dilger.ca, tytso@mit.edu, swhiteho@redhat.com, dwmw2@infradead.org, shaggy@linux.vnet.ibm.com, mfasheh@suse.com, joel.becker@oracle.com, aelder@sgi.com, hughd@google.com, jmorris@namei.org, sds@tycho.nsa.gov, eparis@parisplace.org, hch@lst.de, dchinner@redhat.com, viro@zeniv.linux.org.uk, tao.ma@oracle.com, shemminger@vyatta.com, jeffm@suse.com, serue@us.ibm.com, paul.moore@hp.com, penguin-kernel@I-love.SAKURA.ne.jp, casey@schaufler-ca.com, kees.cook@canonical.com, dhowells@redhat.com Date: Wed, 08 Dec 2010 14:45:27 -0500 Message-ID: <20101208194527.13537.77202.stgit@paris.rdu.redhat.com> User-Agent: StGIT/0.14.3 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1291837670 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean SELinux would like to implement a new labeling behavior of newly created inodes. We currently label new inodes based on the parent and the creating process. This new behavior would also take into account the name of the new object when deciding the new label. This is not the (supposed) full path, just the last component of the path. This is very useful because creating /etc/shadow is different than creating /etc/passwd but the kernel hooks are unable to differentiate these operations. We currently require that userspace realize it is doing some difficult operation like that and than userspace jumps through SELinux hoops to get things set up correctly. This patch does not implement new behavior, that is obviously contained in a seperate SELinux patch, but it does pass the needed name down to the correct LSM hook. If no such name exists it is fine to pass NULL. Signed-off-by: Eric Paris --- fs/btrfs/inode.c | 13 +++++++------ fs/btrfs/xattr.c | 6 ++++-- fs/btrfs/xattr.h | 3 ++- fs/ext2/ext2.h | 2 +- fs/ext2/ialloc.c | 5 +++-- fs/ext2/namei.c | 8 ++++---- fs/ext2/xattr.h | 6 ++++-- fs/ext2/xattr_security.c | 5 +++-- fs/ext3/ialloc.c | 5 +++-- fs/ext3/namei.c | 8 ++++---- fs/ext3/xattr.h | 4 ++-- fs/ext3/xattr_security.c | 5 +++-- fs/ext4/ialloc.c | 2 +- fs/ext4/xattr.h | 4 ++-- fs/ext4/xattr_security.c | 5 +++-- fs/gfs2/inode.c | 7 ++++--- fs/jffs2/dir.c | 9 ++++----- fs/jffs2/nodelist.h | 2 +- fs/jffs2/security.c | 5 +++-- fs/jffs2/write.c | 18 ++++++++++-------- fs/jffs2/xattr.h | 5 +++-- fs/jfs/jfs_xattr.h | 5 +++-- fs/jfs/namei.c | 8 ++++---- fs/jfs/xattr.c | 6 ++++-- fs/ocfs2/namei.c | 4 ++-- fs/ocfs2/refcounttree.c | 3 ++- fs/ocfs2/xattr.c | 10 ++++++---- fs/ocfs2/xattr.h | 4 +++- fs/reiserfs/namei.c | 9 +++++---- fs/reiserfs/xattr_security.c | 3 ++- fs/xfs/linux-2.6/xfs_iops.c | 9 +++++---- include/linux/ext3_fs.h | 3 ++- include/linux/reiserfs_xattr.h | 2 ++ include/linux/security.h | 9 +++++++-- mm/shmem.c | 9 +++++---- security/capability.c | 3 ++- security/security.c | 6 ++++-- security/selinux/hooks.c | 5 +++-- security/smack/smack_lsm.c | 5 ++++- 39 files changed, 136 insertions(+), 94 deletions(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 8039390..ffc6e15 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -90,13 +90,14 @@ static noinline int cow_file_range(struct inode *inode, unsigned long *nr_written, int unlock); static int btrfs_init_inode_security(struct btrfs_trans_handle *trans, - struct inode *inode, struct inode *dir) + struct inode *inode, struct inode *dir, + const struct qstr *qstr) { int err; err = btrfs_init_acl(trans, inode, dir); if (!err) - err = btrfs_xattr_security_init(trans, inode, dir); + err = btrfs_xattr_security_init(trans, inode, dir, qstr); return err; } @@ -4675,7 +4676,7 @@ static int btrfs_mknod(struct inode *dir, struct dentry *dentry, if (IS_ERR(inode)) goto out_unlock; - err = btrfs_init_inode_security(trans, inode, dir); + err = btrfs_init_inode_security(trans, inode, dir, &dentry->d_name); if (err) { drop_inode = 1; goto out_unlock; @@ -4736,7 +4737,7 @@ static int btrfs_create(struct inode *dir, struct dentry *dentry, if (IS_ERR(inode)) goto out_unlock; - err = btrfs_init_inode_security(trans, inode, dir); + err = btrfs_init_inode_security(trans, inode, dir, &dentry->d_name); if (err) { drop_inode = 1; goto out_unlock; @@ -4864,7 +4865,7 @@ static int btrfs_mkdir(struct inode *dir, struct dentry *dentry, int mode) drop_on_err = 1; - err = btrfs_init_inode_security(trans, inode, dir); + err = btrfs_init_inode_security(trans, inode, dir, &dentry->d_name); if (err) goto out_fail; @@ -6940,7 +6941,7 @@ static int btrfs_symlink(struct inode *dir, struct dentry *dentry, if (IS_ERR(inode)) goto out_unlock; - err = btrfs_init_inode_security(trans, inode, dir); + err = btrfs_init_inode_security(trans, inode, dir, &dentry->d_name); if (err) { drop_inode = 1; goto out_unlock; diff --git a/fs/btrfs/xattr.c b/fs/btrfs/xattr.c index 698fdd2..3338a7e 100644 --- a/fs/btrfs/xattr.c +++ b/fs/btrfs/xattr.c @@ -352,7 +352,8 @@ int btrfs_removexattr(struct dentry *dentry, const char *name) } int btrfs_xattr_security_init(struct btrfs_trans_handle *trans, - struct inode *inode, struct inode *dir) + struct inode *inode, struct inode *dir, + const struct qstr *qstr) { int err; size_t len; @@ -360,7 +361,8 @@ int btrfs_xattr_security_init(struct btrfs_trans_handle *trans, char *suffix; char *name; - err = security_inode_init_security(inode, dir, &suffix, &value, &len); + err = security_inode_init_security(inode, dir, qstr, &suffix, &value, + &len); if (err) { if (err == -EOPNOTSUPP) return 0; diff --git a/fs/btrfs/xattr.h b/fs/btrfs/xattr.h index 7a43fd6..b3cc803 100644 --- a/fs/btrfs/xattr.h +++ b/fs/btrfs/xattr.h @@ -37,6 +37,7 @@ extern int btrfs_setxattr(struct dentry *dentry, const char *name, extern int btrfs_removexattr(struct dentry *dentry, const char *name); extern int btrfs_xattr_security_init(struct btrfs_trans_handle *trans, - struct inode *inode, struct inode *dir); + struct inode *inode, struct inode *dir, + const struct qstr *qstr); #endif /* __XATTR__ */ diff --git a/fs/ext2/ext2.h b/fs/ext2/ext2.h index 6346a2a..1b48c33 100644 --- a/fs/ext2/ext2.h +++ b/fs/ext2/ext2.h @@ -110,7 +110,7 @@ extern struct ext2_dir_entry_2 * ext2_dotdot (struct inode *, struct page **); extern void ext2_set_link(struct inode *, struct ext2_dir_entry_2 *, struct page *, struct inode *, int); /* ialloc.c */ -extern struct inode * ext2_new_inode (struct inode *, int); +extern struct inode * ext2_new_inode (struct inode *, int, const struct qstr *); extern void ext2_free_inode (struct inode *); extern unsigned long ext2_count_free_inodes (struct super_block *); extern void ext2_check_inodes_bitmap (struct super_block *); diff --git a/fs/ext2/ialloc.c b/fs/ext2/ialloc.c index ad70479..ee9ed31 100644 --- a/fs/ext2/ialloc.c +++ b/fs/ext2/ialloc.c @@ -429,7 +429,8 @@ found: return group; } -struct inode *ext2_new_inode(struct inode *dir, int mode) +struct inode *ext2_new_inode(struct inode *dir, int mode, + const struct qstr *qstr) { struct super_block *sb; struct buffer_head *bitmap_bh = NULL; @@ -585,7 +586,7 @@ got: if (err) goto fail_free_drop; - err = ext2_init_security(inode,dir); + err = ext2_init_security(inode, dir, qstr); if (err) goto fail_free_drop; diff --git a/fs/ext2/namei.c b/fs/ext2/namei.c index f8aecd2..368d704 100644 --- a/fs/ext2/namei.c +++ b/fs/ext2/namei.c @@ -104,7 +104,7 @@ static int ext2_create (struct inode * dir, struct dentry * dentry, int mode, st dquot_initialize(dir); - inode = ext2_new_inode(dir, mode); + inode = ext2_new_inode(dir, mode, &dentry->d_name); if (IS_ERR(inode)) return PTR_ERR(inode); @@ -133,7 +133,7 @@ static int ext2_mknod (struct inode * dir, struct dentry *dentry, int mode, dev_ dquot_initialize(dir); - inode = ext2_new_inode (dir, mode); + inode = ext2_new_inode (dir, mode, &dentry->d_name); err = PTR_ERR(inode); if (!IS_ERR(inode)) { init_special_inode(inode, inode->i_mode, rdev); @@ -159,7 +159,7 @@ static int ext2_symlink (struct inode * dir, struct dentry * dentry, dquot_initialize(dir); - inode = ext2_new_inode (dir, S_IFLNK | S_IRWXUGO); + inode = ext2_new_inode (dir, S_IFLNK | S_IRWXUGO, &dentry->d_name); err = PTR_ERR(inode); if (IS_ERR(inode)) goto out; @@ -230,7 +230,7 @@ static int ext2_mkdir(struct inode * dir, struct dentry * dentry, int mode) inode_inc_link_count(dir); - inode = ext2_new_inode (dir, S_IFDIR | mode); + inode = ext2_new_inode(dir, S_IFDIR | mode, &dentry->d_name); err = PTR_ERR(inode); if (IS_ERR(inode)) goto out_dir; diff --git a/fs/ext2/xattr.h b/fs/ext2/xattr.h index a1a1c21..5e41ccc 100644 --- a/fs/ext2/xattr.h +++ b/fs/ext2/xattr.h @@ -116,9 +116,11 @@ exit_ext2_xattr(void) # endif /* CONFIG_EXT2_FS_XATTR */ #ifdef CONFIG_EXT2_FS_SECURITY -extern int ext2_init_security(struct inode *inode, struct inode *dir); +extern int ext2_init_security(struct inode *inode, struct inode *dir, + const struct qstr *qstr); #else -static inline int ext2_init_security(struct inode *inode, struct inode *dir) +static inline int ext2_init_security(struct inode *inode, struct inode *dir, + const struct qstr *qstr) { return 0; } diff --git a/fs/ext2/xattr_security.c b/fs/ext2/xattr_security.c index 3004e15..5d979b4 100644 --- a/fs/ext2/xattr_security.c +++ b/fs/ext2/xattr_security.c @@ -47,14 +47,15 @@ ext2_xattr_security_set(struct dentry *dentry, const char *name, } int -ext2_init_security(struct inode *inode, struct inode *dir) +ext2_init_security(struct inode *inode, struct inode *dir, + const struct qstr *qstr) { int err; size_t len; void *value; char *name; - err = security_inode_init_security(inode, dir, &name, &value, &len); + err = security_inode_init_security(inode, dir, qstr, &name, &value, &len); if (err) { if (err == -EOPNOTSUPP) return 0; diff --git a/fs/ext3/ialloc.c b/fs/ext3/ialloc.c index 9724aef..bfc2dc4 100644 --- a/fs/ext3/ialloc.c +++ b/fs/ext3/ialloc.c @@ -404,7 +404,8 @@ static int find_group_other(struct super_block *sb, struct inode *parent) * For other inodes, search forward from the parent directory's block * group to find a free inode. */ -struct inode *ext3_new_inode(handle_t *handle, struct inode * dir, int mode) +struct inode *ext3_new_inode(handle_t *handle, struct inode * dir, + const struct qstr *qstr, int mode) { struct super_block *sb; struct buffer_head *bitmap_bh = NULL; @@ -589,7 +590,7 @@ got: if (err) goto fail_free_drop; - err = ext3_init_security(handle,inode, dir); + err = ext3_init_security(handle, inode, dir, qstr); if (err) goto fail_free_drop; diff --git a/fs/ext3/namei.c b/fs/ext3/namei.c index bce9dce..a900033 100644 --- a/fs/ext3/namei.c +++ b/fs/ext3/namei.c @@ -1707,7 +1707,7 @@ retry: if (IS_DIRSYNC(dir)) handle->h_sync = 1; - inode = ext3_new_inode (handle, dir, mode); + inode = ext3_new_inode (handle, dir, &dentry->d_name, mode); err = PTR_ERR(inode); if (!IS_ERR(inode)) { inode->i_op = &ext3_file_inode_operations; @@ -1743,7 +1743,7 @@ retry: if (IS_DIRSYNC(dir)) handle->h_sync = 1; - inode = ext3_new_inode (handle, dir, mode); + inode = ext3_new_inode (handle, dir, &dentry->d_name, mode); err = PTR_ERR(inode); if (!IS_ERR(inode)) { init_special_inode(inode, inode->i_mode, rdev); @@ -1781,7 +1781,7 @@ retry: if (IS_DIRSYNC(dir)) handle->h_sync = 1; - inode = ext3_new_inode (handle, dir, S_IFDIR | mode); + inode = ext3_new_inode (handle, dir, &dentry->d_name, S_IFDIR | mode); err = PTR_ERR(inode); if (IS_ERR(inode)) goto out_stop; @@ -2195,7 +2195,7 @@ retry: if (IS_DIRSYNC(dir)) handle->h_sync = 1; - inode = ext3_new_inode (handle, dir, S_IFLNK|S_IRWXUGO); + inode = ext3_new_inode (handle, dir, &dentry->d_name, S_IFLNK|S_IRWXUGO); err = PTR_ERR(inode); if (IS_ERR(inode)) goto out_stop; diff --git a/fs/ext3/xattr.h b/fs/ext3/xattr.h index 377fe72..2be4f69 100644 --- a/fs/ext3/xattr.h +++ b/fs/ext3/xattr.h @@ -128,10 +128,10 @@ exit_ext3_xattr(void) #ifdef CONFIG_EXT3_FS_SECURITY extern int ext3_init_security(handle_t *handle, struct inode *inode, - struct inode *dir); + struct inode *dir, const struct qstr *qstr); #else static inline int ext3_init_security(handle_t *handle, struct inode *inode, - struct inode *dir) + struct inode *dir, const struct qstr *qstr) { return 0; } diff --git a/fs/ext3/xattr_security.c b/fs/ext3/xattr_security.c index 03a99bf..b8d9f83 100644 --- a/fs/ext3/xattr_security.c +++ b/fs/ext3/xattr_security.c @@ -49,14 +49,15 @@ ext3_xattr_security_set(struct dentry *dentry, const char *name, } int -ext3_init_security(handle_t *handle, struct inode *inode, struct inode *dir) +ext3_init_security(handle_t *handle, struct inode *inode, struct inode *dir, + const struct qstr *qstr) { int err; size_t len; void *value; char *name; - err = security_inode_init_security(inode, dir, &name, &value, &len); + err = security_inode_init_security(inode, dir, qstr, &name, &value, &len); if (err) { if (err == -EOPNOTSUPP) return 0; diff --git a/fs/ext4/ialloc.c b/fs/ext4/ialloc.c index 1ce240a..49b6cfd 100644 --- a/fs/ext4/ialloc.c +++ b/fs/ext4/ialloc.c @@ -1042,7 +1042,7 @@ got: if (err) goto fail_free_drop; - err = ext4_init_security(handle, inode, dir); + err = ext4_init_security(handle, inode, dir, qstr); if (err) goto fail_free_drop; diff --git a/fs/ext4/xattr.h b/fs/ext4/xattr.h index 1ef1652..25b7387 100644 --- a/fs/ext4/xattr.h +++ b/fs/ext4/xattr.h @@ -145,10 +145,10 @@ ext4_expand_extra_isize_ea(struct inode *inode, int new_extra_isize, #ifdef CONFIG_EXT4_FS_SECURITY extern int ext4_init_security(handle_t *handle, struct inode *inode, - struct inode *dir); + struct inode *dir, const struct qstr *qstr); #else static inline int ext4_init_security(handle_t *handle, struct inode *inode, - struct inode *dir) + struct inode *dir, const struct qstr *qstr) { return 0; } diff --git a/fs/ext4/xattr_security.c b/fs/ext4/xattr_security.c index 9b21268..007c3bf 100644 --- a/fs/ext4/xattr_security.c +++ b/fs/ext4/xattr_security.c @@ -49,14 +49,15 @@ ext4_xattr_security_set(struct dentry *dentry, const char *name, } int -ext4_init_security(handle_t *handle, struct inode *inode, struct inode *dir) +ext4_init_security(handle_t *handle, struct inode *inode, struct inode *dir, + const struct qstr *qstr) { int err; size_t len; void *value; char *name; - err = security_inode_init_security(inode, dir, &name, &value, &len); + err = security_inode_init_security(inode, dir, qstr, &name, &value, &len); if (err) { if (err == -EOPNOTSUPP) return 0; diff --git a/fs/gfs2/inode.c b/fs/gfs2/inode.c index e1213f7..52fd31e 100644 --- a/fs/gfs2/inode.c +++ b/fs/gfs2/inode.c @@ -791,14 +791,15 @@ fail: return error; } -static int gfs2_security_init(struct gfs2_inode *dip, struct gfs2_inode *ip) +static int gfs2_security_init(struct gfs2_inode *dip, struct gfs2_inode *ip, + const struct qstr *qstr) { int err; size_t len; void *value; char *name; - err = security_inode_init_security(&ip->i_inode, &dip->i_inode, + err = security_inode_init_security(&ip->i_inode, &dip->i_inode, qstr, &name, &value, &len); if (err) { @@ -882,7 +883,7 @@ struct inode *gfs2_createi(struct gfs2_holder *ghs, const struct qstr *name, if (error) goto fail_gunlock2; - error = gfs2_security_init(dip, GFS2_I(inode)); + error = gfs2_security_init(dip, GFS2_I(inode), name); if (error) goto fail_gunlock2; diff --git a/fs/jffs2/dir.c b/fs/jffs2/dir.c index 9297865..82faddd 100644 --- a/fs/jffs2/dir.c +++ b/fs/jffs2/dir.c @@ -215,8 +215,7 @@ static int jffs2_create(struct inode *dir_i, struct dentry *dentry, int mode, no chance of AB-BA deadlock involving its f->sem). */ mutex_unlock(&f->sem); - ret = jffs2_do_create(c, dir_f, f, ri, - dentry->d_name.name, dentry->d_name.len); + ret = jffs2_do_create(c, dir_f, f, ri, &dentry->d_name); if (ret) goto fail; @@ -386,7 +385,7 @@ static int jffs2_symlink (struct inode *dir_i, struct dentry *dentry, const char jffs2_complete_reservation(c); - ret = jffs2_init_security(inode, dir_i); + ret = jffs2_init_security(inode, dir_i, &dentry->d_name); if (ret) goto fail; @@ -530,7 +529,7 @@ static int jffs2_mkdir (struct inode *dir_i, struct dentry *dentry, int mode) jffs2_complete_reservation(c); - ret = jffs2_init_security(inode, dir_i); + ret = jffs2_init_security(inode, dir_i, &dentry->d_name); if (ret) goto fail; @@ -703,7 +702,7 @@ static int jffs2_mknod (struct inode *dir_i, struct dentry *dentry, int mode, de jffs2_complete_reservation(c); - ret = jffs2_init_security(inode, dir_i); + ret = jffs2_init_security(inode, dir_i, &dentry->d_name); if (ret) goto fail; diff --git a/fs/jffs2/nodelist.h b/fs/jffs2/nodelist.h index 5a53d9b..e4619b0 100644 --- a/fs/jffs2/nodelist.h +++ b/fs/jffs2/nodelist.h @@ -401,7 +401,7 @@ int jffs2_write_inode_range(struct jffs2_sb_info *c, struct jffs2_inode_info *f, struct jffs2_raw_inode *ri, unsigned char *buf, uint32_t offset, uint32_t writelen, uint32_t *retlen); int jffs2_do_create(struct jffs2_sb_info *c, struct jffs2_inode_info *dir_f, struct jffs2_inode_info *f, - struct jffs2_raw_inode *ri, const char *name, int namelen); + struct jffs2_raw_inode *ri, const struct qstr *qstr); int jffs2_do_unlink(struct jffs2_sb_info *c, struct jffs2_inode_info *dir_f, const char *name, int namelen, struct jffs2_inode_info *dead_f, uint32_t time); int jffs2_do_link(struct jffs2_sb_info *c, struct jffs2_inode_info *dir_f, uint32_t ino, diff --git a/fs/jffs2/security.c b/fs/jffs2/security.c index 239f512..cfeb716 100644 --- a/fs/jffs2/security.c +++ b/fs/jffs2/security.c @@ -23,14 +23,15 @@ #include "nodelist.h" /* ---- Initial Security Label Attachment -------------- */ -int jffs2_init_security(struct inode *inode, struct inode *dir) +int jffs2_init_security(struct inode *inode, struct inode *dir, + const struct qstr *qstr) { int rc; size_t len; void *value; char *name; - rc = security_inode_init_security(inode, dir, &name, &value, &len); + rc = security_inode_init_security(inode, dir, qstr, &name, &value, &len); if (rc) { if (rc == -EOPNOTSUPP) return 0; diff --git a/fs/jffs2/write.c b/fs/jffs2/write.c index c819eb0..30d175b 100644 --- a/fs/jffs2/write.c +++ b/fs/jffs2/write.c @@ -424,7 +424,9 @@ int jffs2_write_inode_range(struct jffs2_sb_info *c, struct jffs2_inode_info *f, return ret; } -int jffs2_do_create(struct jffs2_sb_info *c, struct jffs2_inode_info *dir_f, struct jffs2_inode_info *f, struct jffs2_raw_inode *ri, const char *name, int namelen) +int jffs2_do_create(struct jffs2_sb_info *c, struct jffs2_inode_info *dir_f, + struct jffs2_inode_info *f, struct jffs2_raw_inode *ri, + const struct qstr *qstr) { struct jffs2_raw_dirent *rd; struct jffs2_full_dnode *fn; @@ -466,15 +468,15 @@ int jffs2_do_create(struct jffs2_sb_info *c, struct jffs2_inode_info *dir_f, str mutex_unlock(&f->sem); jffs2_complete_reservation(c); - ret = jffs2_init_security(&f->vfs_inode, &dir_f->vfs_inode); + ret = jffs2_init_security(&f->vfs_inode, &dir_f->vfs_inode, qstr); if (ret) return ret; ret = jffs2_init_acl_post(&f->vfs_inode); if (ret) return ret; - ret = jffs2_reserve_space(c, sizeof(*rd)+namelen, &alloclen, - ALLOC_NORMAL, JFFS2_SUMMARY_DIRENT_SIZE(namelen)); + ret = jffs2_reserve_space(c, sizeof(*rd)+qstr->len, &alloclen, + ALLOC_NORMAL, JFFS2_SUMMARY_DIRENT_SIZE(qstr->len)); if (ret) { /* Eep. */ @@ -493,19 +495,19 @@ int jffs2_do_create(struct jffs2_sb_info *c, struct jffs2_inode_info *dir_f, str rd->magic = cpu_to_je16(JFFS2_MAGIC_BITMASK); rd->nodetype = cpu_to_je16(JFFS2_NODETYPE_DIRENT); - rd->totlen = cpu_to_je32(sizeof(*rd) + namelen); + rd->totlen = cpu_to_je32(sizeof(*rd) + qstr->len); rd->hdr_crc = cpu_to_je32(crc32(0, rd, sizeof(struct jffs2_unknown_node)-4)); rd->pino = cpu_to_je32(dir_f->inocache->ino); rd->version = cpu_to_je32(++dir_f->highest_version); rd->ino = ri->ino; rd->mctime = ri->ctime; - rd->nsize = namelen; + rd->nsize = qstr->len; rd->type = DT_REG; rd->node_crc = cpu_to_je32(crc32(0, rd, sizeof(*rd)-8)); - rd->name_crc = cpu_to_je32(crc32(0, name, namelen)); + rd->name_crc = cpu_to_je32(crc32(0, qstr->name, qstr->len)); - fd = jffs2_write_dirent(c, dir_f, rd, name, namelen, ALLOC_NORMAL); + fd = jffs2_write_dirent(c, dir_f, rd, qstr->name, qstr->len, ALLOC_NORMAL); jffs2_free_raw_dirent(rd); diff --git a/fs/jffs2/xattr.h b/fs/jffs2/xattr.h index cf4f575..7be4beb 100644 --- a/fs/jffs2/xattr.h +++ b/fs/jffs2/xattr.h @@ -121,10 +121,11 @@ extern ssize_t jffs2_listxattr(struct dentry *, char *, size_t); #endif /* CONFIG_JFFS2_FS_XATTR */ #ifdef CONFIG_JFFS2_FS_SECURITY -extern int jffs2_init_security(struct inode *inode, struct inode *dir); +extern int jffs2_init_security(struct inode *inode, struct inode *dir, + const struct qstr *qstr); extern const struct xattr_handler jffs2_security_xattr_handler; #else -#define jffs2_init_security(inode,dir) (0) +#define jffs2_init_security(inode,dir,qstr) (0) #endif /* CONFIG_JFFS2_FS_SECURITY */ #endif /* _JFFS2_FS_XATTR_H_ */ diff --git a/fs/jfs/jfs_xattr.h b/fs/jfs/jfs_xattr.h index 88b6cc5..e9e100f 100644 --- a/fs/jfs/jfs_xattr.h +++ b/fs/jfs/jfs_xattr.h @@ -62,10 +62,11 @@ extern ssize_t jfs_listxattr(struct dentry *, char *, size_t); extern int jfs_removexattr(struct dentry *, const char *); #ifdef CONFIG_JFS_SECURITY -extern int jfs_init_security(tid_t, struct inode *, struct inode *); +extern int jfs_init_security(tid_t, struct inode *, struct inode *, + const struct qstr *); #else static inline int jfs_init_security(tid_t tid, struct inode *inode, - struct inode *dir) + struct inode *dir, const struct qstr *qstr) { return 0; } diff --git a/fs/jfs/namei.c b/fs/jfs/namei.c index 231ca4a..ff0fda9 100644 --- a/fs/jfs/namei.c +++ b/fs/jfs/namei.c @@ -114,7 +114,7 @@ static int jfs_create(struct inode *dip, struct dentry *dentry, int mode, if (rc) goto out3; - rc = jfs_init_security(tid, ip, dip); + rc = jfs_init_security(tid, ip, dip, &dentry->d_name); if (rc) { txAbort(tid, 0); goto out3; @@ -252,7 +252,7 @@ static int jfs_mkdir(struct inode *dip, struct dentry *dentry, int mode) if (rc) goto out3; - rc = jfs_init_security(tid, ip, dip); + rc = jfs_init_security(tid, ip, dip, &dentry->d_name); if (rc) { txAbort(tid, 0); goto out3; @@ -931,7 +931,7 @@ static int jfs_symlink(struct inode *dip, struct dentry *dentry, mutex_lock_nested(&JFS_IP(dip)->commit_mutex, COMMIT_MUTEX_PARENT); mutex_lock_nested(&JFS_IP(ip)->commit_mutex, COMMIT_MUTEX_CHILD); - rc = jfs_init_security(tid, ip, dip); + rc = jfs_init_security(tid, ip, dip, &dentry->d_name); if (rc) goto out3; @@ -1394,7 +1394,7 @@ static int jfs_mknod(struct inode *dir, struct dentry *dentry, if (rc) goto out3; - rc = jfs_init_security(tid, ip, dir); + rc = jfs_init_security(tid, ip, dir, &dentry->d_name); if (rc) { txAbort(tid, 0); goto out3; diff --git a/fs/jfs/xattr.c b/fs/jfs/xattr.c index 2d7f165..3fa4c32 100644 --- a/fs/jfs/xattr.c +++ b/fs/jfs/xattr.c @@ -1091,7 +1091,8 @@ int jfs_removexattr(struct dentry *dentry, const char *name) } #ifdef CONFIG_JFS_SECURITY -int jfs_init_security(tid_t tid, struct inode *inode, struct inode *dir) +int jfs_init_security(tid_t tid, struct inode *inode, struct inode *dir, + const struct qstr *qstr) { int rc; size_t len; @@ -1099,7 +1100,8 @@ int jfs_init_security(tid_t tid, struct inode *inode, struct inode *dir) char *suffix; char *name; - rc = security_inode_init_security(inode, dir, &suffix, &value, &len); + rc = security_inode_init_security(inode, dir, qstr, &suffix, &value, + &len); if (rc) { if (rc == -EOPNOTSUPP) return 0; diff --git a/fs/ocfs2/namei.c b/fs/ocfs2/namei.c index ff5744e..7740bc0 100644 --- a/fs/ocfs2/namei.c +++ b/fs/ocfs2/namei.c @@ -294,7 +294,7 @@ static int ocfs2_mknod(struct inode *dir, } /* get security xattr */ - status = ocfs2_init_security_get(inode, dir, &si); + status = ocfs2_init_security_get(inode, dir, &dentry->d_name, &si); if (status) { if (status == -EOPNOTSUPP) si.enable = 0; @@ -1665,7 +1665,7 @@ static int ocfs2_symlink(struct inode *dir, } /* get security xattr */ - status = ocfs2_init_security_get(inode, dir, &si); + status = ocfs2_init_security_get(inode, dir, &dentry->d_name, &si); if (status) { if (status == -EOPNOTSUPP) si.enable = 0; diff --git a/fs/ocfs2/refcounttree.c b/fs/ocfs2/refcounttree.c index b5f9160..cd3f5b4 100644 --- a/fs/ocfs2/refcounttree.c +++ b/fs/ocfs2/refcounttree.c @@ -4325,7 +4325,8 @@ static int ocfs2_reflink(struct dentry *old_dentry, struct inode *dir, /* If the security isn't preserved, we need to re-initialize them. */ if (!preserve) { - error = ocfs2_init_security_and_acl(dir, new_orphan_inode); + error = ocfs2_init_security_and_acl(dir, new_orphan_inode, + &new_dentry->d_name); if (error) mlog_errno(error); } diff --git a/fs/ocfs2/xattr.c b/fs/ocfs2/xattr.c index 67cd439..6bb6024 100644 --- a/fs/ocfs2/xattr.c +++ b/fs/ocfs2/xattr.c @@ -7185,7 +7185,8 @@ out: * must not hold any lock expect i_mutex. */ int ocfs2_init_security_and_acl(struct inode *dir, - struct inode *inode) + struct inode *inode, + const struct qstr *qstr) { int ret = 0; struct buffer_head *dir_bh = NULL; @@ -7193,7 +7194,7 @@ int ocfs2_init_security_and_acl(struct inode *dir, .enable = 1, }; - ret = ocfs2_init_security_get(inode, dir, &si); + ret = ocfs2_init_security_get(inode, dir, qstr, &si); if (!ret) { ret = ocfs2_xattr_set(inode, OCFS2_XATTR_INDEX_SECURITY, si.name, si.value, si.value_len, @@ -7261,13 +7262,14 @@ static int ocfs2_xattr_security_set(struct dentry *dentry, const char *name, int ocfs2_init_security_get(struct inode *inode, struct inode *dir, + const struct qstr *qstr, struct ocfs2_security_xattr_info *si) { /* check whether ocfs2 support feature xattr */ if (!ocfs2_supports_xattr(OCFS2_SB(dir->i_sb))) return -EOPNOTSUPP; - return security_inode_init_security(inode, dir, &si->name, &si->value, - &si->value_len); + return security_inode_init_security(inode, dir, qstr, &si->name, + &si->value, &si->value_len); } int ocfs2_init_security_set(handle_t *handle, diff --git a/fs/ocfs2/xattr.h b/fs/ocfs2/xattr.h index aa64bb3..d63cfb7 100644 --- a/fs/ocfs2/xattr.h +++ b/fs/ocfs2/xattr.h @@ -57,6 +57,7 @@ int ocfs2_has_inline_xattr_value_outside(struct inode *inode, struct ocfs2_dinode *di); int ocfs2_xattr_remove(struct inode *, struct buffer_head *); int ocfs2_init_security_get(struct inode *, struct inode *, + const struct qstr *, struct ocfs2_security_xattr_info *); int ocfs2_init_security_set(handle_t *, struct inode *, struct buffer_head *, @@ -94,5 +95,6 @@ int ocfs2_reflink_xattrs(struct inode *old_inode, struct buffer_head *new_bh, bool preserve_security); int ocfs2_init_security_and_acl(struct inode *dir, - struct inode *inode); + struct inode *inode, + const struct qstr *qstr); #endif /* OCFS2_XATTR_H */ diff --git a/fs/reiserfs/namei.c b/fs/reiserfs/namei.c index ba5f51e..d5b22ed 100644 --- a/fs/reiserfs/namei.c +++ b/fs/reiserfs/namei.c @@ -593,7 +593,7 @@ static int reiserfs_create(struct inode *dir, struct dentry *dentry, int mode, new_inode_init(inode, dir, mode); jbegin_count += reiserfs_cache_default_acl(dir); - retval = reiserfs_security_init(dir, inode, &security); + retval = reiserfs_security_init(dir, inode, &dentry->d_name, &security); if (retval < 0) { drop_new_inode(inode); return retval; @@ -667,7 +667,7 @@ static int reiserfs_mknod(struct inode *dir, struct dentry *dentry, int mode, new_inode_init(inode, dir, mode); jbegin_count += reiserfs_cache_default_acl(dir); - retval = reiserfs_security_init(dir, inode, &security); + retval = reiserfs_security_init(dir, inode, &dentry->d_name, &security); if (retval < 0) { drop_new_inode(inode); return retval; @@ -747,7 +747,7 @@ static int reiserfs_mkdir(struct inode *dir, struct dentry *dentry, int mode) new_inode_init(inode, dir, mode); jbegin_count += reiserfs_cache_default_acl(dir); - retval = reiserfs_security_init(dir, inode, &security); + retval = reiserfs_security_init(dir, inode, &dentry->d_name, &security); if (retval < 0) { drop_new_inode(inode); return retval; @@ -1032,7 +1032,8 @@ static int reiserfs_symlink(struct inode *parent_dir, } new_inode_init(inode, parent_dir, mode); - retval = reiserfs_security_init(parent_dir, inode, &security); + retval = reiserfs_security_init(parent_dir, inode, &dentry->d_name, + &security); if (retval < 0) { drop_new_inode(inode); return retval; diff --git a/fs/reiserfs/xattr_security.c b/fs/reiserfs/xattr_security.c index 237c692..ef66c18 100644 --- a/fs/reiserfs/xattr_security.c +++ b/fs/reiserfs/xattr_security.c @@ -54,6 +54,7 @@ static size_t security_list(struct dentry *dentry, char *list, size_t list_len, * of blocks needed for the transaction. If successful, reiserfs_security * must be released using reiserfs_security_free when the caller is done. */ int reiserfs_security_init(struct inode *dir, struct inode *inode, + const struct qstr *qstr, struct reiserfs_security_handle *sec) { int blocks = 0; @@ -65,7 +66,7 @@ int reiserfs_security_init(struct inode *dir, struct inode *inode, if (IS_PRIVATE(dir)) return 0; - error = security_inode_init_security(inode, dir, &sec->name, + error = security_inode_init_security(inode, dir, qstr, &sec->name, &sec->value, &sec->length); if (error) { if (error == -EOPNOTSUPP) diff --git a/fs/xfs/linux-2.6/xfs_iops.c b/fs/xfs/linux-2.6/xfs_iops.c index 94d5fd6..d9298cf 100644 --- a/fs/xfs/linux-2.6/xfs_iops.c +++ b/fs/xfs/linux-2.6/xfs_iops.c @@ -103,7 +103,8 @@ xfs_mark_inode_dirty( STATIC int xfs_init_security( struct inode *inode, - struct inode *dir) + struct inode *dir, + const struct qstr *qstr) { struct xfs_inode *ip = XFS_I(inode); size_t length; @@ -111,7 +112,7 @@ xfs_init_security( unsigned char *name; int error; - error = security_inode_init_security(inode, dir, (char **)&name, + error = security_inode_init_security(inode, dir, qstr, (char **)&name, &value, &length); if (error) { if (error == -EOPNOTSUPP) @@ -195,7 +196,7 @@ xfs_vn_mknod( inode = VFS_I(ip); - error = xfs_init_security(inode, dir); + error = xfs_init_security(inode, dir, &dentry->d_name); if (unlikely(error)) goto out_cleanup_inode; @@ -368,7 +369,7 @@ xfs_vn_symlink( inode = VFS_I(cip); - error = xfs_init_security(inode, dir); + error = xfs_init_security(inode, dir, &dentry->d_name); if (unlikely(error)) goto out_cleanup_inode; diff --git a/include/linux/ext3_fs.h b/include/linux/ext3_fs.h index 6ce1bca..87312a8 100644 --- a/include/linux/ext3_fs.h +++ b/include/linux/ext3_fs.h @@ -874,7 +874,8 @@ extern int ext3fs_dirhash(const char *name, int len, struct dx_hash_info *hinfo); /* ialloc.c */ -extern struct inode * ext3_new_inode (handle_t *, struct inode *, int); +extern struct inode * ext3_new_inode (handle_t *, struct inode *, + const struct qstr *, int); extern void ext3_free_inode (handle_t *, struct inode *); extern struct inode * ext3_orphan_get (struct super_block *, unsigned long); extern unsigned long ext3_count_free_inodes (struct super_block *); diff --git a/include/linux/reiserfs_xattr.h b/include/linux/reiserfs_xattr.h index b2cf208..c2b7147 100644 --- a/include/linux/reiserfs_xattr.h +++ b/include/linux/reiserfs_xattr.h @@ -63,6 +63,7 @@ extern const struct xattr_handler reiserfs_xattr_trusted_handler; extern const struct xattr_handler reiserfs_xattr_security_handler; #ifdef CONFIG_REISERFS_FS_SECURITY int reiserfs_security_init(struct inode *dir, struct inode *inode, + const struct qstr *qstr, struct reiserfs_security_handle *sec); int reiserfs_security_write(struct reiserfs_transaction_handle *th, struct inode *inode, @@ -130,6 +131,7 @@ static inline void reiserfs_init_xattr_rwsem(struct inode *inode) #ifndef CONFIG_REISERFS_FS_SECURITY static inline int reiserfs_security_init(struct inode *dir, struct inode *inode, + const struct qstr *qstr, struct reiserfs_security_handle *sec) { return 0; diff --git a/include/linux/security.h b/include/linux/security.h index 4ab684e..02fcc0e 100644 --- a/include/linux/security.h +++ b/include/linux/security.h @@ -25,6 +25,7 @@ #include #include #include +#include #include #include #include @@ -315,6 +316,7 @@ static inline void security_free_mnt_opts(struct security_mnt_opts *opts) * then it should return -EOPNOTSUPP to skip this processing. * @inode contains the inode structure of the newly created inode. * @dir contains the inode structure of the parent directory. + * @qstr contains the last path component of the new object * @name will be set to the allocated name suffix (e.g. selinux). * @value will be set to the allocated attribute value. * @len will be set to the length of the value. @@ -1437,7 +1439,8 @@ struct security_operations { int (*inode_alloc_security) (struct inode *inode); void (*inode_free_security) (struct inode *inode); int (*inode_init_security) (struct inode *inode, struct inode *dir, - char **name, void **value, size_t *len); + const struct qstr *qstr, char **name, + void **value, size_t *len); int (*inode_create) (struct inode *dir, struct dentry *dentry, int mode); int (*inode_link) (struct dentry *old_dentry, @@ -1701,7 +1704,8 @@ int security_sb_parse_opts_str(char *options, struct security_mnt_opts *opts); int security_inode_alloc(struct inode *inode); void security_inode_free(struct inode *inode); int security_inode_init_security(struct inode *inode, struct inode *dir, - char **name, void **value, size_t *len); + const struct qstr *qstr, char **name, + void **value, size_t *len); int security_inode_create(struct inode *dir, struct dentry *dentry, int mode); int security_inode_link(struct dentry *old_dentry, struct inode *dir, struct dentry *new_dentry); @@ -2028,6 +2032,7 @@ static inline void security_inode_free(struct inode *inode) static inline int security_inode_init_security(struct inode *inode, struct inode *dir, + const struct qstr *qstr, char **name, void **value, size_t *len) diff --git a/mm/shmem.c b/mm/shmem.c index 47fdeeb..86cd21d 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -1843,8 +1843,9 @@ shmem_mknod(struct inode *dir, struct dentry *dentry, int mode, dev_t dev) inode = shmem_get_inode(dir->i_sb, dir, mode, dev, VM_NORESERVE); if (inode) { - error = security_inode_init_security(inode, dir, NULL, NULL, - NULL); + error = security_inode_init_security(inode, dir, + &dentry->d_name, NULL, + NULL, NULL); if (error) { if (error != -EOPNOTSUPP) { iput(inode); @@ -1983,8 +1984,8 @@ static int shmem_symlink(struct inode *dir, struct dentry *dentry, const char *s if (!inode) return -ENOSPC; - error = security_inode_init_security(inode, dir, NULL, NULL, - NULL); + error = security_inode_init_security(inode, dir, &dentry->d_name, NULL, + NULL, NULL); if (error) { if (error != -EOPNOTSUPP) { iput(inode); diff --git a/security/capability.c b/security/capability.c index 92a1bff..c3d796c 100644 --- a/security/capability.c +++ b/security/capability.c @@ -118,7 +118,8 @@ static void cap_inode_free_security(struct inode *inode) } static int cap_inode_init_security(struct inode *inode, struct inode *dir, - char **name, void **value, size_t *len) + const struct qstr *qstr, char **name, + void **value, size_t *len) { return -EOPNOTSUPP; } diff --git a/security/security.c b/security/security.c index 799239d..7ebeb86 100644 --- a/security/security.c +++ b/security/security.c @@ -336,11 +336,13 @@ void security_inode_free(struct inode *inode) } int security_inode_init_security(struct inode *inode, struct inode *dir, - char **name, void **value, size_t *len) + const struct qstr *qstr, char **name, + void **value, size_t *len) { if (unlikely(IS_PRIVATE(inode))) return -EOPNOTSUPP; - return security_ops->inode_init_security(inode, dir, name, value, len); + return security_ops->inode_init_security(inode, dir, qstr, name, value, + len); } EXPORT_SYMBOL(security_inode_init_security); diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c index b8dcd05..7699e23 100644 --- a/security/selinux/hooks.c +++ b/security/selinux/hooks.c @@ -39,6 +39,7 @@ #include #include #include +#include #include #include #include @@ -2509,8 +2510,8 @@ static void selinux_inode_free_security(struct inode *inode) } static int selinux_inode_init_security(struct inode *inode, struct inode *dir, - char **name, void **value, - size_t *len) + const struct qstr *qstr, char **name, + void **value, size_t *len) { const struct task_security_struct *tsec = current_security(); struct inode_security_struct *dsec; diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c index 489a85a..581b65e 100644 --- a/security/smack/smack_lsm.c +++ b/security/smack/smack_lsm.c @@ -31,6 +31,7 @@ #include #include #include +#include #include "smack.h" #define task_security(task) (task_cred_xxx((task), security)) @@ -424,6 +425,7 @@ static void smack_inode_free_security(struct inode *inode) * smack_inode_init_security - copy out the smack from an inode * @inode: the inode * @dir: unused + * @qstr: unused * @name: where to put the attribute name * @value: where to put the attribute value * @len: where to put the length of the attribute @@ -431,7 +433,8 @@ static void smack_inode_free_security(struct inode *inode) * Returns 0 if it all works out, -ENOMEM if there's no memory */ static int smack_inode_init_security(struct inode *inode, struct inode *dir, - char **name, void **value, size_t *len) + const struct qstr *qstr, char **name, + void **value, size_t *len) { char *isp = smk_of_inode(inode); From stan@hardwarefreak.com Wed Dec 8 16:12:19 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,J_CHICKENPOX_36, J_CHICKENPOX_43 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB8MCJ3W149194 for ; Wed, 8 Dec 2010 16:12:19 -0600 X-ASG-Debug-ID: 1291846446-7a2a037b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from greer.hardwarefreak.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D066C1CA7F4F for ; Wed, 8 Dec 2010 14:14:07 -0800 (PST) Received: from greer.hardwarefreak.com (mo-65-41-216-221.sta.embarqhsd.net [65.41.216.221]) by cuda.sgi.com with ESMTP id 99wgGwIGgL6qbMh5 for ; Wed, 08 Dec 2010 14:14:07 -0800 (PST) Received: from [192.168.100.53] (gffx.hardwarefreak.com [192.168.100.53]) by greer.hardwarefreak.com (Postfix) with ESMTP id D2A6C6C174 for ; Wed, 8 Dec 2010 16:14:05 -0600 (CST) Message-ID: <4D00032D.4040000@hardwarefreak.com> Date: Wed, 08 Dec 2010 16:14:05 -0600 From: Stan Hoeppner User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs tuning for a 830 GB partition (mkfs.xfs options) Subject: Re: xfs tuning for a 830 GB partition (mkfs.xfs options) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mo-65-41-216-221.sta.embarqhsd.net[65.41.216.221] X-Barracuda-Start-Time: 1291846447 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.01 X-Barracuda-Spam-Status: No, SCORE=-1.01 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC5_MJ1963, RDNS_DYNAMIC, SUBJECT_FUZZY_TION X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48864 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.41 SUBJECT_FUZZY_TION Attempt to obfuscate words in Subject: 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS 0.50 BSF_SC5_MJ1963 Custom Rule MJ1963 X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Abel Coto put forth on 12/8/2010 1:32 PM: > I want to create a 830 GB partition, to mount as /home in my Centos 5.4 > workstation. > > Actually i have /home not mounted ,so i would have to create the new > partition in the lvm,format it and use rsync to copy /home directory to it. > > for a 830 GB partition that i will use to save my data in general and also > 3d / CG projects and renders once finished them what agcount value should be > used. I have read that mkfs default option creates 1 allocation group each > 4G , so i understand that for a 830 GB partition agcount should be 208. > > It is this correct ? No that's not correct. > so i would use for format the partition > > mkfs.xfs -l lazy-count=1,version=2,size=128m -i attr=2 -d agcount=208 -L > VolumeName Do not do this! If this filesystem will reside on a single physical disk, format the partition using the XFS defaults. agcount, and most of the other options, exists for optimizing parallel performance on striped RAID or SSD storage systems that have lots of IOPS performance. These options are _not_ for use on single disk drives. AG count is related to number of spindles and/or IOPs throughput, not the size of the partition. The mkfs.xfs default for a single drive filesystem is 4 AGs. If you specify a value greater than 4 your performance will suffer. If you specify 208 AGs it may likely be little faster than a floppy disk drive. -- Stan From stan@hardwarefreak.com Wed Dec 8 18:26:03 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_43 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB90Q3oR154028 for ; Wed, 8 Dec 2010 18:26:03 -0600 X-ASG-Debug-ID: 1291854470-577203e20000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from greer.hardwarefreak.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A5A421CA8667 for ; Wed, 8 Dec 2010 16:27:51 -0800 (PST) Received: from greer.hardwarefreak.com (mo-65-41-216-221.sta.embarqhsd.net [65.41.216.221]) by cuda.sgi.com with ESMTP id hDXytBuwkkwogvAh for ; Wed, 08 Dec 2010 16:27:51 -0800 (PST) Received: from [192.168.100.53] (gffx.hardwarefreak.com [192.168.100.53]) by greer.hardwarefreak.com (Postfix) with ESMTP id C2B386C173 for ; Wed, 8 Dec 2010 18:27:50 -0600 (CST) Message-ID: <4D002286.2080204@hardwarefreak.com> Date: Wed, 08 Dec 2010 18:27:50 -0600 From: Stan Hoeppner User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs tuning for a 830 GB partition (mkfs.xfs options) Subject: Re: xfs tuning for a 830 GB partition (mkfs.xfs options) References: <4D00032D.4040000@hardwarefreak.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mo-65-41-216-221.sta.embarqhsd.net[65.41.216.221] X-Barracuda-Start-Time: 1291854471 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.01 X-Barracuda-Spam-Status: No, SCORE=-1.01 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC5_MJ1963, BSF_SC5_SA210e, RDNS_DYNAMIC, SUBJECT_FUZZY_TION X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48874 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.41 SUBJECT_FUZZY_TION Attempt to obfuscate words in Subject: 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS 0.50 BSF_SC5_MJ1963 Custom Rule MJ1963 0.00 BSF_SC5_SA210e Custom Rule SA210e X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Abel Coto put forth on 12/8/2010 5:29 PM: > By the moment i will use one hard disk for / (on ext3) and /home , and > the data partition for saving 3d projects working on in another hard > disk (1,5 tb one , with the 350 GB partition and one of 1 TB for > backups of /home mostly) > > so agcount should be in both cases 4, as i haven't got a raid (the 1,5 > tb disk won't be in the LVM neither). > > I have read that in xfsprogs 3.1.2, i think, -l lazy-count=1,version=2 > and -i attr=2 is the default option like agcount=4. So i should only > specify the -l size=128m if i want a log size of 128m for improve > deleting performance and improving system in general. With a single disk filesystem, you can tweak these things forever, and you will gain almost no performance benefit over the mkfs.xfs defaults, though you may decrease performance if you don't know exactly what you're doing, such as with your previous misunderstanding of agcount. The one thing you can tweak beyond defaults to get improved performance is using delayed logging, which will increase metadata write performance substantially. For example, deletes of large groups (thousands) of small files will be "massively" faster using delayed logging. IIRC this requires kernel 2.6.36 or later. Simply add "delaylog" to you /etc/fstab mount options. > I think in /home the most important thing is read/write seqential > performance , and in /data (the 350 GB partition) the same. > > I don't think /data would have to handle too many ramdon reads/ writes > when Maya saves and read data from it, i think would be mostly > seqential and then allocated in memory. Again, with a single disk, there's not much you can tweak to increase general XFS performance, except for metadata writes using delaylog. For sequential file reads/writes and random reads/writes, you're at the mercy of the drive's spindle speed. XFS options can't improve upon the poor physics of a single spinning drive. If you need improved file performance (not metadata), your options are to add spindles and stripe the data (RAID card or mdadm, RAID 0/5/6/10), or use a good quality SSD. -- Stan From SRS0+UJ1G+12+fromorbit.com=david@internode.on.net Wed Dec 8 18:58:02 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB90w1pp155373 for ; Wed, 8 Dec 2010 18:58:02 -0600 X-ASG-Debug-ID: 1291856388-20f601c50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D6C891CA7B6A for ; Wed, 8 Dec 2010 16:59:48 -0800 (PST) Received: from mail.internode.on.net (bld-mail14.adl6.internode.on.net [150.101.137.99]) by cuda.sgi.com with ESMTP id ArF1txQl4CXmFiEk for ; Wed, 08 Dec 2010 16:59:48 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 49678282-1927428 for multiple; Thu, 09 Dec 2010 11:29:46 +1030 (CDT) Received: from dave by dastard with local (Exim 4.71) (envelope-from ) id 1PQUrJ-0001ny-0I; Thu, 09 Dec 2010 11:59:45 +1100 Date: Thu, 9 Dec 2010 11:59:44 +1100 From: Dave Chinner To: blacknred Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: kernel panic-xfs errors Subject: Re: kernel panic-xfs errors Message-ID: <20101209005944.GD32766@dastard> References: <30397503.post@talk.nabble.com> <20101207222558.GC29333@dastard> <30403823.post@talk.nabble.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <30403823.post@talk.nabble.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: bld-mail14.adl6.internode.on.net[150.101.137.99] X-Barracuda-Start-Time: 1291856390 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48876 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Wed, Dec 08, 2010 at 01:39:10AM -0800, blacknred wrote: > > > >You've done a forced module load. No guarantee your kernel is in any > >sane shape if you've done that.... > > Agree, but I'm reasonably convinced that module isn't the issue, because it > works fine with my other servers...... > > >Strange failure. Hmmm - i386 arch and fedora - are you running with > 4k stacks? If so, maybe it blew the stack... > > i386 arch, rhel 5.0 Yup, 4k stacks. This is definitely smelling like a stack blowout. XFS on 4k stacks is a ticking timebomb - it will explode and you've got no idea of when it will go boom. Recompile your kernel with 8k stacks or move to x86_64. > ># dd if= bs=512 count=1 | od -c > This is what i get now, but now server's been rebooted and running OK, what > should i be expecting or rather what are we looking for in this output at > point of failure? Well, what you see here: > 0000000 X F S B \0 \0 020 \0 \0 \0 \0 \0 025 324 304 \0 ^^^^^^^^^^^^^ Is a valid XFS superblock magic number. If you are getting this error: > >> XFS: bad magic number > >> XFS: SB validate failed Then I'd expect to see anything other than "XFSB" as the magic number. Of course, if you smashed the stack during mount, then there will most likely be nothing wrong with the value on disk... > >why did I flash the controller > I was on 5.22 fw version which has a known 'lockup' issue which is fixed in > 7.x ver. > This is a critical fix. Is the version 7.x firmware certified with such an old kernel? It's not uncommon for different firmware versions to only be supported on specific releases/kernel versions. Cheers, Dave. -- Dave Chinner david@fromorbit.com From SRS0+UJ1G+12+fromorbit.com=david@internode.on.net Wed Dec 8 19:03:47 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,J_CHICKENPOX_36, J_CHICKENPOX_43 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB913lnA155554 for ; Wed, 8 Dec 2010 19:03:47 -0600 X-ASG-Debug-ID: 1291856733-68fa01330000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 289501D6025 for ; Wed, 8 Dec 2010 17:05:34 -0800 (PST) Received: from mail.internode.on.net (bld-mail15.adl6.internode.on.net [150.101.137.100]) by cuda.sgi.com with ESMTP id prTuhfhyJjQTKHG2 for ; Wed, 08 Dec 2010 17:05:34 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 37805253-1927428 for multiple; Thu, 09 Dec 2010 11:35:33 +1030 (CDT) Received: from dave by dastard with local (Exim 4.71) (envelope-from ) id 1PQUwt-0001oa-Ak; Thu, 09 Dec 2010 12:05:31 +1100 Date: Thu, 9 Dec 2010 12:05:31 +1100 From: Dave Chinner To: Abel Coto Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs tuning for a 830 GB partition (mkfs.xfs options) Subject: Re: xfs tuning for a 830 GB partition (mkfs.xfs options) Message-ID: <20101209010531.GE32766@dastard> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: bld-mail15.adl6.internode.on.net[150.101.137.100] X-Barracuda-Start-Time: 1291856736 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.61 X-Barracuda-Spam-Status: No, SCORE=-1.61 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=SUBJECT_FUZZY_TION X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48876 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.41 SUBJECT_FUZZY_TION Attempt to obfuscate words in Subject: X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Wed, Dec 08, 2010 at 08:32:28PM +0100, Abel Coto wrote: > I want to create a 830 GB partition, to mount as /home in my Centos 5.4 > workstation. > > Actually i have /home not mounted ,so i would have to create the new > partition in the lvm,format it and use rsync to copy /home directory to it. > > for a 830 GB partition that i will use to save my data in general and also > 3d / CG projects and renders once finished them what agcount value should be > used. I have read that mkfs default option creates 1 allocation group each > 4G , so i understand that for a 830 GB partition agcount should be 208. > > It is this correct ? No, you've read something that is at least 5 years out of date. Just use the defaults - they are already optimised for best performance in most circumstances. > I have read that too much allocation groups are bad , but i don't now if 416 > are too much for a 830 GB partition (and shoukd use 208 to 300) or not. Any more than 4 AGs on a single spindle is bad for performance. AGs can be up to 1TB in size, so you're going to get 4 as the default for your 830GB partition. > I will mount the partition with logbufs=8. (i use a 128m journal and > logbufs=8 to improve a bit deleting performance). I will perhaps use noatime > too ,but i have to see if my backup app, uses atime or not. logbufs=8 is the default. Also, the default atime option is relatime which has pretty much zero compareeed to noatime, so once again just use the defaults. > for this partition , that will handle mostly big files (500 MB to 2-3 GB at > least) what mkfs.xfs options should i use ? The defaults. Cheers, Dave. -- Dave Chinner david@fromorbit.com From SRS0+rFbk+12+fromorbit.com=david@internode.on.net Wed Dec 8 19:37:37 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_36 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB91ba4l156647 for ; Wed, 8 Dec 2010 19:37:37 -0600 X-ASG-Debug-ID: 1291858479-68dc01da0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DAD231D6DF3 for ; Wed, 8 Dec 2010 17:34:39 -0800 (PST) Received: from mail.internode.on.net (bld-mail13.adl6.internode.on.net [150.101.137.98]) by cuda.sgi.com with ESMTP id 7T2GCNU8rJJDw4ar for ; Wed, 08 Dec 2010 17:34:39 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 49456341-1927428 for multiple; Thu, 09 Dec 2010 12:04:36 +1030 (CDT) Received: from dave by dastard with local (Exim 4.71) (envelope-from ) id 1PQVOg-0001r4-2H; Thu, 09 Dec 2010 12:34:14 +1100 Date: Thu, 9 Dec 2010 12:34:14 +1100 From: Dave Chinner To: Abel Coto Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfs tuning for a 830 GB partition (mkfs.xfs options) Subject: Re: xfs tuning for a 830 GB partition (mkfs.xfs options) Message-ID: <20101209013413.GA7105@dastard> References: <20101209010531.GE32766@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101209010531.GE32766@dastard> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: bld-mail13.adl6.internode.on.net[150.101.137.98] X-Barracuda-Start-Time: 1291858480 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0209 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.51 X-Barracuda-Spam-Status: No, SCORE=-1.51 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC0_SA085, SUBJECT_FUZZY_TION X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48878 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.41 SUBJECT_FUZZY_TION Attempt to obfuscate words in Subject: 0.10 BSF_SC0_SA085 Custom Rule SA085 X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, Dec 09, 2010 at 12:05:31PM +1100, Dave Chinner wrote: > On Wed, Dec 08, 2010 at 08:32:28PM +0100, Abel Coto wrote: > > I want to create a 830 GB partition, to mount as /home in my Centos 5.4 > > workstation. > > > > Actually i have /home not mounted ,so i would have to create the new > > partition in the lvm,format it and use rsync to copy /home directory to it. > > > > for a 830 GB partition that i will use to save my data in general and also > > 3d / CG projects and renders once finished them what agcount value should be > > used. I have read that mkfs default option creates 1 allocation group each > > 4G , so i understand that for a 830 GB partition agcount should be 208. > > > > It is this correct ? > > No, you've read something that is at least 5 years out of date. Just > use the defaults - they are already optimised for best performance > in most circumstances. Seeing as I say this so often: http://xfs.org/index.php/XFS_FAQ#Q:_I_want_to_tune_my_XFS_filesystems_for_.3Csomething.3E Cheers, Dave. -- Dave Chinner david@fromorbit.com From sandeen@sandeen.net Wed Dec 8 21:42:28 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB93gSHg166437 for ; Wed, 8 Dec 2010 21:42:28 -0600 X-ASG-Debug-ID: 1291866256-466902630000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2F9B51CA8ED2 for ; Wed, 8 Dec 2010 19:44:16 -0800 (PST) Received: from mail.sandeen.net (64-131-28-21.usfamily.net [64.131.28.21]) by cuda.sgi.com with ESMTP id JEutCkHHfi6U8Bhv for ; Wed, 08 Dec 2010 19:44:16 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sandeen.net (Postfix) with ESMTP id 2CEC44817CFA; Wed, 8 Dec 2010 21:44:15 -0600 (CST) Message-ID: <4D00508E.5040408@sandeen.net> Date: Wed, 08 Dec 2010 21:44:14 -0600 From: Eric Sandeen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Dave Chinner CC: blacknred , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: possible xfs corruption Subject: Re: possible xfs corruption References: <30395558.post@talk.nabble.com> <20101207221009.GA29333@dastard> In-Reply-To: <20101207221009.GA29333@dastard> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: 64-131-28-21.usfamily.net[64.131.28.21] X-Barracuda-Start-Time: 1291866257 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.42 X-Barracuda-Spam-Status: No, SCORE=-1.42 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M, RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48886 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS 0.50 BSF_RULE7568M Custom Rule 7568M X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 12/7/10 4:10 PM, Dave Chinner wrote: > On Tue, Dec 07, 2010 at 03:49:49AM -0800, blacknred wrote: >> >> Hi... >> >> I'm stuck with a storage issue on reboot. Initially doubted the storage, but >> dmesg throws these errors. Now wondering whether this is a fs issue? Any >> thoughts as to whats going on here? >> >> >> XFS: failed to locate log tail >> XFS: log mount/recovery failed: error 117 >> XFS: log mount failed >> XFS mounting filesystem cciss/c0d0 >> Filesystem "cciss/c0d0": XFS internal error xlog_clear_stale_blocks(2) at >> line 1237 of file > > Which indicates that the head and/or the tail of the log are not > valid. Can you provide the output of: > > # xfs_logprint -d /dev/cciss/c0d0 > > So we can see what the head/tail values are in the log? > >> /home/buildsvn/rpmbuild/BUILD/xfs-kmod-0.4/_kmod_build_PAE/xfs_log_recover.c. > > CentOS kernel? How old? Assuning it's centos5, there's really no need to be using an xfs kmod there anymore, the module shipped with the kernel in recent versions of the OS is really the one you want to use. That kmod is ancient and unmaintained. Although I suspect the storage is more likely at fault here. :) -Eric > Cheers, > > Dave. From sandeen@sandeen.net Wed Dec 8 21:49:36 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB93nZoe167350 for ; Wed, 8 Dec 2010 21:49:36 -0600 X-ASG-Debug-ID: 1291866683-07ae03420000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 63773152A76D for ; Wed, 8 Dec 2010 19:51:23 -0800 (PST) Received: from mail.sandeen.net (64-131-28-21.usfamily.net [64.131.28.21]) by cuda.sgi.com with ESMTP id 0aMhTIiIxjXTwnNX for ; Wed, 08 Dec 2010 19:51:23 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sandeen.net (Postfix) with ESMTP id EEE234817CFA; Wed, 8 Dec 2010 21:51:22 -0600 (CST) Message-ID: <4D00523A.9020703@sandeen.net> Date: Wed, 08 Dec 2010 21:51:22 -0600 From: Eric Sandeen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Ajeet Yadav CC: Dave Chinner , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS mount fail: XFS_WANT_CORRUPTED_GOTO fs/xfs/xfs_alloc.c Subject: Re: XFS mount fail: XFS_WANT_CORRUPTED_GOTO fs/xfs/xfs_alloc.c References: <20101202224506.GY16922@dastard> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: 64-131-28-21.usfamily.net[64.131.28.21] X-Barracuda-Start-Time: 1291866684 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48887 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 12/3/10 10:19 PM, Ajeet Yadav wrote: > Our test case is automated: > 1. Create large number of file of 6KB sizes ( 6KB is taken, we wanted to increase journal load, and file size not in multiple of file system block size) > 2. Set target to reboot at random seconds seconds. What exactly is meant by "reboot?" Does this mean "cycle power" or cleanly reboot? Based on the problems you are encountering, I am guessing that you drop power. Is the storage external for this test? Is it qualified hardware or are you planning on supporting anything that the user may choose to plug into their device? It's possible that an external USB device is behaving poorly, and that may be the root of your problems. -Eric > 3. Next boot do "ls" of all files in XFS partition. > 4. Remove all files in XFS. > 5. Go back to step 1 > > The purpose of this test is to test journal and stability of XFS filestem. > > Do you think, we should consider this test case ? > > Other is when we should run xfs_repair ? because if mount fails and journal contain dirty logs then xfs_repair does not run, we are forced to use (-L) option but its description say that (-L) can corrupt the file system. > > Other case even if xfs mount successfully, even in that case accessing some files give IO input/ output error. > > 1. I recommend the following usage for xfs_repair so that we do not come accross these problem > Mount Success -> Umount -> run xfs_repair -> mount > Mount fails -> try xfs_repair -> xfs_repair fails -> finally xfs_repair -L -> mount > > Adding above mount + xfs_repair procedure to script makes file system stable. But other member of my team do not agree as it increases mount time. > > > > On Fri, Dec 3, 2010 at 4:15 AM, Dave Chinner > wrote: > > On Thu, Dec 02, 2010 at 12:31:30PM +0530, Ajeet Yadav wrote: > > Dear all, > > This is XFS fail mount log on linux 2.6.30.9 > > > > XFS mounting filesystem sda2 > > Starting XFS recovery on filesystem: sda2 (logdev: internal) > > XFS internal error XFS_WANT_CORRUPTED_GOTO at line 1629 of file > > fs/xfs/xfs_alloc.c. Caller 0x80129658 > > Call Trace: > > [<802dedc8>] dump_stack+0x8/0x34 from[<80127400>] > > xfs_free_ag_extent+0x128/0x7ac > > [<80127400>] xfs_free_ag_extent+0x128/0x7ac from[<80129658>] > > xfs_free_extent+0xb8/0xe8 > > [<80129658>] xfs_free_extent+0xb8/0xe8 from[<80163978>] > > xlog_recover_process_efi+0x160/0x214 > > [<80163978>] xlog_recover_process_efi+0x160/0x214 from[<80163ac4>] > > xlog_recover_process_efis+0x98/0x11c > > [<80163ac4>] xlog_recover_process_efis+0x98/0x11c from[<8016663c>] > > xlog_recover_finish+0x28/0xdc > > [<8016663c>] xlog_recover_finish+0x28/0xdc from[<8016aec0>] > > xfs_mountfs+0x4d0/0x610 > > [<8016aec0>] xfs_mountfs+0x4d0/0x610 from[<80184434>] > > xfs_fs_fill_super+0x1fc/0x418 > > [<80184434>] xfs_fs_fill_super+0x1fc/0x418 from[<800bae48>] > > get_sb_bdev+0x11c/0x1c0 > > [<800bae48>] get_sb_bdev+0x11c/0x1c0 from[<80181f20>] > > xfs_fs_get_sb+0x20/0x2c > > [<80181f20>] xfs_fs_get_sb+0x20/0x2c from[<800b9424>] > > vfs_kern_mount+0x68/0xd0 > > [<800b9424>] vfs_kern_mount+0x68/0xd0 from[<800b94f0>] > > do_kern_mount+0x54/0x118 > > [<800b94f0>] do_kern_mount+0x54/0x118 from[<800d44e8>] do_mount+0x7b4/0x828 > > [<800d44e8>] do_mount+0x7b4/0x828 from[<800d45f8>] sys_mount+0x9c/0x194 > > [<800d45f8>] sys_mount+0x9c/0x194 from[<800102c4>] stack_done+0x20/0x3c > > > > Failed to recover EFIs on filesystem: sda2 > > XFS: log mount finish failed > > You corrupted a free space btree. Care to tell uswhat test you were > running that caused this? Did you pull the plug on the device > during a copy again? > > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com > > > > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs From sandeen@sandeen.net Wed Dec 8 22:42:22 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB94gMZG178743 for ; Wed, 8 Dec 2010 22:42:22 -0600 X-ASG-Debug-ID: 1291869850-10d901190000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D21B11CA8E2C for ; Wed, 8 Dec 2010 20:44:10 -0800 (PST) Received: from mail.sandeen.net (64-131-28-21.usfamily.net [64.131.28.21]) by cuda.sgi.com with ESMTP id sh9Gy0OVcseLZGzC for ; Wed, 08 Dec 2010 20:44:10 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sandeen.net (Postfix) with ESMTP id 004544817CFA; Wed, 8 Dec 2010 22:44:09 -0600 (CST) Message-ID: <4D005E99.2030400@sandeen.net> Date: Wed, 08 Dec 2010 22:44:09 -0600 From: Eric Sandeen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Dave Chinner CC: blacknred , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: kernel panic-xfs errors Subject: Re: kernel panic-xfs errors References: <30397503.post@talk.nabble.com> <20101207222558.GC29333@dastard> <30403823.post@talk.nabble.com> <20101209005944.GD32766@dastard> In-Reply-To: <20101209005944.GD32766@dastard> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: 64-131-28-21.usfamily.net[64.131.28.21] X-Barracuda-Start-Time: 1291869850 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48890 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 12/8/10 6:59 PM, Dave Chinner wrote: > On Wed, Dec 08, 2010 at 01:39:10AM -0800, blacknred wrote: >> >> >>> You've done a forced module load. No guarantee your kernel is in any >>> sane shape if you've done that.... >> >> Agree, but I'm reasonably convinced that module isn't the issue, because it >> works fine with my other servers...... >> >>> Strange failure. Hmmm - i386 arch and fedora - are you running with >> 4k stacks? If so, maybe it blew the stack... >> >> i386 arch, rhel 5.0 > > Yup, 4k stacks. This is definitely smelling like a stack blowout. well, hang on. The oops said: EIP: 0060:[] Tainted: GF VLI EFLAGS: 00010272 (2.6.33.3-85.fc13.x86_64 #1) EIP is at do_page_fault+0x245/0x617 eax: ec5ee000 ebx: 00000000 ecx: eb5de084 edx: 0000000e esi: 00013103 edi: ec5de0b3 ebp: 00000023 esp: ec5de024 ds: 008b es: 008b ss: 0078 which is NOT a rhel 5.0 kernel, and it says x86_64. But the addresses are all 32 bits? So what's going on here? > esi: 00013103 edi: ec5de0b3 ebp: 00000023 esp: ec5de024 > ds: 008b es: 008b ss: 0078 > Process bm (pid: 3210, ti=ec622000 task=ec5e3450 task.ti=ec6ee000) end of the stack is ec6ee000, stack grows up, esp is at ec5de024, well past it (i.e. yes, overrun) if I remember my stack math right... but that's a pretty huge difference so either I have it wrong, or things are really a huge mess here. -Eric From sandeen@sandeen.net Wed Dec 8 23:13:32 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,J_CHICKENPOX_43, J_CHICKENPOX_44,J_CHICKENPOX_64,J_CHICKENPOX_66,J_CHICKENPOX_73 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB95DWHh184123 for ; Wed, 8 Dec 2010 23:13:32 -0600 X-ASG-Debug-ID: 1291871719-4b8100c50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DC0DF1D2C41 for ; Wed, 8 Dec 2010 21:15:19 -0800 (PST) Received: from mail.sandeen.net (64-131-28-21.usfamily.net [64.131.28.21]) by cuda.sgi.com with ESMTP id MZhwaf2lA8I7j0Az for ; Wed, 08 Dec 2010 21:15:19 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sandeen.net (Postfix) with ESMTP id 8D2C74817CFA; Wed, 8 Dec 2010 23:15:18 -0600 (CST) Message-ID: <4D0065E6.6010009@sandeen.net> Date: Wed, 08 Dec 2010 23:15:18 -0600 From: Eric Sandeen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Lukas Czerner CC: xfs@oss.sgi.com, hch@infradead.org, esandeen@redhat.com X-ASG-Orig-Subj: Re: [PATCH] Add test 248: Check filesystem FITRIM implementation Subject: Re: [PATCH] Add test 248: Check filesystem FITRIM implementation References: <1290780743-12112-1-git-send-email-lczerner@redhat.com> In-Reply-To: <1290780743-12112-1-git-send-email-lczerner@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: 64-131-28-21.usfamily.net[64.131.28.21] X-Barracuda-Start-Time: 1291871719 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48892 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 11/26/10 8:12 AM, Lukas Czerner wrote: > FITRIM ioctl is used on a mounted filesystem to discard (or "trim") > blocks which are not in use by the filesystem. This is useful for > solid-state drives (SSDs) and thinly-provi-sioned storage. This test > helps to verify filesystem FITRIM implementation to assure that it > does not corrupts data. > > This test creates checksums of all files in /usr/share/doc directory and > run several processes which clear its working directory on SCRATCH_MNT, > then copy everything from /usr/share/doc into its working directory, create > list of files in working directory and its checksums and compare it with the > original list of checksums. Every process works in the loop so it repeat > remove->copy->check, while fstrim tool is running simultaneously. > > Fstrim is just a helper tool which uses FITRIM ioctl to actually do the > filesystem discard. > > I found this very useful because when the FITRIM is really buggy (thus > data-destroying) the 248 test will notice, because checksums will most > likely change. > > Signed-off-by: Lukas Czerner > --- > 248 | 163 +++++++++++++++++++++++++++++++++++++ > 248.out | 3 + > group | 1 + > src/Makefile | 2 +- > src/fstrim.c | 257 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > 5 files changed, 425 insertions(+), 1 deletions(-) > create mode 100755 248 > create mode 100644 248.out > create mode 100644 src/fstrim.c > > diff --git a/248 b/248 > new file mode 100755 > index 0000000..0d2f17f > --- /dev/null > +++ b/248 > @@ -0,0 +1,163 @@ > +#!/bin/bash > +# FS QA Test No. 248 > +# > +# This test was created in order to verify filesystem FITRIM implementation. > +# By many concurrent copy and remove operations and checking that files > +# does not change after copied into SCRATCH_MNT test if FITIM implementation typo up there in "FITIM", just FWIW. > +# corrupts the filesystem (data/metadata). > +# > +#----------------------------------------------------------------------- > +# Copyright 2010 (C) Red Hat, Inc., Lukas Czerner > +# > +# This program is free software; you can redistribute it and/or > +# modify it under the terms of the GNU General Public License as > +# published by the Free Software Foundation. > +# > +# This program is distributed in the hope that it would be useful, > +# but WITHOUT ANY WARRANTY; without even the implied warranty of > +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > +# GNU General Public License for more details. > +# > +# You should have received a copy of the GNU General Public License > +# along with this program; if not, write the Free Software Foundation, > +# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA > +#----------------------------------------------------------------------- > + > +owner=lczerner@redhat.com > + > +seq=`basename $0` > +echo "QA output created by $seq" > + > +here=`pwd` > +tmp=`mktemp -d` > +status=1 # failure is the default! > +trap "_cleanup; exit \$status" 0 1 3 > +trap "_destroy; exit \$status" 2 15 > +chpid=0 > +mypid=$$ > + > +# get standard environment, filters and checks > +. ./common.rc > +. ./common.filter > + > +# real QA test starts here > +_supported_fs generic > +_supported_os Linux > +_require_scratch > +_scratch_mkfs >/dev/null 2>&1 > +_scratch_mount > + > +_cleanup() > +{ > + rm -rf $tmp > +} > + > +_destroy() > +{ > + kill $pids $fstrim_pid > + wait $pids $fstrim_pid > + rm -rf $tmp > +} > + > +_destroy_fstrim() > +{ > + kill $fpid > + wait $fpid > +} > + > +fstrim_loop() > +{ > + trap "_destroy_fstrim; exit \$status" 2 15 > + fsize=$(df | grep $SCRATCH_MNT | grep $SCRATCH_DEV | awk '{print $2}') > + > + while true ; do > + step=1048576 > + start=0 > + $here/src/fstrim $SCRATCH_MNT & > + fpid=$! > + wait $fpid > + while [ $start -lt $fsize ] ; do > + $here/src/fstrim -s ${start}k -l ${step}k $SCRATCH_MNT & > + fpid=$! > + wait $fpid > + start=$(( $start + $step )) > + done I may be dense here but a) why do you background and then immediately wait? b) does this start a whole-device trim followed by several smaller range-trims? I could do with some comments, I suppose. > + done > +} > + > +function check_sums() { > + dir=$1 > + > + ( > + cd $SCRATCH_MNT/$p > + find -P . -xdev -type f -print0 | xargs -0 md5sum | sort -o $tmp/stress.$$.$p > + ) > + > + diff $tmp/content.sums $tmp/stress.$$.$p > + if [ $? -ne 0 ]; then > + echo "!!!Checksums has changed - Filesystem possibly corrupted!!!\n" > + kill $mypid what is $mypid? Oh right $$ ... why not: _fail "!!!Checksums has changed - Filesystem possibly corrupted!!!" > + fi > + rm -f $tmp/stress.$$.$p > +} > + > +function run_process() { > + local p=$1 > + repeat=10 > + > + sleep $((5*$p))s & > + export chpid=$! && wait $chpid &> /dev/null I guess I don't sight-read bash very well. What's going on with all the backgrounding/waiting here? > + chpid=0 > + > + while [ $repeat -gt 0 ]; do > + > + # Remove old directories. > + rm -rf $SCRATCH_MNT/$p > + export chpid=$! && wait $chpid &> /dev/null and here? > + # Copy content -> partition. > + mkdir $SCRATCH_MNT/$p > + cp -ax $content/* $SCRATCH_MNT/$p > + export chpid=$! && wait $chpid &> /dev/null > + > + check_sums > + repeat=$(( $repeat - 1 )) > + done > +} > + > +nproc=20 > +content=/usr/share/doc > + > +# Check for FITRIM support > +echo -n "Checking FITRIM support: " > +$here/src/fstrim -l 10M $SCRATCH_MNT > +[ $? -ne 0 ] && exit > +echo "done." > + > +mkdir -p $tmp > + > +( > +cd $content > +find -P . -xdev -type f -print0 | xargs -0 md5sum | sort -o $tmp/content.sums > +) > + > +echo -n "Running the test: " > +pids="" > +fstrim_loop & > +fstrim_pid=$! > +p=1 > +while [ $p -le $nproc ]; do > + run_process $p & > + pids="$pids $!" > + p=$(($p+1)) > +done > +echo "done." > + > +wait $pids > +kill $fstrim_pid > +wait $fstrim_pid > + > +status=0 > +_check_scratch_fs Scratch fs should get checked automatically after the test I think? I guess other tests do this, but I'm not sure it's necessary unless filesystems are made, remounted, etc in a loop during the test > +exit > diff --git a/248.out b/248.out > new file mode 100644 > index 0000000..880d9c7 > --- /dev/null > +++ b/248.out > @@ -0,0 +1,3 @@ > +QA output created by 248 > +Checking FITRIM support: done. > +Running the test: done. > diff --git a/group b/group > index 0f94dd9..fea84ed 100644 > --- a/group > +++ b/group > @@ -361,3 +361,4 @@ deprecated > 245 auto quick dir > 246 auto quick rw > 247 auto quick rw > +248 ioctl I suppose maybe a trim group would be worthwhile at some point ... > diff --git a/src/Makefile b/src/Makefile > index b827bd0..885fd65 100644 > --- a/src/Makefile > +++ b/src/Makefile > @@ -17,7 +17,7 @@ LINUX_TARGETS = xfsctl bstat t_mtab getdevicesize preallo_rw_pattern_reader \ > preallo_rw_pattern_writer ftrunc trunc fs_perms testx looptest \ > locktest unwritten_mmap bulkstat_unlink_test t_stripealign \ > bulkstat_unlink_test_modified t_dir_offset t_futimens t_immutable \ > - stale_handle > + stale_handle fstrim > > SUBDIRS = > > diff --git a/src/fstrim.c b/src/fstrim.c > new file mode 100644 > index 0000000..6686c99 > --- /dev/null > +++ b/src/fstrim.c > @@ -0,0 +1,257 @@ > +/* > + * fstrim.c -- discard the part (or whole) of mounted filesystem. > + * > + * Copyright (C) 2009 Red Hat, Inc., Lukas Czerner 2010 I think :) > + * > + * This program is free software: you can redistribute it and/or modify > + * it under the terms of the GNU General Public License as published by > + * the Free Software Foundation, either version 2 of the License, or > + * (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program. If not, see . > + * > + * This program uses FITRIM ioctl to discard parts or the whole filesystem > + * online (mounted). You can specify range (start and lenght) to be > + * discarded, or simply discard while filesystem. > + * > + * Usage: fstrim [options] > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +#include > +#include > +#include > + > +#ifndef FITRIM > +struct fstrim_range { > + uint64_t start; > + uint64_t len; > + uint64_t minlen; > +}; > +#define FITRIM _IOWR('X', 121, struct fstrim_range) > +#endif > + > +const char *program_name = "fstrim"; > + > +struct options { > + struct fstrim_range *range; > + char mpoint[PATH_MAX]; > + char verbose; > +}; > + > +static void usage(void) > +{ > + fprintf(stderr, > + "Usage: %s [-s start] [-l length] [-m minimum-extent]" > + " [-v] {mountpoint}\n\t" > + "-s Starting Byte to discard from\n\t" > + "-l Number of Bytes to discard from the start\n\t" > + "-m Minimum extent length to discard\n\t" > + "-v Verbose - number of discarded bytes\n", > + program_name); > +} > + > +static void err_exit(const char *fmt, ...) > +{ > + va_list pvar; > + va_start(pvar, fmt); > + vfprintf(stderr, fmt, pvar); > + va_end(pvar); > + usage(); > + exit(EXIT_FAILURE); > +} > + > +/** > + * Get the number from argument. It can be number followed by > + * units: k|K, m|M, g|G, t|T > + */ > +static unsigned long long get_number(char **optarg) > +{ > + char *opt, *end; > + unsigned long long number, max; > + > + /* get the max to avoid overflow */ > + max = ULLONG_MAX / 1024; > + number = 0; > + opt = *optarg; > + > + if (*opt == '-') { > + err_exit("%s: %s (%s)\n", program_name, > + strerror(ERANGE), *optarg); > + } > + > + errno = 0; > + number = strtoul(opt, &end , 0); > + if (errno) > + err_exit("%s: %s (%s)\n", program_name, > + strerror(errno), *optarg); > + > + /* > + * Convert units to numbers. Fall-through stack is used for units > + * so absence of breaks is intentional. > + */ wish we had a library for this sort of thing :( > + switch (*end) { > + case 'T': /* terabytes */ > + case 't': > + if (number > max) > + err_exit("%s: %s (%s)\n", program_name, > + strerror(ERANGE), *optarg); > + number *= 1024; > + case 'G': /* gigabytes */ > + case 'g': > + if (number > max) > + err_exit("%s: %s (%s)\n", program_name, > + strerror(ERANGE), *optarg); > + number *= 1024; > + case 'M': /* megabytes */ > + case 'm': > + if (number > max) > + err_exit("%s: %s (%s)\n", program_name, > + strerror(ERANGE), *optarg); > + number *= 1024; > + case 'K': /* kilobytes */ > + case 'k': > + if (number > max) > + err_exit("%s: %s (%s)\n", program_name, > + strerror(ERANGE), *optarg); > + number *= 1024; > + end++; > + case '\0': /* end of the string */ > + break; > + default: > + err_exit("%s: %s (%s)\n", program_name, > + strerror(EINVAL), *optarg); > + return 0; > + } > + > + if (*end != '\0') { > + err_exit("%s: %s (%s)\n", program_name, > + strerror(EINVAL), *optarg); > + } > + > + return number; > +} > + > +static int parse_opts(int argc, char **argv, struct options *opts) > +{ > + int c; > + > + while ((c = getopt(argc, argv, "s:l:m:v")) != EOF) { > + switch (c) { > + case 's': /* starting point */ > + opts->range->start = get_number(&optarg); > + break; > + case 'l': /* length */ > + opts->range->len = get_number(&optarg); > + break; > + case 'm': /* minlen */ > + opts->range->minlen = get_number(&optarg); > + break; > + case 'v': /* verbose */ > + opts->verbose = 1; > + break; > + default: > + return EXIT_FAILURE; > + } > + } > + > + return 0; > +} > + > +int main(int argc, char **argv) > +{ > + struct options *opts; > + struct stat sb; > + int fd, err = 0, ret = EXIT_FAILURE; > + > + opts = malloc(sizeof(struct options)); > + if (!opts) > + err_exit("%s: malloc(): %s\n", program_name, strerror(errno)); > + > + opts->range = NULL; > + opts->verbose = 0; > + > + if (argc > 1) > + strncpy(opts->mpoint, argv[argc - 1], sizeof(opts->mpoint)); > + > + opts->range = calloc(1, sizeof(struct fstrim_range)); > + if (!opts->range) { > + fprintf(stderr, "%s: calloc(): %s\n", program_name, > + strerror(errno)); > + goto free_opts; > + } > + > + opts->range->len = ULLONG_MAX; > + > + if (argc > 2) > + err = parse_opts(argc, argv, opts); > + > + if (err) { > + usage(); > + goto free_opts; > + } > + > + if (strnlen(opts->mpoint, 1) < 1) { > + fprintf(stderr, "%s: You have to specify mount point.\n", > + program_name); > + usage(); > + goto free_opts; > + } > + > + if (stat(opts->mpoint, &sb) == -1) { > + fprintf(stderr, "%s: %s: %s\n", program_name, > + opts->mpoint, strerror(errno)); > + usage(); > + goto free_opts; > + } > + > + if (!S_ISDIR(sb.st_mode)) { > + fprintf(stderr, "%s: %s: (%s)\n", program_name, > + opts->mpoint, strerror(ENOTDIR)); > + usage(); > + goto free_opts; > + } > + > + fd = open(opts->mpoint, O_RDONLY); > + if (fd < 0) { > + fprintf(stderr, "%s: open(%s): %s\n", program_name, > + opts->mpoint, strerror(errno)); > + goto free_opts; > + } > + > + if (ioctl(fd, FITRIM, opts->range)) { > + fprintf(stderr, "%s: FSTRIM: %s\n", program_name, > + strerror(errno)); > + goto free_opts; > + } > + > + if ((opts->verbose) && (opts->range)) > + fprintf(stdout, "%llu Bytes was trimmed\n", opts->range->len); "Bytes were trimmed," just FWIW > + > + ret = EXIT_SUCCESS; > + > +free_opts: > + if (opts) { > + if (opts->range) > + free(opts->range); > + free(opts); > + } > + > + return ret; > +} From SRS0+rFbk+12+fromorbit.com=david@internode.on.net Thu Dec 9 04:34:22 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB9AYLc2233074 for ; Thu, 9 Dec 2010 04:34:22 -0600 X-ASG-Debug-ID: 1291890967-032b03e50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2EC59152AFC6 for ; Thu, 9 Dec 2010 02:36:08 -0800 (PST) Received: from mail.internode.on.net (bld-mail13.adl6.internode.on.net [150.101.137.98]) by cuda.sgi.com with ESMTP id yebwcRK5aipmAlQy for ; Thu, 09 Dec 2010 02:36:08 -0800 (PST) Received: from dastard (unverified [121.44.88.148]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 49518214-1927428 for multiple; Thu, 09 Dec 2010 21:06:07 +1030 (CDT) Received: from dave by dastard with local (Exim 4.71) (envelope-from ) id 1PQdr3-0002Z2-QN; Thu, 09 Dec 2010 21:36:05 +1100 Date: Thu, 9 Dec 2010 21:36:05 +1100 From: Dave Chinner To: Christoph Hellwig Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] xfs: log timestamp changes to the source inode in rename Subject: Re: [PATCH] xfs: log timestamp changes to the source inode in rename Message-ID: <20101209103605.GC29856@dastard> References: <20101207101641.GA25995@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101207101641.GA25995@infradead.org> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: bld-mail13.adl6.internode.on.net[150.101.137.98] X-Barracuda-Start-Time: 1291890970 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48915 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Tue, Dec 07, 2010 at 05:16:41AM -0500, Christoph Hellwig wrote: > Now that we don't mark VFS inodes dirty anymore for internal timestamp changes, > but rely on the transaction subsystem to push them out, we need to explicitly > log the source inode in rename after updating it's timestamps to make sure > the changes actually get forced out by sync/fsync or an AIL push. > > We already account for the fourth inode in the log reservation, as a rename > of directories needs to update the nlink field, so just adding the > xfs_trans_log_inode call is enough. > > This fixes the xfsqa 065 regression introduced by: > > "xfs: don't use vfs writeback for pure metadata modifications" > > > Signed-off-by: Christoph Hellwig Looks good. Reviewed-by: Dave Chinner -- Dave Chinner david@fromorbit.com From lczerner@redhat.com Thu Dec 9 05:01:16 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB9B1Gqe237089 for ; Thu, 9 Dec 2010 05:01:16 -0600 X-ASG-Debug-ID: 1291892584-46ac00e40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 669961C9A025 for ; Thu, 9 Dec 2010 03:03:04 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id ED3pvaWjGVHV2tXQ for ; Thu, 09 Dec 2010 03:03:04 -0800 (PST) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oB9B2wBo012891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Dec 2010 06:02:58 -0500 Received: from dhcp-lab-213.englab.brq.redhat.com (dhcp-27-109.brq.redhat.com [10.34.27.109]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id oB9B2tME007164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Dec 2010 06:02:56 -0500 Date: Thu, 9 Dec 2010 12:02:52 +0100 (CET) From: Lukas Czerner X-X-Sender: lukas@dhcp-lab-213.englab.brq.redhat.com To: Eric Sandeen cc: Lukas Czerner , xfs@oss.sgi.com, hch@infradead.org, esandeen@redhat.com X-ASG-Orig-Subj: Re: [PATCH] Add test 248: Check filesystem FITRIM implementation Subject: Re: [PATCH] Add test 248: Check filesystem FITRIM implementation In-Reply-To: <4D0065E6.6010009@sandeen.net> Message-ID: References: <1290780743-12112-1-git-send-email-lczerner@redhat.com> <4D0065E6.6010009@sandeen.net> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1291892585 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Wed, 8 Dec 2010, Eric Sandeen wrote: > On 11/26/10 8:12 AM, Lukas Czerner wrote: > > FITRIM ioctl is used on a mounted filesystem to discard (or "trim") > > blocks which are not in use by the filesystem. This is useful for > > solid-state drives (SSDs) and thinly-provi-sioned storage. This test > > helps to verify filesystem FITRIM implementation to assure that it > > does not corrupts data. > > > > This test creates checksums of all files in /usr/share/doc directory and > > run several processes which clear its working directory on SCRATCH_MNT, > > then copy everything from /usr/share/doc into its working directory, create > > list of files in working directory and its checksums and compare it with the > > original list of checksums. Every process works in the loop so it repeat > > remove->copy->check, while fstrim tool is running simultaneously. > > > > Fstrim is just a helper tool which uses FITRIM ioctl to actually do the > > filesystem discard. > > > > I found this very useful because when the FITRIM is really buggy (thus > > data-destroying) the 248 test will notice, because checksums will most > > likely change. > > > > Signed-off-by: Lukas Czerner -snip- > > + > > +fstrim_loop() > > +{ > > + trap "_destroy_fstrim; exit \$status" 2 15 > > + fsize=$(df | grep $SCRATCH_MNT | grep $SCRATCH_DEV | awk '{print $2}') > > + > > + while true ; do > > + step=1048576 > > + start=0 > > + $here/src/fstrim $SCRATCH_MNT & > > + fpid=$! > > + wait $fpid > > + while [ $start -lt $fsize ] ; do > > + $here/src/fstrim -s ${start}k -l ${step}k $SCRATCH_MNT & > > + fpid=$! > > + wait $fpid > > + start=$(( $start + $step )) > > + done > > I may be dense here but > > a) why do you background and then immediately wait? > b) does this start a whole-device trim followed by several > smaller range-trims? > > I could do with some comments, I suppose. Hi Eric, all the waiting is done because Bash is incredibly stupid. As you know, fstrim_loop is run at background and when the test is over, or when it is killed (with ^C), because of trap, it tries to kill fstrim_loop. However, it does not kill currently running commands, so fstrim might be still running making it impossible to umount the SCRATCH_MNT. So this way, I can kill the running process directly. I believe I am not the first one running into this troubles, so maybe there is a better way ? > > > + done > > +} > > + > > +function check_sums() { > > + dir=$1 > > + > > + ( > > + cd $SCRATCH_MNT/$p > > + find -P . -xdev -type f -print0 | xargs -0 md5sum | sort -o $tmp/stress.$$.$p > > + ) > > + > > + diff $tmp/content.sums $tmp/stress.$$.$p > > + if [ $? -ne 0 ]; then > > + echo "!!!Checksums has changed - Filesystem possibly corrupted!!!\n" > > + kill $mypid > > what is $mypid? Oh right $$ ... why not: > > _fail "!!!Checksums has changed - Filesystem possibly corrupted!!!" oh, that's better, thanks. > > > + fi > > + rm -f $tmp/stress.$$.$p > > +} > > + > > +function run_process() { > > + local p=$1 > > + repeat=10 > > + > > + sleep $((5*$p))s & > > + export chpid=$! && wait $chpid &> /dev/null > > I guess I don't sight-read bash very well. What's going > on with all the backgrounding/waiting here? > > > + chpid=0 > > + > > + while [ $repeat -gt 0 ]; do > > + > > + # Remove old directories. > > + rm -rf $SCRATCH_MNT/$p > > + export chpid=$! && wait $chpid &> /dev/null > > and here? The same thing here, the process will still be running when xfstests will attempt to umount SCRATCH_MNT, resulting in error. This way I can kill it directly. > > > + # Copy content -> partition. > > + mkdir $SCRATCH_MNT/$p > > + cp -ax $content/* $SCRATCH_MNT/$p > > + export chpid=$! && wait $chpid &> /dev/null > > + > > + check_sums > > + repeat=$(( $repeat - 1 )) > > + done > > +} > > + > > +nproc=20 > > +content=/usr/share/doc > > + > > +# Check for FITRIM support > > +echo -n "Checking FITRIM support: " > > +$here/src/fstrim -l 10M $SCRATCH_MNT > > +[ $? -ne 0 ] && exit > > +echo "done." > > + > > +mkdir -p $tmp > > + > > +( > > +cd $content > > +find -P . -xdev -type f -print0 | xargs -0 md5sum | sort -o $tmp/content.sums > > +) > > + > > +echo -n "Running the test: " > > +pids="" > > +fstrim_loop & > > +fstrim_pid=$! > > +p=1 > > +while [ $p -le $nproc ]; do > > + run_process $p & > > + pids="$pids $!" > > + p=$(($p+1)) > > +done > > +echo "done." > > + > > +wait $pids > > +kill $fstrim_pid > > +wait $fstrim_pid > > + > > +status=0 > > +_check_scratch_fs > > Scratch fs should get checked automatically after the test I think? > I guess other tests do this, but I'm not sure it's necessary > unless filesystems are made, remounted, etc in a loop during > the test Ok, I'll get rid of it. > > > +exit > > diff --git a/248.out b/248.out > > new file mode 100644 > > index 0000000..880d9c7 > > --- /dev/null > > +++ b/248.out > > @@ -0,0 +1,3 @@ > > +QA output created by 248 > > +Checking FITRIM support: done. > > +Running the test: done. > > diff --git a/group b/group > > index 0f94dd9..fea84ed 100644 > > --- a/group > > +++ b/group > > @@ -361,3 +361,4 @@ deprecated > > 245 auto quick dir > > 246 auto quick rw > > 247 auto quick rw > > +248 ioctl > > I suppose maybe a trim group would be worthwhile at some point ... Added. > > > diff --git a/src/Makefile b/src/Makefile > > index b827bd0..885fd65 100644 > > --- a/src/Makefile > > +++ b/src/Makefile > > @@ -17,7 +17,7 @@ LINUX_TARGETS = xfsctl bstat t_mtab getdevicesize preallo_rw_pattern_reader \ > > preallo_rw_pattern_writer ftrunc trunc fs_perms testx looptest \ > > locktest unwritten_mmap bulkstat_unlink_test t_stripealign \ > > bulkstat_unlink_test_modified t_dir_offset t_futimens t_immutable \ > > - stale_handle > > + stale_handle fstrim > > > > SUBDIRS = > > > > diff --git a/src/fstrim.c b/src/fstrim.c > > new file mode 100644 > > index 0000000..6686c99 > > --- /dev/null > > +++ b/src/fstrim.c > > @@ -0,0 +1,257 @@ > > +/* > > + * fstrim.c -- discard the part (or whole) of mounted filesystem. > > + * > > + * Copyright (C) 2009 Red Hat, Inc., Lukas Czerner > > 2010 I think :) Hmm, still living in the past :). Thanks for review Eric! -Lukas -snip- From lczerner@redhat.com Thu Dec 9 05:09:38 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB9B9cUx238856 for ; Thu, 9 Dec 2010 05:09:38 -0600 X-ASG-Debug-ID: 1291893086-14e303c10000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7B6921D80E8 for ; Thu, 9 Dec 2010 03:11:26 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 2oaAii4xP99OmyQL for ; Thu, 09 Dec 2010 03:11:26 -0800 (PST) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oB9BBNYX014336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Dec 2010 06:11:24 -0500 Received: from dhcp-lab-213.englab.brq.redhat.com (dhcp-27-109.brq.redhat.com [10.34.27.109]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id oB9BBLfg018056 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Dec 2010 06:11:22 -0500 Date: Thu, 9 Dec 2010 12:11:20 +0100 (CET) From: Lukas Czerner X-X-Sender: lukas@dhcp-lab-213.englab.brq.redhat.com To: Lukas Czerner cc: Eric Sandeen , xfs@oss.sgi.com, hch@infradead.org, esandeen@redhat.com X-ASG-Orig-Subj: Re: [PATCH] Add test 248: Check filesystem FITRIM implementation Subject: Re: [PATCH] Add test 248: Check filesystem FITRIM implementation In-Reply-To: Message-ID: References: <1290780743-12112-1-git-send-email-lczerner@redhat.com> <4D0065E6.6010009@sandeen.net> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1291893087 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, 9 Dec 2010, Lukas Czerner wrote: > On Wed, 8 Dec 2010, Eric Sandeen wrote: > > > On 11/26/10 8:12 AM, Lukas Czerner wrote: > > > FITRIM ioctl is used on a mounted filesystem to discard (or "trim") > > > blocks which are not in use by the filesystem. This is useful for > > > solid-state drives (SSDs) and thinly-provi-sioned storage. This test > > > helps to verify filesystem FITRIM implementation to assure that it > > > does not corrupts data. > > > > > > This test creates checksums of all files in /usr/share/doc directory and > > > run several processes which clear its working directory on SCRATCH_MNT, > > > then copy everything from /usr/share/doc into its working directory, create > > > list of files in working directory and its checksums and compare it with the > > > original list of checksums. Every process works in the loop so it repeat > > > remove->copy->check, while fstrim tool is running simultaneously. > > > > > > Fstrim is just a helper tool which uses FITRIM ioctl to actually do the > > > filesystem discard. > > > > > > I found this very useful because when the FITRIM is really buggy (thus > > > data-destroying) the 248 test will notice, because checksums will most > > > likely change. > > > > > > Signed-off-by: Lukas Czerner > > -snip- > > > > + > > > +fstrim_loop() > > > +{ > > > + trap "_destroy_fstrim; exit \$status" 2 15 > > > + fsize=$(df | grep $SCRATCH_MNT | grep $SCRATCH_DEV | awk '{print $2}') > > > + > > > + while true ; do > > > + step=1048576 > > > + start=0 > > > + $here/src/fstrim $SCRATCH_MNT & > > > + fpid=$! > > > + wait $fpid > > > + while [ $start -lt $fsize ] ; do > > > + $here/src/fstrim -s ${start}k -l ${step}k $SCRATCH_MNT & > > > + fpid=$! > > > + wait $fpid > > > + start=$(( $start + $step )) > > > + done > > > > I may be dense here but > > > > a) why do you background and then immediately wait? > > b) does this start a whole-device trim followed by several > > smaller range-trims? I forgot about this one. The reason for this is, that this way we can get better test coverage of the kernel code, because the code path of smaller trims (especially not ag-aligned) might be slightly different, so we test that case as well. -Lukas > > > > I could do with some comments, I suppose. > > Hi Eric, > > all the waiting is done because Bash is incredibly stupid. As you know, > fstrim_loop is run at background and when the test is over, or when it > is killed (with ^C), because of trap, it tries to kill fstrim_loop. > However, it does not kill currently running commands, so fstrim might be > still running making it impossible to umount the SCRATCH_MNT. > > So this way, I can kill the running process directly. I believe I am not > the first one running into this troubles, so maybe there is a better way > ? > From branto@redhat.com Thu Dec 9 07:03:59 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB9D3wWj258219 for ; Thu, 9 Dec 2010 07:03:58 -0600 X-ASG-Debug-ID: 1291899947-46f203da0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 204901CA9E4E for ; Thu, 9 Dec 2010 05:05:47 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id 8fNaJe8Tg6CrEuKD for ; Thu, 09 Dec 2010 05:05:47 -0800 (PST) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oB9D5kHF021986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 9 Dec 2010 08:05:46 -0500 Received: from [10.34.26.208] (dhcp-26-208.brq.redhat.com [10.34.26.208]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id oB9D5iQn006710 for ; Thu, 9 Dec 2010 08:05:45 -0500 X-ASG-Orig-Subj: xfstests: ignore absolute address in filename in test case 237 Subject: xfstests: ignore absolute address in filename in test case 237 From: Boris Ranto To: xfs@oss.sgi.com Content-Type: text/plain; charset="UTF-8" Date: Thu, 09 Dec 2010 14:05:44 +0100 Message-ID: <1291899944.3196.11.camel@dhcp-31-190.brq.redhat.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1291899948 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Test case 237 checks for setfacl output. The setfacl can use both relative address or absolute address for filename. Following patch ignores the unnecessary part of absolute address and therefore the test case can pass on systems that output absolute address: diff -urpN a/xfstests/237 b/xfstests/237 --- a/xfstests/237 2010-12-09 11:24:48.587432718 +0100 +++ b/xfstests/237 2010-12-09 13:46:29.008245581 +0100 @@ -72,7 +72,7 @@ touch file1 chown $acl1.$acl1 file1 echo "Expect to FAIL" -$runas -u $acl2 -g $acl2 -- `which setfacl` -m u::rwx file1 2>&1 +$runas -u $acl2 -g $acl2 -- `which setfacl` -m u::rwx file1 2>&1 | sed 's/^setfacl: \/.*file1: Operation not permitted$/setfacl: file1: Operation not permitted/' echo "Test over." # success, all done Signed-off-by: Boris Ranto From lists@nabble.com Thu Dec 9 07:15:15 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, T_TO_NO_BRKTS_FREEMAIL autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB9DFFld260535 for ; Thu, 9 Dec 2010 07:15:15 -0600 X-ASG-Debug-ID: 1291900623-5a0502c20000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from kuber.nabble.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1749B1D8868 for ; Thu, 9 Dec 2010 05:17:03 -0800 (PST) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by cuda.sgi.com with ESMTP id VcHcD7PAbIJhwYCS for ; Thu, 09 Dec 2010 05:17:03 -0800 (PST) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1PQgMp-0003K0-3B for xfs@oss.sgi.com; Thu, 09 Dec 2010 05:17:03 -0800 Message-ID: <30416394.post@talk.nabble.com> Date: Thu, 9 Dec 2010 05:17:03 -0800 (PST) From: blacknred To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: kernel panic-xfs errors Subject: Re: kernel panic-xfs errors In-Reply-To: <4D005E99.2030400@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: leo1783@hotmail.co.uk References: <30397503.post@talk.nabble.com> <20101207222558.GC29333@dastard> <30403823.post@talk.nabble.com> <20101209005944.GD32766@dastard> <4D005E99.2030400@sandeen.net> X-Barracuda-Connect: kuber.nabble.com[216.139.236.158] X-Barracuda-Start-Time: 1291900624 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48924 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean >which is NOT a rhel 5.0 kernel, and it says x86_64. >But the addresses are all 32 bits? My apologies there, somehow it all got jumbled up, pasting it again: BUG: unable to handle kernel NULL pointer dereference at virtual address 00000098 printing eip: *pde = 2c621001 Oops: 0000 [#1] SMP CPU: 2 EIP: 0060:[] Tainted: GF VLI EFLAGS: 00010282 (2.6.18-164.11.1.el5PAE #1) EIP is at do_page_fault+0x205/0x607 eax: ec6de000 ebx: 00000000 ecx: ec6de074 edx: 0000000d esi: 00014005 edi: ec6de0a4 ebp: 00000014 esp: ec6de054 ds: 007b es: 007b ss: 0068 Process bm (pid: 2910, ti=ec6dd000 task=ec6e3550 task.ti=ec6dd000) Stack: 00000000 00000000 ec6de0a4 00000014 00000098 f7180000 00000001 00000000 ec6de0a4 c0639439 00000000 0000000e 0000000b 00000000 00000000 00000000 00014005 c0619b9c 00000014 c0405a89 00000000 ec6de0f8 0000000d 00014005 Call Trace: [] do_page_fault+0x0/0x607 [] error_code+0x39/0x40 [] do_page_fault+0x205/0x607 [] elv_next_request+0x127/0x134 [] do_cciss_request+0x398/0x3a3 [cciss] [] do_page_fault+0x0/0x607 [] error_code+0x39/0x40 [] do_page_fault+0x205/0x607 [] deadline_set_request+0x16/0x57 [] do_page_fault+0x0/0x607 [] error_code+0x39/0x40 [] do_page_fault+0x205/0x607 [] do_page_fault+0x0/0x607 [] error_code+0x39/0x40 [] do_page_fault+0x205/0x607 [] do_page_fault+0x0/0x607 [] error_code+0x39/0x40 [] __down+0x2b/0xbb [] default_wake_function+0x0/0xc [] __down_failed+0x7/0xc [] .text.lock.xfs_buf+0x17/0x5f [xfs] [] xfs_buf_read_flags+0x48/0x76 [xfs] [] xfs_trans_read_buf+0x1bb/0x2c0 [xfs] [] xfs_btree_read_bufl+0x96/0xb3 [xfs] [] xfs_bmbt_lookup+0x135/0x478 [xfs] [] xfs_bmap_add_extent+0xd2b/0x1e30 [xfs] [] xfs_alloc_update+0x3a/0xbc [xfs] [] xfs_alloc_fixup_trees+0x217/0x29a [xfs] [] xfs_trans_log_buf+0x49/0x6c [xfs] [] xfs_alloc_search_busy+0x20/0xae [xfs] [] xfs_iext_bno_to_ext+0xd8/0x191 [xfs] [] kmem_zone_zalloc+0x1d/0x41 [xfs] [] xfs_bmapi+0x15fe/0x2016 [xfs] [] xfs_iext_bno_to_ext+0x48/0x191 [xfs] [] xfs_bmap_search_multi_extents+0x8a/0xc5 [xfs] [] xfs_iomap_write_allocate+0x29c/0x469 [xfs] [] lock_timer_base+0x15/0x2f [] del_timer+0x41/0x47 [] xfs_iomap+0x409/0x71d [xfs] [] xfs_map_blocks+0x29/0x52 [xfs] [] xfs_page_state_convert+0x37b/0xd2e [xfs] [] xfs_bmap_add_extent+0x1dcf/0x1e30 [xfs] [] xfs_bmap_search_multi_extents+0x8a/0xc5 [xfs] [] xfs_bmapi+0x272/0x2016 [xfs] [] xfs_bmapi+0x1853/0x2016 [xfs] [] find_get_pages_tag+0x30/0x75 [] xfs_vm_writepage+0x8f/0xc2 [xfs] [] mpage_writepages+0x1a7/0x310 [] xfs_vm_writepage+0x0/0xc2 [xfs] [] do_writepages+0x20/0x32 [] __writeback_single_inode+0x170/0x2af [] write_inode_now+0x66/0xa7 [] file_fsync+0xf/0x6c [] moddw_ioctl+0x420/0x669 [mod_dw] [] __cond_resched+0x16/0x34 [] do_ioctl+0x47/0x5d [] vfs_ioctl+0x47b/0x4d3 [] sys_ioctl+0x48/0x5f [] sysenter_past_esp+0x56/0x79 Thanks, sorry for the confusion.... Eric Sandeen-3 wrote: > > On 12/8/10 6:59 PM, Dave Chinner wrote: >> On Wed, Dec 08, 2010 at 01:39:10AM -0800, blacknred wrote: >>> >>> >>>> You've done a forced module load. No guarantee your kernel is in any >>>> sane shape if you've done that.... >>> >>> Agree, but I'm reasonably convinced that module isn't the issue, because >>> it >>> works fine with my other servers...... >>> >>>> Strange failure. Hmmm - i386 arch and fedora - are you running with >>> 4k stacks? If so, maybe it blew the stack... >>> >>> i386 arch, rhel 5.0 >> >> Yup, 4k stacks. This is definitely smelling like a stack blowout. > > well, hang on. The oops said: > > EIP: 0060:[] Tainted: GF VLI > EFLAGS: 00010272 (2.6.33.3-85.fc13.x86_64 #1) > EIP is at do_page_fault+0x245/0x617 > eax: ec5ee000 ebx: 00000000 ecx: eb5de084 edx: 0000000e > esi: 00013103 edi: ec5de0b3 ebp: 00000023 esp: ec5de024 > ds: 008b es: 008b ss: 0078 > > which is NOT a rhel 5.0 kernel, and it says x86_64. > > But the addresses are all 32 bits? > > So what's going on here? > >> esi: 00013103 edi: ec5de0b3 ebp: 00000023 esp: ec5de024 >> ds: 008b es: 008b ss: 0078 >> Process bm (pid: 3210, ti=ec622000 task=ec5e3450 task.ti=ec6ee000) > > end of the stack is ec6ee000, stack grows up, esp is at ec5de024, > well past it (i.e. yes, overrun) if I remember my stack math > right... but that's a pretty huge difference so either I have it > wrong, or things are really a huge mess here. > > -Eric > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > > -- View this message in context: http://old.nabble.com/kernel-panic-xfs-errors-tp30397503p30416394.html Sent from the Xfs - General mailing list archive at Nabble.com. From lists@nabble.com Thu Dec 9 07:21:47 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, T_TO_NO_BRKTS_FREEMAIL autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB9DLlmc001433 for ; Thu, 9 Dec 2010 07:21:47 -0600 X-ASG-Debug-ID: 1291901015-5fa103620000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from kuber.nabble.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id E9A791E974D8 for ; Thu, 9 Dec 2010 05:23:35 -0800 (PST) Received: from kuber.nabble.com (kuber.nabble.com [216.139.236.158]) by cuda.sgi.com with ESMTP id 7CXP3s18Os9H1E4U for ; Thu, 09 Dec 2010 05:23:35 -0800 (PST) Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1PQgT9-0003nW-1s for xfs@oss.sgi.com; Thu, 09 Dec 2010 05:23:35 -0800 Message-ID: <30416451.post@talk.nabble.com> Date: Thu, 9 Dec 2010 05:23:35 -0800 (PST) From: blacknred To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: kernel panic-xfs errors Subject: Re: kernel panic-xfs errors In-Reply-To: <20101209005944.GD32766@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: leo1783@hotmail.co.uk References: <30397503.post@talk.nabble.com> <20101207222558.GC29333@dastard> <30403823.post@talk.nabble.com> <20101209005944.GD32766@dastard> X-Barracuda-Connect: kuber.nabble.com[216.139.236.158] X-Barracuda-Start-Time: 1291901015 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.52 X-Barracuda-Spam-Status: No, SCORE=-1.52 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_RULE7568M X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48926 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean >Is the version 7.x firmware certified with such an old kernel? Yes, it is... It hung again today and dmesg said XFS: bad magic number XFS: SB validate failed But when I do dd if=/dev/cciss/c0d0 bs=512 count=1 |od -c I get below which suggests its a valid XFS superblock magic number as per your reply, correct? I couldn't unmount the partition to do a xfs_repair -n 1+0 records in 1+0 records out 0000000 X F S B \0 \0 020 \0 \0 \0 \0 \0 + 251 262 ^ 512 bytes (512 B) copied0000020 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000040 354 B \b 277 ) 376 @ 333 267 232 304 326 * L 344 322 0000060 \0 \0 \0 \0 \0 \0 @ \0 \0 \0 \0 \0 \0 \0 200 0000100 \0 \0 \0 \0 \0 \0 \0 201 \0 \0 \0 \0 \0 \0 \0 202 0000120 \0 \0 \0 001 \n 352 l 300 \0 \0 \0 004 \0 \0 \0 \0 , 0.000190895 seconds, 2.7 MB/s 0000140 \0 \0 200 \0 265 244 002 \0 \b \0 \0 002 \0 \0 \0 \0 0000160 \0 \0 \0 \0 \0 \0 \0 \0 \b \t \v 001 034 \0 \0 005 0000200 \0 \0 \0 \0 \0 \0 \v \0 \0 \0 \0 \0 \0 \0 \t . 0000220 \0 \0 \0 \0 030 243 275 267 \0 \0 \0 \0 \0 \0 \0 \0 0000240 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 0000260 \0 \0 \0 \0 \0 \0 \0 002 \0 \0 \0 @ \0 \0 001 \0 0000300 \0 \0 \0 \0 \0 004 \0 \0 \0 \0 \0 \b \0 \0 \0 \b 0000320 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 * 0001000 Dave Chinner wrote: > > On Wed, Dec 08, 2010 at 01:39:10AM -0800, blacknred wrote: >> >> >> >You've done a forced module load. No guarantee your kernel is in any >> >sane shape if you've done that.... >> >> Agree, but I'm reasonably convinced that module isn't the issue, because >> it >> works fine with my other servers...... >> >> >Strange failure. Hmmm - i386 arch and fedora - are you running with >> 4k stacks? If so, maybe it blew the stack... >> >> i386 arch, rhel 5.0 > > Yup, 4k stacks. This is definitely smelling like a stack blowout. > > XFS on 4k stacks is a ticking timebomb - it will explode and you've > got no idea of when it will go boom. Recompile your kernel with 8k > stacks or move to x86_64. > >> ># dd if= bs=512 count=1 | od -c >> This is what i get now, but now server's been rebooted and running OK, >> what >> should i be expecting or rather what are we looking for in this output at >> point of failure? > > Well, what you see here: > >> 0000000 X F S B \0 \0 020 \0 \0 \0 \0 \0 025 324 304 \0 > ^^^^^^^^^^^^^ > Is a valid XFS superblock magic number. > > If you are getting this error: > >> >> XFS: bad magic number >> >> XFS: SB validate failed > > Then I'd expect to see anything other than "XFSB" as the magic > number. Of course, if you smashed the stack during mount, then there > will most likely be nothing wrong with the value on disk... > >> >why did I flash the controller >> I was on 5.22 fw version which has a known 'lockup' issue which is fixed >> in >> 7.x ver. >> This is a critical fix. > > Is the version 7.x firmware certified with such an old kernel? It's > not uncommon for different firmware versions to only be supported on > specific releases/kernel versions. > > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > > -- View this message in context: http://old.nabble.com/kernel-panic-xfs-errors-tp30397503p30416451.html Sent from the Xfs - General mailing list archive at Nabble.com. From branto@redhat.com Thu Dec 9 07:39:01 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB9Dd046008000 for ; Thu, 9 Dec 2010 07:39:01 -0600 X-ASG-Debug-ID: 1291902049-5fa803c70000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2575E1E97855 for ; Thu, 9 Dec 2010 05:40:49 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id doEind54yKDS33GZ for ; Thu, 09 Dec 2010 05:40:49 -0800 (PST) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oB9DemXI027963 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 9 Dec 2010 08:40:49 -0500 Received: from [10.34.26.208] (dhcp-26-208.brq.redhat.com [10.34.26.208]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id oB9DelMI016524 for ; Thu, 9 Dec 2010 08:40:48 -0500 X-ASG-Orig-Subj: Re: xfstests: ignore absolute address in filename in test case 237 Subject: Re: xfstests: ignore absolute address in filename in test case 237 From: Boris Ranto To: xfs@oss.sgi.com In-Reply-To: <1291899944.3196.11.camel@dhcp-31-190.brq.redhat.com> References: <1291899944.3196.11.camel@dhcp-31-190.brq.redhat.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 09 Dec 2010 14:40:47 +0100 Message-ID: <1291902047.3196.26.camel@dhcp-31-190.brq.redhat.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.11 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1291902050 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, 2010-12-09 at 14:05 +0100, Boris Ranto wrote: > Test case 237 checks for setfacl output. The setfacl can use both > relative address or absolute address for filename. > > Following patch ignores the unnecessary part of absolute address and > therefore the test case can pass on systems that output absolute > address: > > diff -urpN a/xfstests/237 b/xfstests/237 > --- a/xfstests/237 2010-12-09 11:24:48.587432718 +0100 > +++ b/xfstests/237 2010-12-09 13:46:29.008245581 +0100 > @@ -72,7 +72,7 @@ touch file1 > chown $acl1.$acl1 file1 > > echo "Expect to FAIL" > -$runas -u $acl2 -g $acl2 -- `which setfacl` -m u::rwx file1 2>&1 > +$runas -u $acl2 -g $acl2 -- `which setfacl` -m u::rwx file1 2>&1 | sed 's/^setfacl: \/.*file1: Operation not permitted$/setfacl: file1: Operation not permitted/' > > echo "Test over." > # success, all done > > Signed-off-by: Boris Ranto I noticed that text is usually filtered in a little different way therefore I'd rather suggest the following patch: diff -urpN a/xfstests/237 b/xfstests/237 --- a/xfstests/237 2010-12-09 11:24:48.587432718 +0100 +++ b/xfstests/237 2010-12-09 14:24:09.463402051 +0100 @@ -47,6 +47,11 @@ _cleanup() _cleanup_testdir } +# Allow absolute path in setfacl output +_filter_absolute_path() +{ + sed 's/^setfacl: \/.*file1: Operation not permitted$/setfacl: file1: Operation not permitted/' +} # real QA test starts here _supported_fs generic # only Linux supports fallocate @@ -72,7 +77,7 @@ touch file1 chown $acl1.$acl1 file1 echo "Expect to FAIL" -$runas -u $acl2 -g $acl2 -- `which setfacl` -m u::rwx file1 2>&1 +$runas -u $acl2 -g $acl2 -- `which setfacl` -m u::rwx file1 2>&1 | _filter_absolute_path echo "Test over." # success, all done From branto@redhat.com Thu Dec 9 08:38:26 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_34 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB9EcPXu017339 for ; Thu, 9 Dec 2010 08:38:26 -0600 X-ASG-Debug-ID: 1291905614-610001ad0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5E3CC1D8A10 for ; Thu, 9 Dec 2010 06:40:14 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id LqB3eRtOQPH79z6f for ; Thu, 09 Dec 2010 06:40:14 -0800 (PST) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oB9EeEFB015374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 9 Dec 2010 09:40:14 -0500 Received: from [10.34.26.208] (dhcp-26-208.brq.redhat.com [10.34.26.208]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id oB9EeDLZ008302 for ; Thu, 9 Dec 2010 09:40:13 -0500 X-ASG-Orig-Subj: xfstests: fix 108 through config mechanism Subject: xfstests: fix 108 through config mechanism From: Boris Ranto To: xfs@oss.sgi.com Content-Type: text/plain; charset="UTF-8" Date: Thu, 09 Dec 2010 15:40:12 +0100 Message-ID: <1291905612.3196.49.camel@dhcp-31-190.brq.redhat.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1291905615 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Test case 108 can fail beacuse of the incorrect amount of spaces in its output. This can be overrided by passing -b option to diff (quotation of man page): -b --ignore-space-change Ignore changes in the amount of white space. Since there is currently no mechanism to pass any option to diff I suggest following mechanism: Every test can have its config file ($sef.config) where all its test-run configuration can be stored. Also it should contain variable CONFIG_OPTIONS that specifies what options are created/modified. The check script'll only source the config file if it exists and unset all the modified variables that are listed in CONFIG_OPTIONS variable once they're not needed. This configuration mechanism could (with additional patch to the file check) also help handle multiple output files that might be beneficial in few test cases. Patch that fixes test case 108 and adds described mechanism of test configuration: diff -urpN a/xfstests/108.config b/xfstests/108.config --- a/xfstests/108.config 1970-01-01 01:00:00.000000000 +0100 +++ b/xfstests/108.config 2010-12-09 11:24:51.626367533 +0100 @@ -0,0 +1,2 @@ +export CONFIG_OPTIONS="DIFF_OPTIONS CONFIG_OPTIONS" +export DIFF_OPTIONS="-b" diff -urpN a/xfstests/check b/xfstests/check --- a/xfstests/check 2010-12-09 11:34:26.709247611 +0100 +++ b/xfstests/check 2010-12-09 11:37:13.857370558 +0100 @@ -226,6 +226,11 @@ do else # really going to try and run this one # + CONFIG_OPTIONS="CONFIG_OPTIONS" + if [ -f $seq.config ] + then + source $seq.config + fi rm -f $seq.out.bad lasttime=`sed -n -e "/^$seq /s/.* //p" /dev/null 2>&1 + if diff $DIFF_OPTIONS $seq.out $tmp.out >/dev/null 2>&1 then if $err then @@ -286,12 +291,12 @@ do else echo " - output mismatch (see $seq.out.bad)" mv $tmp.out $seq.out.bad - $diff $seq.out $seq.out.bad + $diff $DIFF_OPTIONS $seq.out $seq.out.bad err=true fi fi fi - + unset $CONFIG_OPTIONS fi # come here for each test, except when $showme is true Signed-off-by: Boris Ranto From sandeen@sandeen.net Thu Dec 9 08:55:03 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_42 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB9Et1RR020314 for ; Thu, 9 Dec 2010 08:55:03 -0600 X-ASG-Debug-ID: 1291906609-6ac603010000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 56E221E97C4F for ; Thu, 9 Dec 2010 06:56:49 -0800 (PST) Received: from mail.sandeen.net (64-131-28-21.usfamily.net [64.131.28.21]) by cuda.sgi.com with ESMTP id q0SbsOPDLLkNEB4r for ; Thu, 09 Dec 2010 06:56:49 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sandeen.net (Postfix) with ESMTP id D4DB44817CFA; Thu, 9 Dec 2010 08:56:48 -0600 (CST) Message-ID: <4D00EE30.2000408@sandeen.net> Date: Thu, 09 Dec 2010 08:56:48 -0600 From: Eric Sandeen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: blacknred CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: kernel panic-xfs errors Subject: Re: kernel panic-xfs errors References: <30397503.post@talk.nabble.com> <20101207222558.GC29333@dastard> <30403823.post@talk.nabble.com> <20101209005944.GD32766@dastard> <4D005E99.2030400@sandeen.net> <30416394.post@talk.nabble.com> In-Reply-To: <30416394.post@talk.nabble.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: 64-131-28-21.usfamily.net[64.131.28.21] X-Barracuda-Start-Time: 1291906610 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC5_SA210e, RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48932 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS 0.00 BSF_SC5_SA210e Custom Rule SA210e X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 12/9/10 7:17 AM, blacknred wrote: > >> which is NOT a rhel 5.0 kernel, and it says x86_64. >> But the addresses are all 32 bits? > > My apologies there, somehow it all got jumbled up, pasting it again: > > BUG: unable to handle kernel NULL pointer dereference at virtual address > 00000098 > printing eip: > *pde = 2c621001 > Oops: 0000 [#1] > SMP > CPU: 2 > EIP: 0060:[] Tainted: GF VLI > EFLAGS: 00010282 (2.6.18-164.11.1.el5PAE #1) > EIP is at do_page_fault+0x205/0x607 > eax: ec6de000 ebx: 00000000 ecx: ec6de074 edx: 0000000d > esi: 00014005 edi: ec6de0a4 ebp: 00000014 esp: ec6de054 > ds: 007b es: 007b ss: 0068 > Process bm (pid: 2910, ti=ec6dd000 task=ec6e3550 task.ti=ec6dd000) > Stack: 00000000 00000000 ec6de0a4 00000014 00000098 f7180000 00000001 > 00000000 > ec6de0a4 c0639439 00000000 0000000e 0000000b 00000000 00000000 > 00000000 > 00014005 c0619b9c 00000014 c0405a89 00000000 ec6de0f8 0000000d > 00014005 ok, same task.ti and esp though, so same massive stack overflow. Is this really RHEL, or CentOS? RHEL doesn't ship xfs for i386, and using the xfs-kmod is a very unsupported/unmaintained solution. If it is "real RHEL" you could try requesting actual i386 support, but these stack issues are one of the reasons it's unlikely. CentOS would do well to ship the same xfs code as is in the x86_64 kernel and drop the kmod-xfs altogether. Some stack issues have been resolved since then, but probably not as much as we see here. I also am suspicious of whatever "moddw_ioctl" is in mod_dw; I assume that's the proprietary kernel module. It may have a really bad stack footprint, although the callchain below looks bad enough. What does: # objdump -d /path/to/mod_dw.ko | grep -A30 ":" | grep sub say? -Eric From john@stoffel.org Thu Dec 9 09:04:25 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB9F4PR0022071 for ; Thu, 9 Dec 2010 09:04:25 -0600 X-ASG-Debug-ID: 1291907172-64ae02530000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mycroft.westnet.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DA9031D8BD5; Thu, 9 Dec 2010 07:06:12 -0800 (PST) Received: from mycroft.westnet.com (Mycroft.westnet.com [216.187.52.7]) by cuda.sgi.com with ESMTP id X7cj7RLCOjsrRgTN; Thu, 09 Dec 2010 07:06:12 -0800 (PST) Received: from jfsnew.stoffel.org (97-95-180-151.dhcp.oxfr.ma.charter.com [97.95.180.151]) (authenticated bits=0) by mycroft.westnet.com (8.14.4/8.14.4) with ESMTP id oB9F5Dxn022512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Dec 2010 10:05:14 -0500 (EST) Received: by jfsnew.stoffel.org (Postfix, from userid 1000) id 5EA90A073D; Thu, 9 Dec 2010 10:05:47 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19712.61515.201226.938553@quad.stoffel.home> Date: Thu, 9 Dec 2010 10:05:47 -0500 From: "John Stoffel" To: Eric Paris Cc: xfs-masters@oss.sgi.com, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, cluster-devel@redhat.com, linux-mtd@lists.infradead.org, jfs-discussion@lists.sourceforge.net, ocfs2-devel@oss.oracle.com, reiserfs-devel@vger.kernel.org, xfs@oss.sgi.com, linux-mm@kvack.org, linux-security-module@vger.kernel.org, chris.mason@oracle.com, jack@suse.cz, akpm@linux-foundation.org, adilger.kernel@dilger.ca, tytso@mit.edu, swhiteho@redhat.com, dwmw2@infradead.org, shaggy@linux.vnet.ibm.com, mfasheh@suse.com, joel.becker@oracle.com, aelder@sgi.com, hughd@google.com, jmorris@namei.org, sds@tycho.nsa.gov, eparis@parisplace.org, hch@lst.de, dchinner@redhat.com, viro@zeniv.linux.org.uk, tao.ma@oracle.com, shemminger@vyatta.com, jeffm@suse.com, serue@us.ibm.com, paul.moore@hp.com, penguin-kernel@I-love.SAKURA.ne.jp, casey@schaufler-ca.com, kees.cook@canonical.com, dhowells@redhat.com X-ASG-Orig-Subj: Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation Subject: Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation In-Reply-To: <20101208194527.13537.77202.stgit@paris.rdu.redhat.com> References: <20101208194527.13537.77202.stgit@paris.rdu.redhat.com> X-Mailer: VM 8.1.1 under 23.2.1 (x86_64-pc-linux-gnu) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Scanned: clamav-milter 0.96.5 at mycroft X-Virus-Status: Clean X-Barracuda-Connect: Mycroft.westnet.com[216.187.52.7] X-Barracuda-Start-Time: 1291907173 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48932 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- >>>>> "Eric" == Eric Paris writes: Eric> SELinux would like to implement a new labeling behavior of newly Eric> created inodes. We currently label new inodes based on the Eric> parent and the creating process. This new behavior would also Eric> take into account the name of the new object when deciding the Eric> new label. This is not the (supposed) full path, just the last Eric> component of the path. Eric> This is very useful because creating /etc/shadow is different Eric> than creating /etc/passwd but the kernel hooks are unable to Eric> differentiate these operations. We currently require that Eric> userspace realize it is doing some difficult operation like that Eric> and than userspace jumps through SELinux hoops to get things set Eric> up correctly. This patch does not implement new behavior, that Eric> is obviously contained in a seperate SELinux patch, but it does Eric> pass the needed name down to the correct LSM hook. If no such Eric> name exists it is fine to pass NULL. I've looked this patch over, and maybe I'm missing something, but how does knowing the name of the file really tell you anything, esp when you only get the filename, not the path? What threat are you addressing with this change? So what happens when I create a file /home/john/shadow, does selinux (or LSM in general) then run extra checks because the filename is 'shadow' in your model? I *think* the overhead shouldn't be there if SELINUX is disabled, but have you confirmed this? How you run performance tests before/after this change when doing lots of creations of inodes to see what sort of performance changes might be there? Thanks, John From yad.naveen@gmail.com Thu Dec 9 09:30:29 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, T_DKIM_INVALID,T_TO_NO_BRKTS_FREEMAIL autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB9FUTnH026129 for ; Thu, 9 Dec 2010 09:30:29 -0600 X-ASG-Debug-ID: 1291908737-239602170000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail-vw0-f53.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 52C5C1435C5F for ; Thu, 9 Dec 2010 07:32:17 -0800 (PST) Received: from mail-vw0-f53.google.com (mail-vw0-f53.google.com [209.85.212.53]) by cuda.sgi.com with ESMTP id fWaDZ5Q7aCWz3IPL for ; Thu, 09 Dec 2010 07:32:17 -0800 (PST) Received: by vws8 with SMTP id 8so1723779vws.26 for ; Thu, 09 Dec 2010 07:32:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=kc0vkT6SAqI5zUUcidzQwdq4GtCatsuUKBMZ97Krq18=; b=Il8D8135kn2m3ux+uJFonJCjTd9HawYAJRY4Scv1+LNRbpWk6tpJNrCngSSZNKHg65 0ho2tRN3vgcCvw2KDo6GQPyD6wMcquUkvA/49Mhx8VwdtKSZdTqbOzjCHsFEAl+qcmSh fgTAX+7VuPG+mfkqyf47kl7L+Yw1TOWYahp2I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=Fpi7tlVX0EsMdivCm7UWpqTfnIudnPX6DcjUGMolBY2y5RO9BxduuUWSl7K/s8seRt 4FSmNMo+TN7ZxvO5X/8CivSfICGvjmqsrSdMEFRwtVjkD/Og8xDJ1hOZmiy9PXr3wTmX ZKCAO+kh8MFuvfuxuvaZPTT9Q5t+M70YsBdfo= MIME-Version: 1.0 Received: by 10.229.246.83 with SMTP id lx19mr3179304qcb.210.1291908736123; Thu, 09 Dec 2010 07:32:16 -0800 (PST) Received: by 10.229.75.13 with HTTP; Thu, 9 Dec 2010 07:32:15 -0800 (PST) Date: Thu, 9 Dec 2010 21:02:15 +0530 Message-ID: X-ASG-Orig-Subj: XFS Testsuite Subject: XFS Testsuite From: naveen yadav To: xfs@oss.sgi.com Content-Type: text/plain; charset=ISO-8859-1 X-Barracuda-Connect: mail-vw0-f53.google.com[209.85.212.53] X-Barracuda-Start-Time: 1291908738 X-Barracuda-Bayes: INNOCENT GLOBAL 0.2213 1.0000 -0.7176 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.72 X-Barracuda-Spam-Status: No, SCORE=-0.72 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=DKIM_SIGNED, DKIM_VERIFIED X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48933 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- -0.00 DKIM_VERIFIED Domain Keys Identified Mail: signature passes verification 0.00 DKIM_SIGNED Domain Keys Identified Mail: message has a signature X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hi all, I want to setup XFS testsuite for my embedded ARM Target, Is it possible ? If any body have already done, Please help me. I am trying but there are lots of constrain and problem Thanks From eparis@redhat.com Thu Dec 9 09:52:51 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB9FqpMs029997 for ; Thu, 9 Dec 2010 09:52:51 -0600 X-ASG-Debug-ID: 1291910079-17da03a50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 73DFA14343F3; Thu, 9 Dec 2010 07:54:39 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id oPNSgEVerTZ5EQgE; Thu, 09 Dec 2010 07:54:39 -0800 (PST) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oB9FqVs9030130 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Dec 2010 10:52:31 -0500 Received: from [10.11.231.139] (dhcp231-139.rdu.redhat.com [10.11.231.139]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id oB9FqMN9030453; Thu, 9 Dec 2010 10:52:22 -0500 X-ASG-Orig-Subj: Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation Subject: Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation From: Eric Paris To: John Stoffel Cc: xfs-masters@oss.sgi.com, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, cluster-devel@redhat.com, linux-mtd@lists.infradead.org, jfs-discussion@lists.sourceforge.net, ocfs2-devel@oss.oracle.com, reiserfs-devel@vger.kernel.org, xfs@oss.sgi.com, linux-mm@kvack.org, linux-security-module@vger.kernel.org, chris.mason@oracle.com, jack@suse.cz, akpm@linux-foundation.org, adilger.kernel@dilger.ca, tytso@mit.edu, swhiteho@redhat.com, dwmw2@infradead.org, shaggy@linux.vnet.ibm.com, mfasheh@suse.com, joel.becker@oracle.com, aelder@sgi.com, hughd@google.com, jmorris@namei.org, sds@tycho.nsa.gov, eparis@parisplace.org, hch@lst.de, dchinner@redhat.com, viro@zeniv.linux.org.uk, tao.ma@oracle.com, shemminger@vyatta.com, jeffm@suse.com, paul.moore@hp.com, penguin-kernel@I-love.SAKURA.ne.jp, casey@schaufler-ca.com, kees.cook@canonical.com, dhowells@redhat.com In-Reply-To: <19712.61515.201226.938553@quad.stoffel.home> References: <20101208194527.13537.77202.stgit@paris.rdu.redhat.com> <19712.61515.201226.938553@quad.stoffel.home> Content-Type: text/plain; charset="UTF-8" Date: Thu, 09 Dec 2010 10:52:21 -0500 Message-ID: <1291909941.3072.70.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1291910080 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, 2010-12-09 at 10:05 -0500, John Stoffel wrote: > >>>>> "Eric" == Eric Paris writes: > So what happens when I create a file /home/john/shadow, does selinux > (or LSM in general) then run extra checks because the filename is > 'shadow' in your model? It's entirely a question of labeling and one that was discussed on the LSM list in some detail: http://marc.info/?t=129141308200002&r=1&w=2 The basic synopsis is that when a new inode is created SELinux must apply some label. It makes the decision for what label to apply based on 3 pieces of information. The label of the parent inode. The label of the process creating the new inode. The 'class' of the inode, S_ISREG, S_ISDIR, S_ISLNK, etc This patch adds a 4th piece of information, the name of the object being created. An obvious situation where this will be useful is devtmpfs (although you'll find other examples in the above thread). devtmpfs when it creates char/block devices is unable to distinguish between kmem and console and so they are created with a generic label. hotplug/udev is then called which does some pathname like matching and relabels them to something more specific. We've found that many people are able to race against this particular updating and get spurious denials in /dev. With this patch devtmpfs will be able to get the labels correct to begin with. I'm certainly willing to discuss the security implications of this patch, but that would probably be best done with a significantly shortened cc-list. You'll see in the above mentioned thread that a number of 'security' people (even those who are staunchly anti-SELinux) recognize there is value in this and that it is certainly much better than we have today. > I *think* the overhead shouldn't be there if SELINUX is disabled, but > have you confirmed this? How you run performance tests before/after > this change when doing lots of creations of inodes to see what sort of > performance changes might be there? I've actually recently done some perf testing on creating large numbers of inodes using bonnie++, since SELinux was a noticeable overhead in that operation. Doing that same test with SELinux disabled (or enabled) I do not see a noticeable difference when this patch is applied or not. It's just an extra argument to a function that goes unused. -Eric From serge.hallyn@canonical.com Thu Dec 9 10:04:32 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB9G4Wap032174 for ; Thu, 9 Dec 2010 10:04:32 -0600 X-ASG-Debug-ID: 1291910780-4f0f004f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from adelie.canonical.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 168E51D8F0E; Thu, 9 Dec 2010 08:06:20 -0800 (PST) Received: from adelie.canonical.com (adelie.canonical.com [91.189.90.139]) by cuda.sgi.com with ESMTP id orYmieJYxgitvNBy; Thu, 09 Dec 2010 08:06:20 -0800 (PST) Received: from hutte.canonical.com ([91.189.90.181]) by adelie.canonical.com with esmtp (Exim 4.69 #1 (Debian)) id 1PQj0K-0003ei-O3; Thu, 09 Dec 2010 16:06:02 +0000 Received: from [64.202.139.114] (helo=peq) by hutte.canonical.com with esmtpsa (TLS-1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.69) (envelope-from ) id 1PQj0J-0006Ab-KJ; Thu, 09 Dec 2010 16:06:00 +0000 Date: Thu, 9 Dec 2010 10:05:49 -0600 From: Serge Hallyn To: John Stoffel Cc: Eric Paris , xfs-masters@oss.sgi.com, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, cluster-devel@redhat.com, linux-mtd@lists.infradead.org, jfs-discussion@lists.sourceforge.net, ocfs2-devel@oss.oracle.com, reiserfs-devel@vger.kernel.org, xfs@oss.sgi.com, linux-mm@kvack.org, linux-security-module@vger.kernel.org, chris.mason@oracle.com, jack@suse.cz, akpm@linux-foundation.org, adilger.kernel@dilger.ca, tytso@mit.edu, swhiteho@redhat.com, dwmw2@infradead.org, shaggy@linux.vnet.ibm.com, mfasheh@suse.com, joel.becker@oracle.com, aelder@sgi.com, hughd@google.com, jmorris@namei.org, sds@tycho.nsa.gov, eparis@parisplace.org, hch@lst.de, dchinner@redhat.com, viro@zeniv.linux.org.uk, tao.ma@oracle.com, shemminger@vyatta.com, jeffm@suse.com, serue@us.ibm.com, paul.moore@hp.com, penguin-kernel@I-love.SAKURA.ne.jp, casey@schaufler-ca.com, kees.cook@canonical.com, dhowells@redhat.com X-ASG-Orig-Subj: Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation Subject: Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation Message-ID: <20101209160549.GA2315@peq> References: <20101208194527.13537.77202.stgit@paris.rdu.redhat.com> <19712.61515.201226.938553@quad.stoffel.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19712.61515.201226.938553@quad.stoffel.home> User-Agent: Mutt/1.5.20 (2009-06-14) X-Barracuda-Connect: adelie.canonical.com[91.189.90.139] X-Barracuda-Start-Time: 1291910781 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48936 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Quoting John Stoffel (john@stoffel.org): > >>>>> "Eric" == Eric Paris writes: > > Eric> SELinux would like to implement a new labeling behavior of newly > Eric> created inodes. We currently label new inodes based on the > Eric> parent and the creating process. This new behavior would also > Eric> take into account the name of the new object when deciding the > Eric> new label. This is not the (supposed) full path, just the last > Eric> component of the path. > > Eric> This is very useful because creating /etc/shadow is different > Eric> than creating /etc/passwd but the kernel hooks are unable to > Eric> differentiate these operations. We currently require that > Eric> userspace realize it is doing some difficult operation like that > Eric> and than userspace jumps through SELinux hoops to get things set > Eric> up correctly. This patch does not implement new behavior, that > Eric> is obviously contained in a seperate SELinux patch, but it does > Eric> pass the needed name down to the correct LSM hook. If no such > Eric> name exists it is fine to pass NULL. > > I've looked this patch over, and maybe I'm missing something, but how > does knowing the name of the file really tell you anything, esp when > you only get the filename, not the path? What threat are you > addressing with this change? Like you, I keep thinking back to this patch and going back and forth. But to answer your question: in some cases, the name of the file (plus the context of the directory in which it is created) can tell you what assumptions userspace will make about it. And userspace most definately is a part of the TCB, i.e. /bin/passwd and /bin/login. -serge From sandeen@sandeen.net Thu Dec 9 11:46:30 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB9HkT6B047431 for ; Thu, 9 Dec 2010 11:46:30 -0600 X-ASG-Debug-ID: 1291916897-37af011c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A1BFB1436751 for ; Thu, 9 Dec 2010 09:48:17 -0800 (PST) Received: from mail.sandeen.net (64-131-28-21.usfamily.net [64.131.28.21]) by cuda.sgi.com with ESMTP id 4aMMzKCZLFqLJCFS for ; Thu, 09 Dec 2010 09:48:17 -0800 (PST) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sandeen.net (Postfix) with ESMTP id 067C848E8B05; Thu, 9 Dec 2010 11:48:17 -0600 (CST) Message-ID: <4D011660.200@sandeen.net> Date: Thu, 09 Dec 2010 11:48:16 -0600 From: Eric Sandeen User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: naveen yadav CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS Testsuite Subject: Re: XFS Testsuite References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: 64-131-28-21.usfamily.net[64.131.28.21] X-Barracuda-Start-Time: 1291916898 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0209 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_DYNAMIC X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48943 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_DYNAMIC Delivered to trusted network by host with dynamic-looking rDNS X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On 12/9/10 9:32 AM, naveen yadav wrote: > Hi all, > > I want to setup XFS testsuite for my embedded ARM Target, Is it possible ? > If any body have already done, Please help me. I am trying but there > are lots of constrain and problem It certainly is possible, and a very good idea - what problems have you encountered? I assume you've started with the README instructions? -Eric > Thanks > > _______________________________________________ > xfs mailing list > xfs@oss.sgi.com > http://oss.sgi.com/mailman/listinfo/xfs > From john@stoffel.org Thu Dec 9 11:46:56 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB9HkuGE047533 for ; Thu, 9 Dec 2010 11:46:56 -0600 X-ASG-Debug-ID: 1291916925-2a6c006b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mycroft.westnet.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0440C1D9DF8; Thu, 9 Dec 2010 09:48:45 -0800 (PST) Received: from mycroft.westnet.com (Mycroft.westnet.com [216.187.52.7]) by cuda.sgi.com with ESMTP id nZsGgoIhxfISrETN; Thu, 09 Dec 2010 09:48:45 -0800 (PST) Received: from jfsnew.stoffel.org (97-95-180-151.dhcp.oxfr.ma.charter.com [97.95.180.151]) (authenticated bits=0) by mycroft.westnet.com (8.14.4/8.14.4) with ESMTP id oB9HlruS002884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 9 Dec 2010 12:47:53 -0500 (EST) Received: by jfsnew.stoffel.org (Postfix, from userid 1000) id D3637A073F; Thu, 9 Dec 2010 12:48:26 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19713.5738.653711.301814@quad.stoffel.home> Date: Thu, 9 Dec 2010 12:48:26 -0500 From: "John Stoffel" To: Eric Paris Cc: John Stoffel , xfs-masters@oss.sgi.com, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, cluster-devel@redhat.com, linux-mtd@lists.infradead.org, jfs-discussion@lists.sourceforge.net, ocfs2-devel@oss.oracle.com, reiserfs-devel@vger.kernel.org, xfs@oss.sgi.com, linux-mm@kvack.org, linux-security-module@vger.kernel.org, chris.mason@oracle.com, jack@suse.cz, akpm@linux-foundation.org, adilger.kernel@dilger.ca, tytso@mit.edu, swhiteho@redhat.com, dwmw2@infradead.org, shaggy@linux.vnet.ibm.com, mfasheh@suse.com, joel.becker@oracle.com, aelder@sgi.com, hughd@google.com, jmorris@namei.org, sds@tycho.nsa.gov, eparis@parisplace.org, hch@lst.de, dchinner@redhat.com, viro@zeniv.linux.org.uk, tao.ma@oracle.com, shemminger@vyatta.com, jeffm@suse.com, paul.moore@hp.com, penguin-kernel@I-love.SAKURA.ne.jp, casey@schaufler-ca.com, kees.cook@canonical.com, dhowells@redhat.com X-ASG-Orig-Subj: Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation Subject: Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation In-Reply-To: <1291909941.3072.70.camel@localhost.localdomain> References: <20101208194527.13537.77202.stgit@paris.rdu.redhat.com> <19712.61515.201226.938553@quad.stoffel.home> <1291909941.3072.70.camel@localhost.localdomain> X-Mailer: VM 8.1.1 under 23.2.1 (x86_64-pc-linux-gnu) X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Scanned: clamav-milter 0.96.5 at mycroft X-Virus-Status: Clean X-Barracuda-Connect: Mycroft.westnet.com[216.187.52.7] X-Barracuda-Start-Time: 1291916926 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-ASG-Whitelist: BODY (http://marc\.info/\?) >>>>> "Eric" == Eric Paris writes: Eric> On Thu, 2010-12-09 at 10:05 -0500, John Stoffel wrote: >> >>>>> "Eric" == Eric Paris writes: >> So what happens when I create a file /home/john/shadow, does selinux >> (or LSM in general) then run extra checks because the filename is >> 'shadow' in your model? Eric> It's entirely a question of labeling and one that was discussed on the Eric> LSM list in some detail: Eric> http://marc.info/?t=129141308200002&r=1&w=2 Thank you for pointing me at this discussion. I'm working my way through it, but so far I'm not seeing any consensus that this is really the proper thing to do. I personally feel this should be in userspace if at all possible. Eric> The basic synopsis is that when a new inode is created SELinux Eric> must apply some label. It makes the decision for what label to Eric> apply based on 3 pieces of information. Eric> The label of the parent inode. Eric> The label of the process creating the new inode. Eric> The 'class' of the inode, S_ISREG, S_ISDIR, S_ISLNK, etc These seem to be ok, if you're using label based security. But since I freely admit I'm not an expert or even a user, I'm just trying to understand and push back to make sure we do what's good. And which doesn't impact non-SElinux users. Eric> This patch adds a 4th piece of information, the name of the Eric> object being created. An obvious situation where this will be Eric> useful is devtmpfs (although you'll find other examples in the Eric> above thread). devtmpfs when it creates char/block devices is Eric> unable to distinguish between kmem and console and so they are Eric> created with a generic label. hotplug/udev is then called which Eric> does some pathname like matching and relabels them to something Eric> more specific. We've found that many people are able to race Eric> against this particular updating and get spurious denials in Eric> /dev. With this patch devtmpfs will be able to get the labels Eric> correct to begin with. So your Label based access controls are *also* based on pathnames? Right? Eric> I'm certainly willing to discuss the security implications of this Eric> patch, but that would probably be best done with a significantly Eric> shortened cc-list. You'll see in the above mentioned thread that a Eric> number of 'security' people (even those who are staunchly anti-SELinux) Eric> recognize there is value in this and that it is certainly much better Eric> than we have today. >> I *think* the overhead shouldn't be there if SELINUX is disabled, but >> have you confirmed this? How you run performance tests before/after >> this change when doing lots of creations of inodes to see what sort of >> performance changes might be there? Eric> I've actually recently done some perf testing on creating large Eric> numbers of inodes using bonnie++, since SELinux was a noticeable Eric> overhead in that operation. Doing that same test with SELinux Eric> disabled (or enabled) I do not see a noticeable difference when Eric> this patch is applied or not. It's just an extra argument to a Eric> function that goes unused. That answers alot of my concerns then. Not having it impact users in a non-SELinux context is vitally important to me. Thanks, John From eparis@redhat.com Thu Dec 9 12:05:54 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB9I5sgW050863 for ; Thu, 9 Dec 2010 12:05:54 -0600 X-ASG-Debug-ID: 1291918062-5b3e01440000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4FA901CAA578; Thu, 9 Dec 2010 10:07:42 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id fkhXafT85bMVo6Dy; Thu, 09 Dec 2010 10:07:42 -0800 (PST) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oB9I5Ttk031827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Dec 2010 13:05:29 -0500 Received: from [10.11.231.139] (dhcp231-139.rdu.redhat.com [10.11.231.139]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id oB9I5LfX014858; Thu, 9 Dec 2010 13:05:21 -0500 X-ASG-Orig-Subj: Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation Subject: Re: [PATCH] fs/vfs/security: pass last path component to LSM on inode creation From: Eric Paris To: John Stoffel Cc: xfs-masters@oss.sgi.com, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org, cluster-devel@redhat.com, linux-mtd@lists.infradead.org, jfs-discussion@lists.sourceforge.net, ocfs2-devel@oss.oracle.com, reiserfs-devel@vger.kernel.org, xfs@oss.sgi.com, linux-mm@kvack.org, linux-security-module@vger.kernel.org, chris.mason@oracle.com, jack@suse.cz, akpm@linux-foundation.org, adilger.kernel@dilger.ca, tytso@mit.edu, swhiteho@redhat.com, dwmw2@infradead.org, shaggy@linux.vnet.ibm.com, mfasheh@suse.com, joel.becker@oracle.com, aelder@sgi.com, hughd@google.com, jmorris@namei.org, sds@tycho.nsa.gov, eparis@parisplace.org, hch@lst.de, dchinner@redhat.com, viro@zeniv.linux.org.uk, shemminger@vyatta.com, jeffm@suse.com, paul.moore@hp.com, penguin-kernel@I-love.SAKURA.ne.jp, casey@schaufler-ca.com, kees.cook@canonical.com, dhowells@redhat.com In-Reply-To: <19713.5738.653711.301814@quad.stoffel.home> References: <20101208194527.13537.77202.stgit@paris.rdu.redhat.com> <19712.61515.201226.938553@quad.stoffel.home> <1291909941.3072.70.camel@localhost.localdomain> <19713.5738.653711.301814@quad.stoffel.home> Content-Type: text/plain; charset="UTF-8" Date: Thu, 09 Dec 2010 13:05:21 -0500 Message-ID: <1291917921.12683.4.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1291918063 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, 2010-12-09 at 12:48 -0500, John Stoffel wrote: > >>>>> "Eric" == Eric Paris writes: > > Eric> On Thu, 2010-12-09 at 10:05 -0500, John Stoffel wrote: > >> >>>>> "Eric" == Eric Paris writes: > > Eric> This patch adds a 4th piece of information, the name of the > Eric> object being created. An obvious situation where this will be > Eric> useful is devtmpfs (although you'll find other examples in the > Eric> above thread). devtmpfs when it creates char/block devices is > Eric> unable to distinguish between kmem and console and so they are > Eric> created with a generic label. hotplug/udev is then called which > Eric> does some pathname like matching and relabels them to something > Eric> more specific. We've found that many people are able to race > Eric> against this particular updating and get spurious denials in > Eric> /dev. With this patch devtmpfs will be able to get the labels > Eric> correct to begin with. > > So your Label based access controls are *also* based on pathnames? > Right? Access decisions are still based solely on the label. This patch can influence how new objects get their label, which makes the access decisions indirectly path based. You'll find a reasonable summary and commentary on lwn in this weeks security section. From aelder@sgi.com Thu Dec 9 15:17:54 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from relay.sgi.com (relay2.corp.sgi.com [137.38.102.29]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB9LHstr082640 for ; Thu, 9 Dec 2010 15:17:54 -0600 Received: from cf--amer001e--3.americas.sgi.com (cf--amer001e--3.americas.sgi.com [137.38.100.5]) by relay2.corp.sgi.com (Postfix) with ESMTP id 6031D30407A; Thu, 9 Dec 2010 13:19:41 -0800 (PST) Received: from [127.0.0.1] ([198.149.20.12]) by cf--amer001e--3.americas.sgi.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Dec 2010 15:19:41 -0600 Subject: Re: [PATCH] xfstests: fix 108 golden output From: Alex Elder Reply-To: aelder@sgi.com To: Christoph Hellwig Cc: xfs@oss.sgi.com, branto@redhat.com In-Reply-To: <20101110125855.GA18357@infradead.org> References: <20101110125855.GA18357@infradead.org> Content-Type: text/plain; charset="UTF-8" Date: Thu, 09 Dec 2010 15:19:39 -0600 Message-ID: <1291929579.13355.30.camel@doink> Mime-Version: 1.0 X-Mailer: Evolution 2.30.3 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Dec 2010 21:19:41.0215 (UTC) FILETIME=[CAE022F0:01CB97E6] X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Wed, 2010-11-10 at 07:58 -0500, Christoph Hellwig wrote: > The new common scratch mount filter produces slightly different > whitespaces than the old home grown filter, so adjust the golden > output. > > Signed-off-by: Christoph Hellwig I found out why this is happening. I get no such error, and Dave Chinner said he wasn't seeing it either. xfs_quota is formatting its output such that the second and later columns always align at a certain offset from the beginning of the line. As a result, path names assigned as SCRATCH_DEV of different lengths will produce different (filtered) output, with more or fewer blanks between SCRATCH_DEV and the usage number. Boris Ranto has proposed a change that would add the "-b" flag to diff when checking output against golden output. That should fix it, but it's possible we *want* differences in white space to matter in some cases. Have to look into this. -Alex From Natashal19@terra.com Thu Dec 9 17:37:14 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: * X-Spam-Status: No, score=2.0 required=5.0 tests=BAYES_50,FREEMAIL_FROM, FREEMAIL_REPLYTO_END_DIGIT autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oB9NbDgP106574 for ; Thu, 9 Dec 2010 17:37:14 -0600 X-ASG-Debug-ID: 1291937940-484c02fc0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from if00-mail-fb03-mia.mta.terra.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 950351437D92 for ; Thu, 9 Dec 2010 15:39:00 -0800 (PST) Received: from if00-mail-fb03-mia.mta.terra.com (if00-mail-fb03-mia.mta.terra.com [208.84.243.137]) by cuda.sgi.com with ESMTP id TcOqWcfJlyMXLhsZ for ; Thu, 09 Dec 2010 15:39:00 -0800 (PST) Received: from midland.terra.com (midland.tpn.terra.com [10.235.200.8]) by mail-fb03-mia.tpn.terra.com (Postfix) with ESMTP id E92A420061948 for ; Thu, 9 Dec 2010 23:38:59 +0000 (UTC) X-Terra-Karma: 0% X-Terra-Hash: 430f18e1c27bb7f65046f499c10b12a6 Received-SPF: pass (midland.terra.com: domain of terra.com designates 208.84.242.62 as permitted sender) client-ip=208.84.242.62; envelope-from=Natashal19@terra.com; helo=192.168.0.61; Received: from 192.168.0.61 (unknown [112.201.180.129]) (authenticated user Natashal19@terra.com) by midland.terra.com (Postfix) with ESMTPA id D0286280000BD for ; Thu, 9 Dec 2010 23:38:58 +0000 (UTC) Date: Thu, 9 Dec 2010 23:39:02 +0000 To: name From: Reply-To: X-ASG-Orig-Subj: I highly recommend this service... Subject: I highly recommend this service... Message-ID: <1670c2cba3c44b78e05d4e07df32fa98@192.168.0.61> X-Priority: 3 X-Mailer: PHPMailer [version 1.72] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="iso-8859-1" X-CLX-Rate-Response: fi=10.235.200.253:2001; rg=B; GT=0; fs=1011; PS=xfs@oss.sgi.com:0; ns=0; id=a123GLF880yS0VH-B92338x; rv=6379/208.84.242.253:14051; ts=ENw0u; fl=I; ip=112.201.180.129; he=JDa5SbeTwlN; ho=Pk32Ts6EzWt; hd=MiyMN+lL6Vc; hf=BF13h35vIwV; hF=G+4YOwgYe68; hj=GeFvTR2LT0F; hr=BFhjH927n/M; ZB=KbC1t8/GAkc; ZB=Mq0XGtSZ79v; ZB=LVpJV8p3w7q; ZB=BKOXUBnr8ru; ZB=KnxIPk5NlnV; ZU=OiqF3SSFNvb; Zu=GhfXyw5Xp8M; X-Barracuda-Connect: if00-mail-fb03-mia.mta.terra.com[208.84.243.137] X-Barracuda-Start-Time: 1291937941 X-Barracuda-Bayes: INNOCENT GLOBAL 0.6524 1.0000 1.0367 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.04 X-Barracuda-Spam-Status: No, SCORE=1.04 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=NO_REAL_NAME X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.2.48967 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 NO_REAL_NAME From: does not include a real name X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Hi, Want to earn 10,000 every month, just working part time from home? Go here fast: http://379aday.Co.CC It's a really cool new work at home recruiting service that will help you start working at home. They say it's only available in select city's, for a limited time, so you should hurry. I highly recommend this service. Go here now: http://379aday.Co.CC To your success, Carolyn Griffith P.S.: Don't delay - this could be gone any second now... ...If you are serious about cashing 6 figures per month affiliates cheques you can't miss this out -- go there NOW: => http://379aday.Co.CC 64 Bridgeport Drive Waynesboro VA 22980 Reply *remove* if you wish to be removed in our system From aelder@oss.sgi.com Thu Dec 9 20:10:25 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oBA2APsT134279 for ; Thu, 9 Dec 2010 20:10:25 -0600 Received: (from aelder@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id oBA2APVN134251; Thu, 9 Dec 2010 20:10:25 -0600 Date: Thu, 9 Dec 2010 20:10:25 -0600 Message-Id: <201012100210.oBA2APVN134251@oss.sgi.com> From: xfs@oss.sgi.com To: xfs@oss.sgi.com Subject: [XFS updates] XFS development tree branch, master, updated. v2.6.37-rc4-6-g05340d4 X-Git-Refname: refs/heads/master X-Git-Reftype: branch X-Git-Oldrev: c76febef574fd86566bbdf1a73a547a439115c25 X-Git-Newrev: 05340d4ab2ec2b6b4962c1c41c6ea8fb550f947b This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "XFS development tree". The branch, master has been updated 05340d4 xfs: log timestamp changes to the source inode in rename from c76febef574fd86566bbdf1a73a547a439115c25 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 05340d4ab2ec2b6b4962c1c41c6ea8fb550f947b Author: Christoph Hellwig Date: Tue Dec 7 10:16:41 2010 +0000 xfs: log timestamp changes to the source inode in rename Now that we don't mark VFS inodes dirty anymore for internal timestamp changes, but rely on the transaction subsystem to push them out, we need to explicitly log the source inode in rename after updating it's timestamps to make sure the changes actually get forced out by sync/fsync or an AIL push. We already account for the fourth inode in the log reservation, as a rename of directories needs to update the nlink field, so just adding the xfs_trans_log_inode call is enough. This fixes the xfsqa 065 regression introduced by: "xfs: don't use vfs writeback for pure metadata modifications" Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner Signed-off-by: Alex Elder ----------------------------------------------------------------------- Summary of changes: fs/xfs/xfs_rename.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) hooks/post-receive -- XFS development tree From aelder@oss.sgi.com Thu Dec 9 20:10:35 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from oss.sgi.com (localhost [127.0.0.1]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oBA2AZbe134402 for ; Thu, 9 Dec 2010 20:10:35 -0600 Received: (from aelder@localhost) by oss.sgi.com (8.14.3/8.14.3/Submit) id oBA2AZbT134375; Thu, 9 Dec 2010 20:10:35 -0600 Date: Thu, 9 Dec 2010 20:10:35 -0600 Message-Id: <201012100210.oBA2AZbT134375@oss.sgi.com> From: xfs@oss.sgi.com To: xfs@oss.sgi.com Subject: [XFS updates] XFS development tree branch, for-linus, updated. v2.6.37-rc4-6-g05340d4 X-Git-Refname: refs/heads/for-linus X-Git-Reftype: branch X-Git-Oldrev: c76febef574fd86566bbdf1a73a547a439115c25 X-Git-Newrev: 05340d4ab2ec2b6b4962c1c41c6ea8fb550f947b This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "XFS development tree". The branch, for-linus has been updated 05340d4 xfs: log timestamp changes to the source inode in rename from c76febef574fd86566bbdf1a73a547a439115c25 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 05340d4ab2ec2b6b4962c1c41c6ea8fb550f947b Author: Christoph Hellwig Date: Tue Dec 7 10:16:41 2010 +0000 xfs: log timestamp changes to the source inode in rename Now that we don't mark VFS inodes dirty anymore for internal timestamp changes, but rely on the transaction subsystem to push them out, we need to explicitly log the source inode in rename after updating it's timestamps to make sure the changes actually get forced out by sync/fsync or an AIL push. We already account for the fourth inode in the log reservation, as a rename of directories needs to update the nlink field, so just adding the xfs_trans_log_inode call is enough. This fixes the xfsqa 065 regression introduced by: "xfs: don't use vfs writeback for pure metadata modifications" Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner Signed-off-by: Alex Elder ----------------------------------------------------------------------- Summary of changes: fs/xfs/xfs_rename.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) hooks/post-receive -- XFS development tree From BATV+870d71e9bf4a5d360c11+2665+infradead.org+hch@bombadil.srs.infradead.org Fri Dec 10 02:41:14 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oBA8fE4q205194 for ; Fri, 10 Dec 2010 02:41:14 -0600 X-ASG-Debug-ID: 1291970583-626f03170000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 06144160F98E for ; Fri, 10 Dec 2010 00:43:03 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id beg1NP4dVCRIg084 for ; Fri, 10 Dec 2010 00:43:03 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PQyZD-0006RQ-Be for xfs@oss.sgi.com; Fri, 10 Dec 2010 08:43:03 +0000 Message-Id: <20101210084303.320837611@bombadil.infradead.org> User-Agent: quilt/0.48-1 Date: Fri, 10 Dec 2010 03:42:24 -0500 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 09/10] xfs: refactor xfs_vm_writepage Subject: [PATCH 09/10] xfs: refactor xfs_vm_writepage References: <20101210084215.259628825@bombadil.infradead.org> Content-Disposition: inline; filename=xfs-factor-writepage X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291970584 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean After the last patches the code for overwrites is the same as for delayed and unwritten extents except that it doesn't need to call xfs_map_at_offset. Take care of that fact to simplify xfs_vm_writepage. The buffer loop now first checks the type of buffer and checks/sets the ioend type, or continues to the next buffer if it's not interesting to us. Only after that we validate the iomap and perform the block mapping if needed, all in common code for the cases where we have to do work. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner Index: xfs/fs/xfs/linux-2.6/xfs_aops.c =================================================================== --- xfs.orig/fs/xfs/linux-2.6/xfs_aops.c 2010-12-09 15:52:12.718004124 +0100 +++ xfs/fs/xfs/linux-2.6/xfs_aops.c 2010-12-09 15:52:23.144273297 +0100 @@ -999,74 +999,55 @@ xfs_vm_writepage( continue; } - if (imap_valid) - imap_valid = xfs_imap_valid(inode, &imap, offset); - - if (buffer_unwritten(bh) || buffer_delay(bh)) { - if (buffer_unwritten(bh)) { - if (type != IO_UNWRITTEN) { - type = IO_UNWRITTEN; - imap_valid = 0; - } - } else if (buffer_delay(bh)) { - if (type != IO_DELALLOC) { - type = IO_DELALLOC; - imap_valid = 0; - } - } - - if (!imap_valid) { - /* - * If we didn't have a valid mapping then we - * need to ensure that we put the new mapping - * in a new ioend structure. This needs to be - * done to ensure that the ioends correctly - * reflect the block mappings at io completion - * for unwritten extent conversion. - */ - new_ioend = 1; - err = xfs_map_blocks(inode, offset, &imap, - type, nonblocking); - if (err) - goto error; - imap_valid = xfs_imap_valid(inode, &imap, - offset); + if (buffer_unwritten(bh)) { + if (type != IO_UNWRITTEN) { + type = IO_UNWRITTEN; + imap_valid = 0; } - if (imap_valid) { - xfs_map_at_offset(inode, bh, &imap, offset); - xfs_add_to_ioend(inode, bh, offset, type, - &ioend, new_ioend); - count++; + } else if (buffer_delay(bh)) { + if (type != IO_DELALLOC) { + type = IO_DELALLOC; + imap_valid = 0; } } else if (buffer_uptodate(bh)) { - /* - * we got here because the buffer is already mapped. - * That means it must already have extents allocated - * underneath it. Map the extent by reading it. - */ if (type != IO_OVERWRITE) { type = IO_OVERWRITE; imap_valid = 0; } - if (!imap_valid) { - new_ioend = 1; - err = xfs_map_blocks(inode, offset, - &imap, type, nonblocking); - if (err) - goto error; - imap_valid = xfs_imap_valid(inode, &imap, - offset); + } else { + if (PageUptodate(page)) { + ASSERT(buffer_mapped(bh)); + imap_valid = 0; } + continue; + } - if (imap_valid) { + if (imap_valid) + imap_valid = xfs_imap_valid(inode, &imap, offset); + if (!imap_valid) { + /* + * If we didn't have a valid mapping then we need to + * put the new mapping into a separate ioend structure. + * This ensures non-contiguous extents always have + * separate ioends, which is particularly important + * for unwritten extent conversion at I/O completion + * time. + */ + new_ioend = 1; + err = xfs_map_blocks(inode, offset, &imap, type, + nonblocking); + if (err) + goto error; + imap_valid = xfs_imap_valid(inode, &imap, offset); + } + if (imap_valid) { + if (type == IO_OVERWRITE) lock_buffer(bh); - xfs_add_to_ioend(inode, bh, offset, type, - &ioend, new_ioend); - count++; - } - } else if (PageUptodate(page)) { - ASSERT(buffer_mapped(bh)); - imap_valid = 0; + else + xfs_map_at_offset(inode, bh, &imap, offset); + xfs_add_to_ioend(inode, bh, offset, type, &ioend, + new_ioend); + count++; } if (!iohead) From BATV+870d71e9bf4a5d360c11+2665+infradead.org+hch@bombadil.srs.infradead.org Fri Dec 10 02:41:14 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_35, LOCAL_GNU_PATCH autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oBA8fDLU205184 for ; Fri, 10 Dec 2010 02:41:14 -0600 X-ASG-Debug-ID: 1291970583-626b03820000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8AF65160F98F for ; Fri, 10 Dec 2010 00:43:03 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id Zb2agampurAibyfE for ; Fri, 10 Dec 2010 00:43:03 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PQyZC-0006QO-Tc for xfs@oss.sgi.com; Fri, 10 Dec 2010 08:43:02 +0000 Message-Id: <20101210084302.878788913@bombadil.infradead.org> User-Agent: quilt/0.48-1 Date: Fri, 10 Dec 2010 03:42:22 -0500 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 07/10] xfs: remove xfs_probe_cluster Subject: [PATCH 07/10] xfs: remove xfs_probe_cluster References: <20101210084215.259628825@bombadil.infradead.org> Content-Disposition: inline; filename=xfs-kill-xfs_probe_cluster X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291970583 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean xfs_map_blocks always calls xfs_bmapi with the XFS_BMAPI_ENTIRE entire flag, which tells it to not cap the extent at the passed in size, but just treat the size as an minimum to map. This means xfs_probe_cluster is entirely useless as we'll always get the whole extent back anyway. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner Index: xfs/fs/xfs/linux-2.6/xfs_aops.c =================================================================== --- xfs.orig/fs/xfs/linux-2.6/xfs_aops.c 2010-12-09 15:51:10.367274204 +0100 +++ xfs/fs/xfs/linux-2.6/xfs_aops.c 2010-12-09 15:51:41.609272318 +0100 @@ -304,13 +304,13 @@ STATIC int xfs_map_blocks( struct inode *inode, loff_t offset, - ssize_t count, struct xfs_bmbt_irec *imap, int type, int nonblocking) { struct xfs_inode *ip = XFS_I(inode); struct xfs_mount *mp = ip->i_mount; + ssize_t count = 1 << inode->i_blkbits; xfs_fileoff_t offset_fsb, end_fsb; int error = 0; int bmapi_flags = XFS_BMAPI_ENTIRE; @@ -635,108 +635,6 @@ xfs_map_at_offset( } /* - * Look for a page at index that is suitable for clustering. - */ -STATIC unsigned int -xfs_probe_page( - struct page *page, - unsigned int pg_offset) -{ - struct buffer_head *bh, *head; - int ret = 0; - - if (PageWriteback(page)) - return 0; - if (!PageDirty(page)) - return 0; - if (!page->mapping) - return 0; - if (!page_has_buffers(page)) - return 0; - - bh = head = page_buffers(page); - do { - if (!buffer_uptodate(bh)) - break; - if (!buffer_mapped(bh)) - break; - ret += bh->b_size; - if (ret >= pg_offset) - break; - } while ((bh = bh->b_this_page) != head); - - return ret; -} - -STATIC size_t -xfs_probe_cluster( - struct inode *inode, - struct page *startpage, - struct buffer_head *bh, - struct buffer_head *head) -{ - struct pagevec pvec; - pgoff_t tindex, tlast, tloff; - size_t total = 0; - int done = 0, i; - - /* First sum forwards in this page */ - do { - if (!buffer_uptodate(bh) || !buffer_mapped(bh)) - return total; - total += bh->b_size; - } while ((bh = bh->b_this_page) != head); - - /* if we reached the end of the page, sum forwards in following pages */ - tlast = i_size_read(inode) >> PAGE_CACHE_SHIFT; - tindex = startpage->index + 1; - - /* Prune this back to avoid pathological behavior */ - tloff = min(tlast, startpage->index + 64); - - pagevec_init(&pvec, 0); - while (!done && tindex <= tloff) { - unsigned len = min_t(pgoff_t, PAGEVEC_SIZE, tlast - tindex + 1); - - if (!pagevec_lookup(&pvec, inode->i_mapping, tindex, len)) - break; - - for (i = 0; i < pagevec_count(&pvec); i++) { - struct page *page = pvec.pages[i]; - size_t pg_offset, pg_len = 0; - - if (tindex == tlast) { - pg_offset = - i_size_read(inode) & (PAGE_CACHE_SIZE - 1); - if (!pg_offset) { - done = 1; - break; - } - } else - pg_offset = PAGE_CACHE_SIZE; - - if (page->index == tindex && trylock_page(page)) { - pg_len = xfs_probe_page(page, pg_offset); - unlock_page(page); - } - - if (!pg_len) { - done = 1; - break; - } - - total += pg_len; - tindex++; - } - - pagevec_release(&pvec); - cond_resched(); - } - - return total; -} - -/* * Test if a given page is suitable for writing as part of an unwritten * or delayed allocate extent. */ @@ -1028,7 +926,7 @@ xfs_vm_writepage( unsigned int type; __uint64_t end_offset; pgoff_t end_index, last_index; - ssize_t size, len; + ssize_t len; int err, imap_valid = 0, uptodate = 1; int count = 0; int all_bh = 0; @@ -1133,7 +1031,7 @@ xfs_vm_writepage( * for unwritten extent conversion. */ new_ioend = 1; - err = xfs_map_blocks(inode, offset, len, &imap, + err = xfs_map_blocks(inode, offset, &imap, type, nonblocking); if (err) goto error; @@ -1158,8 +1056,7 @@ xfs_vm_writepage( } if (!imap_valid) { new_ioend = 1; - size = xfs_probe_cluster(inode, page, bh, head); - err = xfs_map_blocks(inode, offset, size, + err = xfs_map_blocks(inode, offset, &imap, type, nonblocking); if (err) goto error; From BATV+870d71e9bf4a5d360c11+2665+infradead.org+hch@bombadil.srs.infradead.org Fri Dec 10 02:41:14 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_66 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oBA8fDga205177 for ; Fri, 10 Dec 2010 02:41:14 -0600 X-ASG-Debug-ID: 1291970582-523d027b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 508E11DC53D for ; Fri, 10 Dec 2010 00:43:03 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id hba4f68hXimpJO5P for ; Fri, 10 Dec 2010 00:43:03 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PQyZC-0006Ps-MB for xfs@oss.sgi.com; Fri, 10 Dec 2010 08:43:02 +0000 Message-Id: <20101210084302.641592786@bombadil.infradead.org> User-Agent: quilt/0.48-1 Date: Fri, 10 Dec 2010 03:42:21 -0500 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 06/10] xfs: simplify xfs_map_blocks Subject: [PATCH 06/10] xfs: simplify xfs_map_blocks References: <20101210084215.259628825@bombadil.infradead.org> Content-Disposition: inline; filename=xfs-simplify-map_blocks X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291970583 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean No need to lock the extent map exclusive when performing an overwrite, we know the extent map must already have been loaded by get_blocks. Apply the non-blocking inode semantics to all mapping types instead of just delayed allocations. Remove the handling of not yet allocated blocks for the IO_UNWRITTEN case - if an extent is marked as unwritten allocated in the buffer it must already have an extent on disk. Add asserts to verify all the assumptions above in debug builds. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner Index: xfs/fs/xfs/linux-2.6/xfs_aops.c =================================================================== --- xfs.orig/fs/xfs/linux-2.6/xfs_aops.c 2010-10-31 15:10:59.000000000 -0400 +++ xfs/fs/xfs/linux-2.6/xfs_aops.c 2010-10-31 15:13:27.777719469 -0400 @@ -313,81 +313,54 @@ xfs_map_blocks( struct xfs_mount *mp = ip->i_mount; xfs_fileoff_t offset_fsb, end_fsb; int error = 0; - int lockmode = 0; int bmapi_flags = XFS_BMAPI_ENTIRE; int nimaps = 1; if (XFS_FORCED_SHUTDOWN(mp)) return -XFS_ERROR(EIO); - switch (type) { - case IO_OVERWRITE: - lockmode = xfs_ilock_map_shared(ip); - break; - case IO_UNWRITTEN: - lockmode = XFS_ILOCK_EXCL; + if (type == IO_UNWRITTEN) bmapi_flags |= XFS_BMAPI_IGSTATE; - xfs_ilock(ip, lockmode); - break; - case IO_DELALLOC: - lockmode = XFS_ILOCK_SHARED; - - if (!xfs_ilock_nowait(ip, lockmode)) { - if (nonblocking) - return -XFS_ERROR(EAGAIN); - xfs_ilock(ip, lockmode); - } - break; + + if (!xfs_ilock_nowait(ip, XFS_ILOCK_SHARED)) { + if (nonblocking) + return -XFS_ERROR(EAGAIN); + xfs_ilock(ip, XFS_ILOCK_SHARED); } + ASSERT(ip->i_d.di_format != XFS_DINODE_FMT_BTREE || + (ip->i_df.if_flags & XFS_IFEXTENTS)); ASSERT(offset <= mp->m_maxioffset); + if (offset + count > mp->m_maxioffset) count = mp->m_maxioffset - offset; end_fsb = XFS_B_TO_FSB(mp, (xfs_ufsize_t)offset + count); offset_fsb = XFS_B_TO_FSBT(mp, offset); - error = xfs_bmapi(NULL, ip, offset_fsb, end_fsb - offset_fsb, bmapi_flags, NULL, 0, imap, &nimaps, NULL); - if (error) - goto out; - - switch (type) { - case IO_UNWRITTEN: - /* If we found an extent, return it */ - if (nimaps && - (imap->br_startblock != HOLESTARTBLOCK) && - (imap->br_startblock != DELAYSTARTBLOCK)) { - trace_xfs_map_blocks_found(ip, offset, count, type, imap); - break; - } + xfs_iunlock(ip, XFS_ILOCK_SHARED); - error = xfs_iomap_write_delay(ip, offset, count, imap); - if (!error) - trace_xfs_map_blocks_alloc(ip, offset, count, type, imap); - break; - case IO_DELALLOC: - /* If we found an extent, return it */ - xfs_iunlock(ip, lockmode); - lockmode = 0; - - if (nimaps && !isnullstartblock(imap->br_startblock)) { - trace_xfs_map_blocks_found(ip, offset, count, type, imap); - break; - } + if (error) + return -XFS_ERROR(error); + if (type == IO_DELALLOC && + (!nimaps || isnullstartblock(imap->br_startblock))) { error = xfs_iomap_write_allocate(ip, offset, count, imap); if (!error) trace_xfs_map_blocks_alloc(ip, offset, count, type, imap); - break; - default: - if (nimaps) - trace_xfs_map_blocks_found(ip, offset, count, type, imap); + return -XFS_ERROR(error); } -out: - if (lockmode) - xfs_iunlock(ip, lockmode); - return -XFS_ERROR(error); +#ifdef DEBUG + if (type == IO_UNWRITTEN) { + ASSERT(nimaps); + ASSERT(imap->br_startblock != HOLESTARTBLOCK); + ASSERT(imap->br_startblock != DELAYSTARTBLOCK); + } +#endif + if (nimaps) + trace_xfs_map_blocks_found(ip, offset, count, type, imap); + return 0; } STATIC int From BATV+870d71e9bf4a5d360c11+2665+infradead.org+hch@bombadil.srs.infradead.org Fri Dec 10 02:41:15 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oBA8fChh205170 for ; Fri, 10 Dec 2010 02:41:14 -0600 X-ASG-Debug-ID: 1291970582-776801a00000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9AD161CAE1E8 for ; Fri, 10 Dec 2010 00:43:02 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id DDrZtgYEqMD834yV for ; Fri, 10 Dec 2010 00:43:02 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PQyZC-0006OG-2S for xfs@oss.sgi.com; Fri, 10 Dec 2010 08:43:02 +0000 Message-Id: <20101210084302.036988910@bombadil.infradead.org> User-Agent: quilt/0.48-1 Date: Fri, 10 Dec 2010 03:42:18 -0500 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 03/10] xfs: a few small tweaks for overwrites in xfs_vm_writepage Subject: [PATCH 03/10] xfs: a few small tweaks for overwrites in xfs_vm_writepage References: <20101210084215.259628825@bombadil.infradead.org> Content-Disposition: inline; filename=xfs-stop-trylocking-buffers X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291970582 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Don't trylock the buffer. We are the only one ever locking it for a regular file address space, and trylock was only copied from the generic code which did it due to the old buffer based writeout in jbd. Also make sure to only write out the buffer if the iomap actually is valid, because we wouldn't have a proper mapping otherwise. In practice we will never get an invalid mapping here as the page lock guarantees truncate doesn't race with us, but better be safe than sorry. Also make sure we allocate a new ioend when crossing boundaries between mappings, just like we do for delalloc and unwritten extents. Again this currently doesn't matter as the I/O end handler only cares for the boundaries for unwritten extents, but this makes the code fully correct and the same as for delalloc/unwritten extents. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner Index: xfs/fs/xfs/linux-2.6/xfs_aops.c =================================================================== --- xfs.orig/fs/xfs/linux-2.6/xfs_aops.c 2010-12-09 15:47:31.707272459 +0100 +++ xfs/fs/xfs/linux-2.6/xfs_aops.c 2010-12-09 15:47:44.805272667 +0100 @@ -1051,6 +1051,8 @@ xfs_vm_writepage( type = IO_NEW; do { + int new_ioend = 0; + if (offset >= end_offset) break; if (!buffer_uptodate(bh)) @@ -1071,8 +1073,6 @@ xfs_vm_writepage( imap_valid = xfs_imap_valid(inode, &imap, offset); if (buffer_unwritten(bh) || buffer_delay(bh)) { - int new_ioend = 0; - if (buffer_unwritten(bh)) { if (type != IO_UNWRITTEN) { type = IO_UNWRITTEN; @@ -1124,6 +1124,7 @@ xfs_vm_writepage( imap_valid = 0; } if (!imap_valid) { + new_ioend = 1; size = xfs_probe_cluster(inode, page, bh, head); err = xfs_map_blocks(inode, offset, size, &imap, flags); @@ -1142,14 +1143,12 @@ xfs_vm_writepage( * that we are writing into for the first time. */ type = IO_NEW; - if (trylock_buffer(bh)) { - if (imap_valid) - all_bh = 1; + if (imap_valid) { + all_bh = 1; + lock_buffer(bh); xfs_add_to_ioend(inode, bh, offset, type, - &ioend, !imap_valid); + &ioend, new_ioend); count++; - } else { - imap_valid = 0; } } else if (PageUptodate(page)) { ASSERT(buffer_mapped(bh)); From BATV+870d71e9bf4a5d360c11+2665+infradead.org+hch@bombadil.srs.infradead.org Fri Dec 10 02:41:14 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_66 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oBA8fDY0205176 for ; Fri, 10 Dec 2010 02:41:14 -0600 X-ASG-Debug-ID: 1291970582-4666035a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4D8F71DC53B for ; Fri, 10 Dec 2010 00:43:02 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id IW2obc0CbT3nKfQN for ; Fri, 10 Dec 2010 00:43:02 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PQyZC-0006PI-Fw for xfs@oss.sgi.com; Fri, 10 Dec 2010 08:43:02 +0000 Message-Id: <20101210084302.454258243@bombadil.infradead.org> User-Agent: quilt/0.48-1 Date: Fri, 10 Dec 2010 03:42:20 -0500 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 05/10] xfs: kill xfs_iomap Subject: [PATCH 05/10] xfs: kill xfs_iomap References: <20101210084215.259628825@bombadil.infradead.org> Content-Disposition: inline; filename=xfs-kill-xfs_iomap X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291970583 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Opencode the xfs_iomap code in it's two callers. The overlap of passed flags already was minimal and will be further reduced in the next patch. As a side effect the BMAPI_* flags for xfs_bmapi and the IO_* flags for I/O end processing are merged into a single set of flags, which should be a bit more descriptive of the operation we perform. Also improve the tracing by giving each caller it's own type set of tracepoints. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner Index: xfs/fs/xfs/xfs_iomap.h =================================================================== --- xfs.orig/fs/xfs/xfs_iomap.h 2010-12-02 12:38:03.719005800 +0100 +++ xfs/fs/xfs/xfs_iomap.h 2010-12-09 15:48:23.779003915 +0100 @@ -18,30 +18,15 @@ #ifndef __XFS_IOMAP_H__ #define __XFS_IOMAP_H__ -/* base extent manipulation calls */ -#define BMAPI_READ (1 << 0) /* read extents */ -#define BMAPI_WRITE (1 << 1) /* create extents */ -#define BMAPI_ALLOCATE (1 << 2) /* delayed allocate to real extents */ - -/* modifiers */ -#define BMAPI_IGNSTATE (1 << 4) /* ignore unwritten state on read */ -#define BMAPI_DIRECT (1 << 5) /* direct instead of buffered write */ -#define BMAPI_MMA (1 << 6) /* allocate for mmap write */ -#define BMAPI_TRYLOCK (1 << 7) /* non-blocking request */ - -#define BMAPI_FLAGS \ - { BMAPI_READ, "READ" }, \ - { BMAPI_WRITE, "WRITE" }, \ - { BMAPI_ALLOCATE, "ALLOCATE" }, \ - { BMAPI_IGNSTATE, "IGNSTATE" }, \ - { BMAPI_DIRECT, "DIRECT" }, \ - { BMAPI_TRYLOCK, "TRYLOCK" } - struct xfs_inode; struct xfs_bmbt_irec; -extern int xfs_iomap(struct xfs_inode *, xfs_off_t, ssize_t, int, - struct xfs_bmbt_irec *, int *, int *); +extern int xfs_iomap_write_direct(struct xfs_inode *, xfs_off_t, size_t, + struct xfs_bmbt_irec *, int); +extern int xfs_iomap_write_delay(struct xfs_inode *, xfs_off_t, size_t, + struct xfs_bmbt_irec *); +extern int xfs_iomap_write_allocate(struct xfs_inode *, xfs_off_t, size_t, + struct xfs_bmbt_irec *); extern int xfs_iomap_write_unwritten(struct xfs_inode *, xfs_off_t, size_t); #endif /* __XFS_IOMAP_H__*/ Index: xfs/fs/xfs/linux-2.6/xfs_aops.c =================================================================== --- xfs.orig/fs/xfs/linux-2.6/xfs_aops.c 2010-12-09 15:47:44.805272667 +0100 +++ xfs/fs/xfs/linux-2.6/xfs_aops.c 2010-12-09 15:49:29.815255698 +0100 @@ -38,15 +38,6 @@ #include #include -/* - * Types of I/O for bmap clustering and I/O completion tracking. - */ -enum { - IO_READ, /* mapping for a read */ - IO_DELAY, /* mapping covers delalloc region */ - IO_UNWRITTEN, /* mapping covers allocated but uninitialized data */ - IO_NEW /* just allocated */ -}; /* * Prime number of hash buckets since address is used as the key. @@ -182,9 +173,6 @@ xfs_setfilesize( xfs_inode_t *ip = XFS_I(ioend->io_inode); xfs_fsize_t isize; - ASSERT((ip->i_d.di_mode & S_IFMT) == S_IFREG); - ASSERT(ioend->io_type != IO_READ); - if (unlikely(ioend->io_error)) return 0; @@ -244,10 +232,8 @@ xfs_end_io( * We might have to update the on-disk file size after extending * writes. */ - if (ioend->io_type != IO_READ) { - error = xfs_setfilesize(ioend); - ASSERT(!error || error == EAGAIN); - } + error = xfs_setfilesize(ioend); + ASSERT(!error || error == EAGAIN); /* * If we didn't complete processing of the ioend, requeue it to the @@ -320,12 +306,88 @@ xfs_map_blocks( loff_t offset, ssize_t count, struct xfs_bmbt_irec *imap, - int flags) + int type, + int nonblocking) { - int nmaps = 1; - int new = 0; + struct xfs_inode *ip = XFS_I(inode); + struct xfs_mount *mp = ip->i_mount; + xfs_fileoff_t offset_fsb, end_fsb; + int error = 0; + int lockmode = 0; + int bmapi_flags = XFS_BMAPI_ENTIRE; + int nimaps = 1; + + if (XFS_FORCED_SHUTDOWN(mp)) + return -XFS_ERROR(EIO); + + switch (type) { + case IO_OVERWRITE: + lockmode = xfs_ilock_map_shared(ip); + break; + case IO_UNWRITTEN: + lockmode = XFS_ILOCK_EXCL; + bmapi_flags |= XFS_BMAPI_IGSTATE; + xfs_ilock(ip, lockmode); + break; + case IO_DELALLOC: + lockmode = XFS_ILOCK_SHARED; + + if (!xfs_ilock_nowait(ip, lockmode)) { + if (nonblocking) + return -XFS_ERROR(EAGAIN); + xfs_ilock(ip, lockmode); + } + break; + } + + ASSERT(offset <= mp->m_maxioffset); + if (offset + count > mp->m_maxioffset) + count = mp->m_maxioffset - offset; + end_fsb = XFS_B_TO_FSB(mp, (xfs_ufsize_t)offset + count); + offset_fsb = XFS_B_TO_FSBT(mp, offset); + + error = xfs_bmapi(NULL, ip, offset_fsb, end_fsb - offset_fsb, + bmapi_flags, NULL, 0, imap, &nimaps, NULL); + if (error) + goto out; + + switch (type) { + case IO_UNWRITTEN: + /* If we found an extent, return it */ + if (nimaps && + (imap->br_startblock != HOLESTARTBLOCK) && + (imap->br_startblock != DELAYSTARTBLOCK)) { + trace_xfs_map_blocks_found(ip, offset, count, type, imap); + break; + } + + error = xfs_iomap_write_delay(ip, offset, count, imap); + if (!error) + trace_xfs_map_blocks_alloc(ip, offset, count, type, imap); + break; + case IO_DELALLOC: + /* If we found an extent, return it */ + xfs_iunlock(ip, lockmode); + lockmode = 0; + + if (nimaps && !isnullstartblock(imap->br_startblock)) { + trace_xfs_map_blocks_found(ip, offset, count, type, imap); + break; + } + + error = xfs_iomap_write_allocate(ip, offset, count, imap); + if (!error) + trace_xfs_map_blocks_alloc(ip, offset, count, type, imap); + break; + default: + if (nimaps) + trace_xfs_map_blocks_found(ip, offset, count, type, imap); + } - return -xfs_iomap(XFS_I(inode), offset, count, flags, imap, &nmaps, &new); +out: + if (lockmode) + xfs_iunlock(ip, lockmode); + return -XFS_ERROR(error); } STATIC int @@ -722,9 +784,9 @@ xfs_is_delayed_page( if (buffer_unwritten(bh)) acceptable = (type == IO_UNWRITTEN); else if (buffer_delay(bh)) - acceptable = (type == IO_DELAY); + acceptable = (type == IO_DELALLOC); else if (buffer_dirty(bh) && buffer_mapped(bh)) - acceptable = (type == IO_NEW); + acceptable = (type == IO_OVERWRITE); else break; } while ((bh = bh->b_this_page) != head); @@ -809,7 +871,7 @@ xfs_convert_page( if (buffer_unwritten(bh)) type = IO_UNWRITTEN; else - type = IO_DELAY; + type = IO_DELALLOC; if (!xfs_imap_valid(inode, imap, offset)) { done = 1; @@ -826,7 +888,7 @@ xfs_convert_page( page_dirty--; count++; } else { - type = IO_NEW; + type = IO_OVERWRITE; if (buffer_mapped(bh) && all_bh) { lock_buffer(bh); xfs_add_to_ioend(inode, bh, offset, @@ -926,7 +988,7 @@ xfs_aops_discard_page( struct buffer_head *bh, *head; loff_t offset = page_offset(page); - if (!xfs_is_delayed_page(page, IO_DELAY)) + if (!xfs_is_delayed_page(page, IO_DELALLOC)) goto out_invalidate; if (XFS_FORCED_SHUTDOWN(ip->i_mount)) @@ -994,9 +1056,10 @@ xfs_vm_writepage( __uint64_t end_offset; pgoff_t end_index, last_index; ssize_t size, len; - int flags, err, imap_valid = 0, uptodate = 1; + int err, imap_valid = 0, uptodate = 1; int count = 0; int all_bh = 0; + int nonblocking = 0; trace_xfs_writepage(inode, page, 0); @@ -1047,8 +1110,10 @@ xfs_vm_writepage( bh = head = page_buffers(page); offset = page_offset(page); - flags = BMAPI_READ; - type = IO_NEW; + type = IO_OVERWRITE; + + if (wbc->sync_mode == WB_SYNC_NONE && wbc->nonblocking) + nonblocking = 1; do { int new_ioend = 0; @@ -1078,16 +1143,11 @@ xfs_vm_writepage( type = IO_UNWRITTEN; imap_valid = 0; } - flags = BMAPI_WRITE | BMAPI_IGNSTATE; } else if (buffer_delay(bh)) { - if (type != IO_DELAY) { - type = IO_DELAY; + if (type != IO_DELALLOC) { + type = IO_DELALLOC; imap_valid = 0; } - flags = BMAPI_ALLOCATE; - - if (wbc->sync_mode == WB_SYNC_NONE) - flags |= BMAPI_TRYLOCK; } if (!imap_valid) { @@ -1100,8 +1160,8 @@ xfs_vm_writepage( * for unwritten extent conversion. */ new_ioend = 1; - err = xfs_map_blocks(inode, offset, len, - &imap, flags); + err = xfs_map_blocks(inode, offset, len, &imap, + type, nonblocking); if (err) goto error; imap_valid = xfs_imap_valid(inode, &imap, @@ -1119,30 +1179,21 @@ xfs_vm_writepage( * That means it must already have extents allocated * underneath it. Map the extent by reading it. */ - if (flags != BMAPI_READ) { - flags = BMAPI_READ; + if (type != IO_OVERWRITE) { + type = IO_OVERWRITE; imap_valid = 0; } if (!imap_valid) { new_ioend = 1; size = xfs_probe_cluster(inode, page, bh, head); err = xfs_map_blocks(inode, offset, size, - &imap, flags); + &imap, type, nonblocking); if (err) goto error; imap_valid = xfs_imap_valid(inode, &imap, offset); } - /* - * We set the type to IO_NEW in case we are doing a - * small write at EOF that is extending the file but - * without needing an allocation. We need to update the - * file size on I/O completion in this case so it is - * the same case as having just allocated a new extent - * that we are writing into for the first time. - */ - type = IO_NEW; if (imap_valid) { all_bh = 1; lock_buffer(bh); @@ -1250,13 +1301,19 @@ __xfs_get_blocks( int create, int direct) { - int flags = create ? BMAPI_WRITE : BMAPI_READ; + struct xfs_inode *ip = XFS_I(inode); + struct xfs_mount *mp = ip->i_mount; + xfs_fileoff_t offset_fsb, end_fsb; + int error = 0; + int lockmode = 0; struct xfs_bmbt_irec imap; + int nimaps = 1; xfs_off_t offset; ssize_t size; - int nimap = 1; int new = 0; - int error; + + if (XFS_FORCED_SHUTDOWN(mp)) + return -XFS_ERROR(EIO); offset = (xfs_off_t)iblock << inode->i_blkbits; ASSERT(bh_result->b_size >= (1 << inode->i_blkbits)); @@ -1265,15 +1322,45 @@ __xfs_get_blocks( if (!create && direct && offset >= i_size_read(inode)) return 0; - if (direct && create) - flags |= BMAPI_DIRECT; + if (create) { + lockmode = XFS_ILOCK_EXCL; + xfs_ilock(ip, lockmode); + } else { + lockmode = xfs_ilock_map_shared(ip); + } + + ASSERT(offset <= mp->m_maxioffset); + if (offset + size > mp->m_maxioffset) + size = mp->m_maxioffset - offset; + end_fsb = XFS_B_TO_FSB(mp, (xfs_ufsize_t)offset + size); + offset_fsb = XFS_B_TO_FSBT(mp, offset); - error = xfs_iomap(XFS_I(inode), offset, size, flags, &imap, &nimap, - &new); + error = xfs_bmapi(NULL, ip, offset_fsb, end_fsb - offset_fsb, + XFS_BMAPI_ENTIRE, NULL, 0, &imap, &nimaps, NULL); if (error) - return -error; - if (nimap == 0) - return 0; + goto out_unlock; + + if (create && + (!nimaps || + (imap.br_startblock == HOLESTARTBLOCK || + imap.br_startblock == DELAYSTARTBLOCK))) { + if (direct) { + error = xfs_iomap_write_direct(ip, offset, size, + &imap, nimaps); + } else { + error = xfs_iomap_write_delay(ip, offset, size, &imap); + } + if (error) + goto out_unlock; + + trace_xfs_get_blocks_alloc(ip, offset, size, 0, &imap); + } else if (nimaps) { + trace_xfs_get_blocks_found(ip, offset, size, 0, &imap); + } else { + trace_xfs_get_blocks_notfound(ip, offset, size); + goto out_unlock; + } + xfs_iunlock(ip, lockmode); if (imap.br_startblock != HOLESTARTBLOCK && imap.br_startblock != DELAYSTARTBLOCK) { @@ -1340,6 +1427,10 @@ __xfs_get_blocks( } return 0; + +out_unlock: + xfs_iunlock(ip, lockmode); + return -error; } int @@ -1427,7 +1518,7 @@ xfs_vm_direct_IO( ssize_t ret; if (rw & WRITE) { - iocb->private = xfs_alloc_ioend(inode, IO_NEW); + iocb->private = xfs_alloc_ioend(inode, IO_DIRECT); ret = __blockdev_direct_IO(rw, iocb, inode, bdev, iov, offset, nr_segs, Index: xfs/fs/xfs/linux-2.6/xfs_trace.h =================================================================== --- xfs.orig/fs/xfs/linux-2.6/xfs_trace.h 2010-12-09 15:45:46.367254159 +0100 +++ xfs/fs/xfs/linux-2.6/xfs_trace.h 2010-12-09 15:48:23.784010410 +0100 @@ -935,10 +935,10 @@ DEFINE_PAGE_EVENT(xfs_writepage); DEFINE_PAGE_EVENT(xfs_releasepage); DEFINE_PAGE_EVENT(xfs_invalidatepage); -DECLARE_EVENT_CLASS(xfs_iomap_class, +DECLARE_EVENT_CLASS(xfs_imap_class, TP_PROTO(struct xfs_inode *ip, xfs_off_t offset, ssize_t count, - int flags, struct xfs_bmbt_irec *irec), - TP_ARGS(ip, offset, count, flags, irec), + int type, struct xfs_bmbt_irec *irec), + TP_ARGS(ip, offset, count, type, irec), TP_STRUCT__entry( __field(dev_t, dev) __field(xfs_ino_t, ino) @@ -946,7 +946,7 @@ DECLARE_EVENT_CLASS(xfs_iomap_class, __field(loff_t, new_size) __field(loff_t, offset) __field(size_t, count) - __field(int, flags) + __field(int, type) __field(xfs_fileoff_t, startoff) __field(xfs_fsblock_t, startblock) __field(xfs_filblks_t, blockcount) @@ -958,13 +958,13 @@ DECLARE_EVENT_CLASS(xfs_iomap_class, __entry->new_size = ip->i_new_size; __entry->offset = offset; __entry->count = count; - __entry->flags = flags; + __entry->type = type; __entry->startoff = irec ? irec->br_startoff : 0; __entry->startblock = irec ? irec->br_startblock : 0; __entry->blockcount = irec ? irec->br_blockcount : 0; ), TP_printk("dev %d:%d ino 0x%llx size 0x%llx new_size 0x%llx " - "offset 0x%llx count %zd flags %s " + "offset 0x%llx count %zd type %s " "startoff 0x%llx startblock %lld blockcount 0x%llx", MAJOR(__entry->dev), MINOR(__entry->dev), __entry->ino, @@ -972,20 +972,21 @@ DECLARE_EVENT_CLASS(xfs_iomap_class, __entry->new_size, __entry->offset, __entry->count, - __print_flags(__entry->flags, "|", BMAPI_FLAGS), + __print_symbolic(__entry->type, XFS_IO_TYPES), __entry->startoff, (__int64_t)__entry->startblock, __entry->blockcount) ) #define DEFINE_IOMAP_EVENT(name) \ -DEFINE_EVENT(xfs_iomap_class, name, \ +DEFINE_EVENT(xfs_imap_class, name, \ TP_PROTO(struct xfs_inode *ip, xfs_off_t offset, ssize_t count, \ - int flags, struct xfs_bmbt_irec *irec), \ - TP_ARGS(ip, offset, count, flags, irec)) -DEFINE_IOMAP_EVENT(xfs_iomap_enter); -DEFINE_IOMAP_EVENT(xfs_iomap_found); -DEFINE_IOMAP_EVENT(xfs_iomap_alloc); + int type, struct xfs_bmbt_irec *irec), \ + TP_ARGS(ip, offset, count, type, irec)) +DEFINE_IOMAP_EVENT(xfs_map_blocks_found); +DEFINE_IOMAP_EVENT(xfs_map_blocks_alloc); +DEFINE_IOMAP_EVENT(xfs_get_blocks_found); +DEFINE_IOMAP_EVENT(xfs_get_blocks_alloc); DECLARE_EVENT_CLASS(xfs_simple_io_class, TP_PROTO(struct xfs_inode *ip, xfs_off_t offset, ssize_t count), @@ -1022,6 +1023,7 @@ DEFINE_EVENT(xfs_simple_io_class, name, TP_ARGS(ip, offset, count)) DEFINE_SIMPLE_IO_EVENT(xfs_delalloc_enospc); DEFINE_SIMPLE_IO_EVENT(xfs_unwritten_convert); +DEFINE_SIMPLE_IO_EVENT(xfs_get_blocks_notfound); TRACE_EVENT(xfs_itruncate_start, Index: xfs/fs/xfs/linux-2.6/xfs_aops.h =================================================================== --- xfs.orig/fs/xfs/linux-2.6/xfs_aops.h 2010-12-02 12:38:03.745004124 +0100 +++ xfs/fs/xfs/linux-2.6/xfs_aops.h 2010-12-09 15:49:31.585257930 +0100 @@ -23,6 +23,22 @@ extern struct workqueue_struct *xfsconve extern mempool_t *xfs_ioend_pool; /* + * Types of I/O for bmap clustering and I/O completion tracking. + */ +enum { + IO_DIRECT = 0, /* special case for direct I/O ioends */ + IO_DELALLOC, /* mapping covers delalloc region */ + IO_UNWRITTEN, /* mapping covers allocated but uninitialized data */ + IO_OVERWRITE, /* mapping covers already allocated extent */ +}; + +#define XFS_IO_TYPES \ + { 0, "" }, \ + { IO_DELALLOC, "delalloc" }, \ + { IO_UNWRITTEN, "unwritten" }, \ + { IO_OVERWRITE, "overwrite" } + +/* * xfs_ioend struct manages large extent writes for XFS. * It can manage several multi-page bio's at once. */ Index: xfs/fs/xfs/xfs_iomap.c =================================================================== --- xfs.orig/fs/xfs/xfs_iomap.c 2010-12-09 15:48:00.407254089 +0100 +++ xfs/fs/xfs/xfs_iomap.c 2010-12-09 15:48:23.789003845 +0100 @@ -47,124 +47,8 @@ #define XFS_WRITEIO_ALIGN(mp,off) (((off) >> mp->m_writeio_log) \ << mp->m_writeio_log) -#define XFS_STRAT_WRITE_IMAPS 2 #define XFS_WRITE_IMAPS XFS_BMAP_MAX_NMAP -STATIC int xfs_iomap_write_direct(struct xfs_inode *, xfs_off_t, size_t, - struct xfs_bmbt_irec *, int); -STATIC int xfs_iomap_write_delay(struct xfs_inode *, xfs_off_t, size_t, - struct xfs_bmbt_irec *); -STATIC int xfs_iomap_write_allocate(struct xfs_inode *, xfs_off_t, size_t, - struct xfs_bmbt_irec *); - -int -xfs_iomap( - struct xfs_inode *ip, - xfs_off_t offset, - ssize_t count, - int flags, - struct xfs_bmbt_irec *imap, - int *nimaps, - int *new) -{ - struct xfs_mount *mp = ip->i_mount; - xfs_fileoff_t offset_fsb, end_fsb; - int error = 0; - int lockmode = 0; - int bmapi_flags = 0; - - ASSERT((ip->i_d.di_mode & S_IFMT) == S_IFREG); - - *new = 0; - - if (XFS_FORCED_SHUTDOWN(mp)) - return XFS_ERROR(EIO); - - trace_xfs_iomap_enter(ip, offset, count, flags, NULL); - - switch (flags & (BMAPI_READ | BMAPI_WRITE | BMAPI_ALLOCATE)) { - case BMAPI_READ: - lockmode = xfs_ilock_map_shared(ip); - bmapi_flags = XFS_BMAPI_ENTIRE; - break; - case BMAPI_WRITE: - lockmode = XFS_ILOCK_EXCL; - if (flags & BMAPI_IGNSTATE) - bmapi_flags |= XFS_BMAPI_IGSTATE|XFS_BMAPI_ENTIRE; - xfs_ilock(ip, lockmode); - break; - case BMAPI_ALLOCATE: - lockmode = XFS_ILOCK_SHARED; - bmapi_flags = XFS_BMAPI_ENTIRE; - - /* Attempt non-blocking lock */ - if (flags & BMAPI_TRYLOCK) { - if (!xfs_ilock_nowait(ip, lockmode)) - return XFS_ERROR(EAGAIN); - } else { - xfs_ilock(ip, lockmode); - } - break; - default: - BUG(); - } - - ASSERT(offset <= mp->m_maxioffset); - if ((xfs_fsize_t)offset + count > mp->m_maxioffset) - count = mp->m_maxioffset - offset; - end_fsb = XFS_B_TO_FSB(mp, (xfs_ufsize_t)offset + count); - offset_fsb = XFS_B_TO_FSBT(mp, offset); - - error = xfs_bmapi(NULL, ip, offset_fsb, - (xfs_filblks_t)(end_fsb - offset_fsb), - bmapi_flags, NULL, 0, imap, - nimaps, NULL); - - if (error) - goto out; - - switch (flags & (BMAPI_WRITE|BMAPI_ALLOCATE)) { - case BMAPI_WRITE: - /* If we found an extent, return it */ - if (*nimaps && - (imap->br_startblock != HOLESTARTBLOCK) && - (imap->br_startblock != DELAYSTARTBLOCK)) { - trace_xfs_iomap_found(ip, offset, count, flags, imap); - break; - } - - if (flags & BMAPI_DIRECT) { - error = xfs_iomap_write_direct(ip, offset, count, imap, - *nimaps); - } else { - error = xfs_iomap_write_delay(ip, offset, count, imap); - } - - if (!error) { - trace_xfs_iomap_alloc(ip, offset, count, flags, imap); - } - *new = 1; - break; - case BMAPI_ALLOCATE: - /* If we found an extent, return it */ - xfs_iunlock(ip, lockmode); - lockmode = 0; - - if (*nimaps && !isnullstartblock(imap->br_startblock)) { - trace_xfs_iomap_found(ip, offset, count, flags, imap); - break; - } - - error = xfs_iomap_write_allocate(ip, offset, count, imap); - break; - } - -out: - if (lockmode) - xfs_iunlock(ip, lockmode); - return XFS_ERROR(error); -} - STATIC int xfs_iomap_eof_align_last_fsb( xfs_mount_t *mp, @@ -233,7 +117,7 @@ xfs_cmn_err_fsblock_zero( return EFSCORRUPTED; } -STATIC int +int xfs_iomap_write_direct( xfs_inode_t *ip, xfs_off_t offset, @@ -428,7 +312,7 @@ xfs_iomap_eof_want_preallocate( return 0; } -STATIC int +int xfs_iomap_write_delay( xfs_inode_t *ip, xfs_off_t offset, @@ -527,7 +411,7 @@ retry: * We no longer bother to look at the incoming map - all we have to * guarantee is that whatever we allocate fills the required range. */ -STATIC int +int xfs_iomap_write_allocate( xfs_inode_t *ip, xfs_off_t offset, From BATV+870d71e9bf4a5d360c11+2665+infradead.org+hch@bombadil.srs.infradead.org Fri Dec 10 02:41:15 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,LOCAL_GNU_PATCH autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oBA8fDil205183 for ; Fri, 10 Dec 2010 02:41:15 -0600 X-ASG-Debug-ID: 1291970582-626903890000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 717C9160F98E for ; Fri, 10 Dec 2010 00:43:02 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id J8n7knZmSKLWXGHM for ; Fri, 10 Dec 2010 00:43:02 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PQyZC-0006Om-8o for xfs@oss.sgi.com; Fri, 10 Dec 2010 08:43:02 +0000 Message-Id: <20101210084302.229951279@bombadil.infradead.org> User-Agent: quilt/0.48-1 Date: Fri, 10 Dec 2010 03:42:19 -0500 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 04/10] xfs: cleanup the xfs_iomap_write_* helpers Subject: [PATCH 04/10] xfs: cleanup the xfs_iomap_write_* helpers References: <20101210084215.259628825@bombadil.infradead.org> Content-Disposition: inline; filename=xfs-cleanup-iomap-helpers X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291970583 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Remove passing the BMAPI_* flags to these helpers, in xfs_iomap_write_direct the check BMAPI_DIRECT was always true, and in the xfs_iomap_write_delay path is was never checked at all. Remove the nmap return value as we never make use of it. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner Index: xfs/fs/xfs/xfs_iomap.c =================================================================== --- xfs.orig/fs/xfs/xfs_iomap.c 2010-11-02 11:10:15.000103373 -0400 +++ xfs/fs/xfs/xfs_iomap.c 2010-11-02 11:14:14.640103375 -0400 @@ -51,11 +51,11 @@ #define XFS_WRITE_IMAPS XFS_BMAP_MAX_NMAP STATIC int xfs_iomap_write_direct(struct xfs_inode *, xfs_off_t, size_t, - int, struct xfs_bmbt_irec *, int *); -STATIC int xfs_iomap_write_delay(struct xfs_inode *, xfs_off_t, size_t, int, - struct xfs_bmbt_irec *, int *); + struct xfs_bmbt_irec *, int); +STATIC int xfs_iomap_write_delay(struct xfs_inode *, xfs_off_t, size_t, + struct xfs_bmbt_irec *); STATIC int xfs_iomap_write_allocate(struct xfs_inode *, xfs_off_t, size_t, - struct xfs_bmbt_irec *, int *); + struct xfs_bmbt_irec *); int xfs_iomap( @@ -134,12 +134,12 @@ xfs_iomap( } if (flags & BMAPI_DIRECT) { - error = xfs_iomap_write_direct(ip, offset, count, flags, - imap, nimaps); + error = xfs_iomap_write_direct(ip, offset, count, imap, + *nimaps); } else { - error = xfs_iomap_write_delay(ip, offset, count, flags, - imap, nimaps); + error = xfs_iomap_write_delay(ip, offset, count, imap); } + if (!error) { trace_xfs_iomap_alloc(ip, offset, count, flags, imap); } @@ -155,13 +155,10 @@ xfs_iomap( break; } - error = xfs_iomap_write_allocate(ip, offset, count, - imap, nimaps); + error = xfs_iomap_write_allocate(ip, offset, count, imap); break; } - ASSERT(*nimaps <= 1); - out: if (lockmode) xfs_iunlock(ip, lockmode); @@ -241,9 +238,8 @@ xfs_iomap_write_direct( xfs_inode_t *ip, xfs_off_t offset, size_t count, - int flags, xfs_bmbt_irec_t *imap, - int *nmaps) + int nmaps) { xfs_mount_t *mp = ip->i_mount; xfs_fileoff_t offset_fsb; @@ -279,7 +275,7 @@ xfs_iomap_write_direct( if (error) goto error_out; } else { - if (*nmaps && (imap->br_startblock == HOLESTARTBLOCK)) + if (nmaps && (imap->br_startblock == HOLESTARTBLOCK)) last_fsb = MIN(last_fsb, (xfs_fileoff_t) imap->br_blockcount + imap->br_startoff); @@ -331,7 +327,7 @@ xfs_iomap_write_direct( xfs_trans_ijoin(tp, ip); bmapi_flag = XFS_BMAPI_WRITE; - if ((flags & BMAPI_DIRECT) && (offset < ip->i_size || extsz)) + if (offset < ip->i_size || extsz) bmapi_flag |= XFS_BMAPI_PREALLOC; /* @@ -370,7 +366,6 @@ xfs_iomap_write_direct( goto error_out; } - *nmaps = 1; return 0; error0: /* Cancel bmap, unlock inode, unreserve quota blocks, cancel trans */ @@ -379,7 +374,6 @@ error0: /* Cancel bmap, unlock inode, un error1: /* Just cancel transaction */ xfs_trans_cancel(tp, XFS_TRANS_RELEASE_LOG_RES | XFS_TRANS_ABORT); - *nmaps = 0; /* nothing set-up here */ error_out: return XFS_ERROR(error); @@ -396,7 +390,6 @@ xfs_iomap_eof_want_preallocate( xfs_inode_t *ip, xfs_off_t offset, size_t count, - int ioflag, xfs_bmbt_irec_t *imap, int nimaps, int *prealloc) @@ -440,9 +433,7 @@ xfs_iomap_write_delay( xfs_inode_t *ip, xfs_off_t offset, size_t count, - int ioflag, - xfs_bmbt_irec_t *ret_imap, - int *nmaps) + xfs_bmbt_irec_t *ret_imap) { xfs_mount_t *mp = ip->i_mount; xfs_fileoff_t offset_fsb; @@ -470,7 +461,7 @@ xfs_iomap_write_delay( offset_fsb = XFS_B_TO_FSBT(mp, offset); error = xfs_iomap_eof_want_preallocate(mp, ip, offset, count, - ioflag, imap, XFS_WRITE_IMAPS, &prealloc); + imap, XFS_WRITE_IMAPS, &prealloc); if (error) return error; @@ -523,8 +514,6 @@ retry: return xfs_cmn_err_fsblock_zero(ip, &imap[0]); *ret_imap = imap[0]; - *nmaps = 1; - return 0; } @@ -543,8 +532,7 @@ xfs_iomap_write_allocate( xfs_inode_t *ip, xfs_off_t offset, size_t count, - xfs_bmbt_irec_t *imap, - int *retmap) + xfs_bmbt_irec_t *imap) { xfs_mount_t *mp = ip->i_mount; xfs_fileoff_t offset_fsb, last_block; @@ -557,8 +545,6 @@ xfs_iomap_write_allocate( int error = 0; int nres; - *retmap = 0; - /* * Make sure that the dquots are there. */ @@ -680,7 +666,6 @@ xfs_iomap_write_allocate( if ((offset_fsb >= imap->br_startoff) && (offset_fsb < (imap->br_startoff + imap->br_blockcount))) { - *retmap = 1; XFS_STATS_INC(xs_xstrat_quick); return 0; } From BATV+870d71e9bf4a5d360c11+2665+infradead.org+hch@bombadil.srs.infradead.org Fri Dec 10 02:41:14 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oBA8fDqU205182 for ; Fri, 10 Dec 2010 02:41:14 -0600 X-ASG-Debug-ID: 1291970583-648901350000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 84DD21DC540 for ; Fri, 10 Dec 2010 00:43:03 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id GTCfWTwAMfGrqwmh for ; Fri, 10 Dec 2010 00:43:03 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PQyZD-0006Qu-41 for xfs@oss.sgi.com; Fri, 10 Dec 2010 08:43:03 +0000 Message-Id: <20101210084303.084674092@bombadil.infradead.org> User-Agent: quilt/0.48-1 Date: Fri, 10 Dec 2010 03:42:23 -0500 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 08/10] xfs: remove the all_bh flag from xfs_convert_page Subject: [PATCH 08/10] xfs: remove the all_bh flag from xfs_convert_page References: <20101210084215.259628825@bombadil.infradead.org> Content-Disposition: inline; filename=xfs-kill-all-bh X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291970583 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean The all_bh flag is always set when entering the page clustering machinery with a regular written extent, which means the check for it is superflous. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner Index: xfs/fs/xfs/linux-2.6/xfs_aops.c =================================================================== --- xfs.orig/fs/xfs/linux-2.6/xfs_aops.c 2010-12-09 15:51:41.609272318 +0100 +++ xfs/fs/xfs/linux-2.6/xfs_aops.c 2010-12-09 15:52:12.718004124 +0100 @@ -682,8 +682,7 @@ xfs_convert_page( loff_t tindex, struct xfs_bmbt_irec *imap, xfs_ioend_t **ioendp, - struct writeback_control *wbc, - int all_bh) + struct writeback_control *wbc) { struct buffer_head *bh, *head; xfs_off_t end_offset; @@ -738,11 +737,14 @@ xfs_convert_page( continue; } - if (buffer_unwritten(bh) || buffer_delay(bh)) { + if (buffer_unwritten(bh) || buffer_delay(bh) || + buffer_mapped(bh)) { if (buffer_unwritten(bh)) type = IO_UNWRITTEN; - else + else if (buffer_delay(bh)) type = IO_DELALLOC; + else + type = IO_OVERWRITE; if (!xfs_imap_valid(inode, imap, offset)) { done = 1; @@ -752,23 +754,17 @@ xfs_convert_page( ASSERT(imap->br_startblock != HOLESTARTBLOCK); ASSERT(imap->br_startblock != DELAYSTARTBLOCK); - xfs_map_at_offset(inode, bh, imap, offset); + if (type == IO_OVERWRITE) + lock_buffer(bh); + else + xfs_map_at_offset(inode, bh, imap, offset); xfs_add_to_ioend(inode, bh, offset, type, ioendp, done); page_dirty--; count++; } else { - type = IO_OVERWRITE; - if (buffer_mapped(bh) && all_bh) { - lock_buffer(bh); - xfs_add_to_ioend(inode, bh, offset, - type, ioendp, done); - count++; - page_dirty--; - } else { - done = 1; - } + done = 1; } } while (offset += len, (bh = bh->b_this_page) != head); @@ -800,7 +796,6 @@ xfs_cluster_write( struct xfs_bmbt_irec *imap, xfs_ioend_t **ioendp, struct writeback_control *wbc, - int all_bh, pgoff_t tlast) { struct pagevec pvec; @@ -815,7 +810,7 @@ xfs_cluster_write( for (i = 0; i < pagevec_count(&pvec); i++) { done = xfs_convert_page(inode, pvec.pages[i], tindex++, - imap, ioendp, wbc, all_bh); + imap, ioendp, wbc); if (done) break; } @@ -929,7 +924,6 @@ xfs_vm_writepage( ssize_t len; int err, imap_valid = 0, uptodate = 1; int count = 0; - int all_bh = 0; int nonblocking = 0; trace_xfs_writepage(inode, page, 0); @@ -1065,7 +1059,6 @@ xfs_vm_writepage( } if (imap_valid) { - all_bh = 1; lock_buffer(bh); xfs_add_to_ioend(inode, bh, offset, type, &ioend, new_ioend); @@ -1102,7 +1095,7 @@ xfs_vm_writepage( end_index = last_index; xfs_cluster_write(inode, page->index + 1, &imap, &ioend, - wbc, all_bh, end_index); + wbc, end_index); } if (iohead) From BATV+870d71e9bf4a5d360c11+2665+infradead.org+hch@bombadil.srs.infradead.org Fri Dec 10 02:41:15 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oBA8fDRe205179 for ; Fri, 10 Dec 2010 02:41:15 -0600 X-ASG-Debug-ID: 1291970582-5e3e03c90000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4CD66160F98B for ; Fri, 10 Dec 2010 00:43:02 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id AUrICICJOTst1Dfw for ; Fri, 10 Dec 2010 00:43:02 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PQyZB-0006ND-LB for xfs@oss.sgi.com; Fri, 10 Dec 2010 08:43:01 +0000 Message-Id: <20101210084301.616302405@bombadil.infradead.org> User-Agent: quilt/0.48-1 Date: Fri, 10 Dec 2010 03:42:16 -0500 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 01/10] xfs: improve mapping type check in xfs_vm_writepage Subject: [PATCH 01/10] xfs: improve mapping type check in xfs_vm_writepage References: <20101210084215.259628825@bombadil.infradead.org> Content-Disposition: inline; filename=xfs-fix-iomap-type-checking X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291970583 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Currently we only refuse a "read-only" mapping for writing out unwritten and delayed buffers, and refuse any other for overwrites. Improve the checks to require delalloc mappings for delayed buffers, and unwritten extent mappings for unwritten extents. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner Index: xfs/fs/xfs/linux-2.6/xfs_aops.c =================================================================== --- xfs.orig/fs/xfs/linux-2.6/xfs_aops.c 2010-12-09 15:46:04.943253809 +0100 +++ xfs/fs/xfs/linux-2.6/xfs_aops.c 2010-12-09 15:47:20.583004194 +0100 @@ -1082,17 +1082,17 @@ xfs_vm_writepage( if (buffer_unwritten(bh) || buffer_delay(bh)) { int new_ioend = 0; - /* - * Make sure we don't use a read-only iomap - */ - if (flags == BMAPI_READ) - imap_valid = 0; - if (buffer_unwritten(bh)) { - type = IO_UNWRITTEN; + if (type != IO_UNWRITTEN) { + type = IO_UNWRITTEN; + imap_valid = 0; + } flags = BMAPI_WRITE | BMAPI_IGNSTATE; } else if (buffer_delay(bh)) { - type = IO_DELAY; + if (type != IO_DELAY) { + type = IO_DELAY; + imap_valid = 0; + } flags = BMAPI_ALLOCATE; if (wbc->sync_mode == WB_SYNC_NONE) @@ -1128,8 +1128,11 @@ xfs_vm_writepage( * That means it must already have extents allocated * underneath it. Map the extent by reading it. */ - if (!imap_valid || flags != BMAPI_READ) { + if (flags != BMAPI_READ) { flags = BMAPI_READ; + imap_valid = 0; + } + if (!imap_valid) { size = xfs_probe_cluster(inode, page, bh, head); err = xfs_map_blocks(inode, offset, size, &imap, flags); From BATV+870d71e9bf4a5d360c11+2665+infradead.org+hch@bombadil.srs.infradead.org Fri Dec 10 02:41:15 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oBA8fEcO205193 for ; Fri, 10 Dec 2010 02:41:14 -0600 X-ASG-Debug-ID: 1291970584-466f037c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3357C1DC540 for ; Fri, 10 Dec 2010 00:43:04 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 2qit0vwMH5fbBRiF for ; Fri, 10 Dec 2010 00:43:04 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PQyZB-0006Nk-SY for xfs@oss.sgi.com; Fri, 10 Dec 2010 08:43:01 +0000 Message-Id: <20101210084301.858316107@bombadil.infradead.org> User-Agent: quilt/0.48-1 Date: Fri, 10 Dec 2010 03:42:17 -0500 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 02/10] xfs: remove some dead bio handling code Subject: [PATCH 02/10] xfs: remove some dead bio handling code References: <20101210084215.259628825@bombadil.infradead.org> Content-Disposition: inline; filename=xfs-aop-cleanups X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291970584 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean We'll never have BIO_EOPNOTSUPP set after calling submit_bio as this can only happen for discards, and used to happen for barriers, none of which is every submitted by xfs_submit_ioend_bio. Also remove the loop around bio_alloc as it will never fail due to it's mempool backing. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner Index: xfs/fs/xfs/linux-2.6/xfs_aops.c =================================================================== --- xfs.orig/fs/xfs/linux-2.6/xfs_aops.c 2010-11-19 14:49:28.115261980 +0100 +++ xfs/fs/xfs/linux-2.6/xfs_aops.c 2010-11-19 14:49:29.417024168 +0100 @@ -380,26 +380,18 @@ xfs_submit_ioend_bio( submit_bio(wbc->sync_mode == WB_SYNC_ALL ? WRITE_SYNC_PLUG : WRITE, bio); - ASSERT(!bio_flagged(bio, BIO_EOPNOTSUPP)); - bio_put(bio); } STATIC struct bio * xfs_alloc_ioend_bio( struct buffer_head *bh) { - struct bio *bio; int nvecs = bio_get_nr_vecs(bh->b_bdev); - - do { - bio = bio_alloc(GFP_NOIO, nvecs); - nvecs >>= 1; - } while (!bio); + struct bio *bio = bio_alloc(GFP_NOIO, nvecs); ASSERT(bio->bi_private == NULL); bio->bi_sector = bh->b_blocknr * (bh->b_size >> 9); bio->bi_bdev = bh->b_bdev; - bio_get(bio); return bio; } @@ -470,9 +462,8 @@ xfs_submit_ioend( /* Pass 1 - start writeback */ do { next = ioend->io_list; - for (bh = ioend->io_buffer_head; bh; bh = bh->b_private) { + for (bh = ioend->io_buffer_head; bh; bh = bh->b_private) xfs_start_buffer_writeback(bh); - } } while ((ioend = next) != NULL); /* Pass 2 - submit I/O */ From BATV+870d71e9bf4a5d360c11+2665+infradead.org+hch@bombadil.srs.infradead.org Fri Dec 10 02:41:15 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oBA8fCsI205167 for ; Fri, 10 Dec 2010 02:41:14 -0600 X-ASG-Debug-ID: 1291970582-0d8300140000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9019D1CAE1E3 for ; Fri, 10 Dec 2010 00:43:02 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id s2wTjFL5Sz94HG7Y for ; Fri, 10 Dec 2010 00:43:02 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PQyZB-0006Me-9F for xfs@oss.sgi.com; Fri, 10 Dec 2010 08:43:01 +0000 Message-Id: <20101210084215.259628825@bombadil.infradead.org> User-Agent: quilt/0.48-1 Date: Fri, 10 Dec 2010 03:42:15 -0500 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 00/10] writeback updates V2 Subject: [PATCH 00/10] writeback updates V2 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291970582 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean - add IO_DIRECT per Dave's review comment - fix up a commit message as per Dave's review comment - add Reviewed-by: tags for Dave's reviews From BATV+870d71e9bf4a5d360c11+2665+infradead.org+hch@bombadil.srs.infradead.org Fri Dec 10 02:41:15 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oBA8fE6N205197 for ; Fri, 10 Dec 2010 02:41:14 -0600 X-ASG-Debug-ID: 1291970583-5e3f03950000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3DB91160F98F for ; Fri, 10 Dec 2010 00:43:04 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id Ro4r6ARB8ko6TmeQ for ; Fri, 10 Dec 2010 00:43:04 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PQyZD-0006Rw-Ia for xfs@oss.sgi.com; Fri, 10 Dec 2010 08:43:03 +0000 Message-Id: <20101210084303.537974157@bombadil.infradead.org> User-Agent: quilt/0.48-1 Date: Fri, 10 Dec 2010 03:42:25 -0500 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH 10/10] xfs: simplify xfs_map_at_offset Subject: [PATCH 10/10] xfs: simplify xfs_map_at_offset References: <20101210084215.259628825@bombadil.infradead.org> Content-Disposition: inline; filename=xfs-simplify-xfs_map_at_offset X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291970584 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Move the buffer locking into the callers as they need to do it wether they call xfs_map_at_offset or not. Remove the b_bdev assignment, which is already done by get_blocks. Remove the duplicate extent type asserts in xfs_convert_page just before calling xfs_map_at_offset. Signed-off-by: Christoph Hellwig Reviewed-by: Dave Chinner Index: xfs/fs/xfs/linux-2.6/xfs_aops.c =================================================================== --- xfs.orig/fs/xfs/linux-2.6/xfs_aops.c 2010-12-09 15:52:23.144273297 +0100 +++ xfs/fs/xfs/linux-2.6/xfs_aops.c 2010-12-09 15:52:41.846254159 +0100 @@ -626,9 +626,7 @@ xfs_map_at_offset( ASSERT(imap->br_startblock != HOLESTARTBLOCK); ASSERT(imap->br_startblock != DELAYSTARTBLOCK); - lock_buffer(bh); xfs_map_buffer(inode, bh, imap, offset); - bh->b_bdev = xfs_find_bdev_for_inode(inode); set_buffer_mapped(bh); clear_buffer_delay(bh); clear_buffer_unwritten(bh); @@ -751,12 +749,8 @@ xfs_convert_page( continue; } - ASSERT(imap->br_startblock != HOLESTARTBLOCK); - ASSERT(imap->br_startblock != DELAYSTARTBLOCK); - - if (type == IO_OVERWRITE) - lock_buffer(bh); - else + lock_buffer(bh); + if (type != IO_OVERWRITE) xfs_map_at_offset(inode, bh, imap, offset); xfs_add_to_ioend(inode, bh, offset, type, ioendp, done); @@ -1041,9 +1035,8 @@ xfs_vm_writepage( imap_valid = xfs_imap_valid(inode, &imap, offset); } if (imap_valid) { - if (type == IO_OVERWRITE) - lock_buffer(bh); - else + lock_buffer(bh); + if (type != IO_OVERWRITE) xfs_map_at_offset(inode, bh, &imap, offset); xfs_add_to_ioend(inode, bh, offset, type, &ioend, new_ioend); From branto@redhat.com Fri Dec 10 04:05:08 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oBAA58Lf221316 for ; Fri, 10 Dec 2010 04:05:08 -0600 X-ASG-Debug-ID: 1291975617-0e1a01c50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx1.redhat.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 730DB1CAEC64; Fri, 10 Dec 2010 02:06:57 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by cuda.sgi.com with ESMTP id dGPWk9vB5r8B2Ddu; Fri, 10 Dec 2010 02:06:57 -0800 (PST) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id oBAA6pus022927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 10 Dec 2010 05:06:52 -0500 Received: from [10.34.26.208] (dhcp-26-208.brq.redhat.com [10.34.26.208]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id oBAA6o9B002883; Fri, 10 Dec 2010 05:06:50 -0500 X-ASG-Orig-Subj: Re: [PATCH] xfstests: fix 108 golden output Subject: Re: [PATCH] xfstests: fix 108 golden output From: Boris Ranto To: aelder@sgi.com Cc: Christoph Hellwig , xfs@oss.sgi.com In-Reply-To: <1291929579.13355.30.camel@doink> References: <20101110125855.GA18357@infradead.org> <1291929579.13355.30.camel@doink> Content-Type: text/plain; charset="UTF-8" Date: Fri, 10 Dec 2010 11:06:49 +0100 Message-ID: <1291975609.3282.7.camel@dhcp-31-190.brq.redhat.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.25 X-Barracuda-Connect: mx1.redhat.com[209.132.183.28] X-Barracuda-Start-Time: 1291975618 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Thu, 2010-12-09 at 15:19 -0600, Alex Elder wrote: > On Wed, 2010-11-10 at 07:58 -0500, Christoph Hellwig wrote: > > The new common scratch mount filter produces slightly different > > whitespaces than the old home grown filter, so adjust the golden > > output. > > > > Signed-off-by: Christoph Hellwig > > I found out why this is happening. I get no > such error, and Dave Chinner said he wasn't seeing > it either. > > xfs_quota is formatting its output such that the > second and later columns always align at a certain > offset from the beginning of the line. As a result, > path names assigned as SCRATCH_DEV of different > lengths will produce different (filtered) output, > with more or fewer blanks between SCRATCH_DEV and > the usage number. > > Boris Ranto has proposed a change that would > add the "-b" flag to diff when checking output > against golden output. That should fix it, but > it's possible we *want* differences in white > space to matter in some cases. Have to look > into this. > > -Alex > The change was designed to add the "-b" flag only for this test case. Any other test case could also modify its diff options through DIFF_OPTIONS variable in its config file ($seq.config). -Boris From BATV+870d71e9bf4a5d360c11+2665+infradead.org+hch@bombadil.srs.infradead.org Fri Dec 10 07:27:50 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,J_CHICKENPOX_32, J_CHICKENPOX_33 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oBADRnPJ257855 for ; Fri, 10 Dec 2010 07:27:50 -0600 X-ASG-Debug-ID: 1291987779-068c00d70000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 418EA1CB11D7 for ; Fri, 10 Dec 2010 05:29:39 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id YEPyLRg9sR2kSd2v for ; Fri, 10 Dec 2010 05:29:39 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PR32V-0006wp-QO; Fri, 10 Dec 2010 13:29:35 +0000 Date: Fri, 10 Dec 2010 08:29:35 -0500 From: Christoph Hellwig To: Dave Chinner Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] xfs: prevent NMI timeouts in cmn_err Subject: Re: [PATCH] xfs: prevent NMI timeouts in cmn_err Message-ID: <20101210132935.GA24210@infradead.org> References: <1291341315-31338-1-git-send-email-david@fromorbit.com> <20101203043846.GB23339@dastard> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20101203043846.GB23339@dastard> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291987779 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean On Fri, Dec 03, 2010 at 03:38:46PM +1100, Dave Chinner wrote: > FWIW, while these macros are the best way to make a simple backport > is possible, I just discovered that mainline has a %pV format > operator that allows an implementation like: > > void > xfs_fs_cmn_err( > const char *lvl, > struct xfs_mount *mp, > const char *fmt, > ...) > { > struct va_format vaf; > va_list args; > > va_start(args, fmt); > vaf.fmt = fmt; > vaf.va = &args; > > printk("%sFilesystem %s: %pV", lvl, mp->m_fsname, &vaf); > va_end(args); > > BUG_ON(strncmp(lvl, KERN_EMERG, strlen(KERN_EMERG)) == 0); > } With this we can also keep the existing integer-based CE_ values and do trivial array lookup. That also avoids having to do a strcmp for every message printed. From BATV+870d71e9bf4a5d360c11+2665+infradead.org+hch@bombadil.srs.infradead.org Fri Dec 10 08:34:08 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.157.11]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oBAEY5wX008575 for ; Fri, 10 Dec 2010 08:34:08 -0600 X-ASG-Debug-ID: 1291991755-34a301900000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D29D316102D4 for ; Fri, 10 Dec 2010 06:35:55 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id no34PHDiQFd7dlrR for ; Fri, 10 Dec 2010 06:35:55 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PR44g-0000QH-Ne; Fri, 10 Dec 2010 14:35:54 +0000 Date: Fri, 10 Dec 2010 09:35:54 -0500 From: Christoph Hellwig To: Boris Ranto Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfstests: ignore absolute address in filename in test case 237 Subject: Re: xfstests: ignore absolute address in filename in test case 237 Message-ID: <20101210143554.GA1415@infradead.org> References: <1291899944.3196.11.camel@dhcp-31-190.brq.redhat.com> <1291902047.3196.26.camel@dhcp-31-190.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1291902047.3196.26.camel@dhcp-31-190.brq.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291991755 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean I don't mind the patch, but what version of getfacl would produce an absolute filename? From BATV+870d71e9bf4a5d360c11+2665+infradead.org+hch@bombadil.srs.infradead.org Fri Dec 10 08:35:28 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oBAEZSC1008868 for ; Fri, 10 Dec 2010 08:35:28 -0600 X-ASG-Debug-ID: 1291991837-5b3d02d80000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 23AF91DD3D2 for ; Fri, 10 Dec 2010 06:37:18 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id PL7wRchtucD3EIRQ for ; Fri, 10 Dec 2010 06:37:18 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PR461-0000UV-N1; Fri, 10 Dec 2010 14:37:17 +0000 Date: Fri, 10 Dec 2010 09:37:17 -0500 From: Christoph Hellwig To: Boris Ranto Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: xfstests: fix 108 through config mechanism Subject: Re: xfstests: fix 108 through config mechanism Message-ID: <20101210143717.GB1415@infradead.org> References: <1291905612.3196.49.camel@dhcp-31-190.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1291905612.3196.49.camel@dhcp-31-190.brq.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291991838 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean I don't rally like the per-test option. What about adding a _filter_xfs_quota helper that uses sed to output a canonical number of whitespaces? From BATV+870d71e9bf4a5d360c11+2665+infradead.org+hch@bombadil.srs.infradead.org Fri Dec 10 09:02:07 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_64 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.176.25]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oBAF271j014086 for ; Fri, 10 Dec 2010 09:02:07 -0600 X-ASG-Debug-ID: 1291993437-6401039a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A72E01DD9E6 for ; Fri, 10 Dec 2010 07:03:57 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id nXXEmtB1TClcLKz9 for ; Fri, 10 Dec 2010 07:03:57 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PR4Vp-0005OZ-96 for xfs@oss.sgi.com; Fri, 10 Dec 2010 15:03:57 +0000 Date: Fri, 10 Dec 2010 10:03:57 -0500 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH] xfs: clean up xfs_alloc_ag_vextent_exact Subject: [PATCH] xfs: clean up xfs_alloc_ag_vextent_exact Message-ID: <20101210150357.GA20726@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291993437 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Use a goto label to consolidate all block not found cases, and add a tracepoint for them. Also clean up a few whitespace issues. Based on an earlier patch from Dave Chinner. Signed-off-by: Christoph Hellwig Index: linux-2.6/fs/xfs/linux-2.6/xfs_trace.h =================================================================== --- linux-2.6.orig/fs/xfs/linux-2.6/xfs_trace.h +++ linux-2.6/fs/xfs/linux-2.6/xfs_trace.h @@ -1421,6 +1421,7 @@ DEFINE_EVENT(xfs_alloc_class, name, \ TP_PROTO(struct xfs_alloc_arg *args), \ TP_ARGS(args)) DEFINE_ALLOC_EVENT(xfs_alloc_exact_done); +DEFINE_ALLOC_EVENT(xfs_alloc_exact_notfound); DEFINE_ALLOC_EVENT(xfs_alloc_exact_error); DEFINE_ALLOC_EVENT(xfs_alloc_near_nominleft); DEFINE_ALLOC_EVENT(xfs_alloc_near_first); Index: linux-2.6/fs/xfs/xfs_alloc.c =================================================================== --- linux-2.6.orig/fs/xfs/xfs_alloc.c +++ linux-2.6/fs/xfs/xfs_alloc.c @@ -577,61 +577,58 @@ xfs_alloc_ag_vextent_exact( xfs_extlen_t rlen; /* length of returned extent */ ASSERT(args->alignment == 1); + /* * Allocate/initialize a cursor for the by-number freespace btree. */ bno_cur = xfs_allocbt_init_cursor(args->mp, args->tp, args->agbp, - args->agno, XFS_BTNUM_BNO); + args->agno, XFS_BTNUM_BNO); + /* * Lookup bno and minlen in the btree (minlen is irrelevant, really). * Look for the closest free block <= bno, it must contain bno * if any free block does. */ - if ((error = xfs_alloc_lookup_le(bno_cur, args->agbno, args->minlen, &i))) + error = xfs_alloc_lookup_le(bno_cur, args->agbno, args->minlen, &i); + if (error) goto error0; - if (!i) { - /* - * Didn't find it, return null. - */ - xfs_btree_del_cursor(bno_cur, XFS_BTREE_NOERROR); - args->agbno = NULLAGBLOCK; - return 0; - } + if (!i) + goto not_found; + /* * Grab the freespace record. */ - if ((error = xfs_alloc_get_rec(bno_cur, &fbno, &flen, &i))) + error = xfs_alloc_get_rec(bno_cur, &fbno, &flen, &i); + if (error) goto error0; XFS_WANT_CORRUPTED_GOTO(i == 1, error0); ASSERT(fbno <= args->agbno); minend = args->agbno + args->minlen; maxend = args->agbno + args->maxlen; fend = fbno + flen; + /* * Give up if the freespace isn't long enough for the minimum request. */ - if (fend < minend) { - xfs_btree_del_cursor(bno_cur, XFS_BTREE_NOERROR); - args->agbno = NULLAGBLOCK; - return 0; - } + if (fend < minend) + goto not_found; + /* * End of extent will be smaller of the freespace end and the * maximal requested end. - */ - end = XFS_AGBLOCK_MIN(fend, maxend); - /* + * * Fix the length according to mod and prod if given. */ + end = XFS_AGBLOCK_MIN(fend, maxend); args->len = end - args->agbno; xfs_alloc_fix_len(args); - if (!xfs_alloc_fix_minleft(args)) { - xfs_btree_del_cursor(bno_cur, XFS_BTREE_NOERROR); - return 0; - } + if (!xfs_alloc_fix_minleft(args)) + goto not_found; + rlen = args->len; ASSERT(args->agbno + rlen <= fend); end = args->agbno + rlen; + /* * We are allocating agbno for rlen [agbno .. end] * Allocate/initialize a cursor for the by-size btree. @@ -640,16 +637,25 @@ xfs_alloc_ag_vextent_exact( args->agno, XFS_BTNUM_CNT); ASSERT(args->agbno + args->len <= be32_to_cpu(XFS_BUF_TO_AGF(args->agbp)->agf_length)); - if ((error = xfs_alloc_fixup_trees(cnt_cur, bno_cur, fbno, flen, - args->agbno, args->len, XFSA_FIXUP_BNO_OK))) { + error = xfs_alloc_fixup_trees(cnt_cur, bno_cur, fbno, flen, args->agbno, + args->len, XFSA_FIXUP_BNO_OK); + if (error) { xfs_btree_del_cursor(cnt_cur, XFS_BTREE_ERROR); goto error0; } + xfs_btree_del_cursor(bno_cur, XFS_BTREE_NOERROR); xfs_btree_del_cursor(cnt_cur, XFS_BTREE_NOERROR); - trace_xfs_alloc_exact_done(args); args->wasfromfl = 0; + trace_xfs_alloc_exact_done(args); + return 0; + +not_found: + /* Didn't find it, return null. */ + xfs_btree_del_cursor(bno_cur, XFS_BTREE_NOERROR); + args->agbno = NULLAGBLOCK; + trace_xfs_alloc_exact_notfound(args); return 0; error0: From BATV+870d71e9bf4a5d360c11+2665+infradead.org+hch@bombadil.srs.infradead.org Fri Dec 10 09:02:22 2010 X-Spam-Checker-Version: SpamAssassin 3.4.0-r929098 (2010-03-30) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,J_CHICKENPOX_66 autolearn=no version=3.4.0-r929098 Received: from cuda.sgi.com (cuda3.sgi.com [192.48.176.15]) by oss.sgi.com (8.14.3/8.14.3/SuSE Linux 0.8) with ESMTP id oBAF2MQ4014147 for ; Fri, 10 Dec 2010 09:02:22 -0600 X-ASG-Debug-ID: 1291993452-441702030000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bombadil.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 582381CB1B0E for ; Fri, 10 Dec 2010 07:04:12 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id n2w9BkPur0QVIXQi for ; Fri, 10 Dec 2010 07:04:12 -0800 (PST) X-ASG-Whitelist: Client Received: from hch by bombadil.infradead.org with local (Exim 4.72 #1 (Red Hat Linux)) id 1PR4W3-0005Oh-U4 for xfs@oss.sgi.com; Fri, 10 Dec 2010 15:04:11 +0000 Date: Fri, 10 Dec 2010 10:04:11 -0500 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH] xfs: factor duplicate code in xfs_alloc_ag_vextent_near into a helper Subject: [PATCH] xfs: factor duplicate code in xfs_alloc_ag_vextent_near into a helper Message-ID: <20101210150411.GB20726@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: bombadil.infradead.org[18.85.46.34] X-Barracuda-Start-Time: 1291993452 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV version 0.94.2, clamav-milter version 0.94.2 on oss.sgi.com X-Virus-Status: Clean Add a new xfs_alloc_find_best_extent that does a forward/backward search in the allocation btree. That code previously was existed two times in xfs_a