From owner-xfs@oss.sgi.com Tue Jul 1 00:57:49 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Jul 2008 00:57:54 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_63, J_CHICKENPOX_65,J_CHICKENPOX_66 autolearn=no version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m617vh7S003945 for ; Tue, 1 Jul 2008 00:57:45 -0700 Received: from pc-bnaujok.melbourne.sgi.com (pc-bnaujok.melbourne.sgi.com [134.14.55.58]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA23222 for ; Tue, 1 Jul 2008 17:58:44 +1000 Date: Tue, 01 Jul 2008 18:00:17 +1000 To: "xfs@oss.sgi.com" Subject: REVIEW: xfs_repair fixes for bad directories From: "Barry Naujok" Organization: SGI Content-Type: multipart/mixed; boundary=----------KBCi25FieZfzpyKYHMgMHb MIME-Version: 1.0 Message-ID: User-Agent: Opera Mail/9.50 (Win32) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16669 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: bnaujok@sgi.com Precedence: bulk X-list: xfs ------------KBCi25FieZfzpyKYHMgMHb Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 Content-Transfer-Encoding: 7bit Two issues have been encounted with xfs_repair and badly corrupted directories. 1. A huge size (inode di_size) can cause malloc which will fail. Patch dir_size_check.patch checks for a valid directory size and if it's bad, junks the directory. The di_size for a dir only counts the data blocks being used, not all the other associated metadata. This is limited to 32GB by the XFS_DIR2_LEAF_OFFSET value in XFS. Anything greater than this must be invalid. 2. An update a while ago to xfs_repair attempts to fix invalid ".." entries for subdirectories where there is a valid parent with the appropriate entry. It was a partial fix that never did the full job, especially if the subdirectory was short- form or it has already been processed. Patch fix_dir_rebuild_without_dotdot_entry.patch creates a post-processing queue after the main scan to update any directories with an invalid ".." entry. Both these patches sit on top of the dinode.patch that has been posted out for review previously. ------------KBCi25FieZfzpyKYHMgMHb Content-Disposition: attachment; filename=dinode.patch Content-Type: text/x-patch; name=dinode.patch Content-Transfer-Encoding: 7bit =========================================================================== xfsprogs/repair/dino_chunks.c =========================================================================== Index: ci/xfsprogs/repair/dino_chunks.c =================================================================== --- ci.orig/xfsprogs/repair/dino_chunks.c 2007-11-16 14:45:56.000000000 +1100 +++ ci/xfsprogs/repair/dino_chunks.c 2008-01-18 14:50:42.000000000 +1100 @@ -593,7 +593,6 @@ xfs_agino_t agino; xfs_agblock_t agbno; int dirty = 0; - int cleared = 0; int isa_dir = 0; int blks_per_cluster; int cluster_count; @@ -777,8 +776,7 @@ status = process_dinode(mp, dino, agno, agino, is_inode_free(ino_rec, irec_offset), - &ino_dirty, &cleared, &is_used, - ino_discovery, check_dups, + &ino_dirty, &is_used,ino_discovery, check_dups, extra_attr_check, &isa_dir, &parent); ASSERT(is_used != 3); Index: ci/xfsprogs/repair/dinode.c =================================================================== --- ci.orig/xfsprogs/repair/dinode.c 2007-11-16 14:45:56.000000000 +1100 +++ ci/xfsprogs/repair/dinode.c 2008-01-18 14:57:36.000000000 +1100 @@ -58,9 +58,6 @@ case XFS_DINODE_FMT_LOCAL: offset += INT_GET(dinoc->di_size, ARCH_CONVERT); break; - case XFS_DINODE_FMT_UUID: - offset += sizeof(uuid_t); - break; case XFS_DINODE_FMT_EXTENTS: offset += INT_GET(dinoc->di_nextents, ARCH_CONVERT) * sizeof(xfs_bmbt_rec_32_t); break; @@ -1563,8 +1560,11 @@ * bogus */ int -process_symlink(xfs_mount_t *mp, xfs_ino_t lino, xfs_dinode_t *dino, - blkmap_t *blkmap) +process_symlink( + xfs_mount_t *mp, + xfs_ino_t lino, + xfs_dinode_t *dino, + blkmap_t *blkmap) { xfs_dfsbno_t fsbno; xfs_dinode_core_t *dinoc = &dino->di_core; @@ -1673,8 +1673,7 @@ * called to process the set of misc inode special inode types * that have no associated data storage (fifos, pipes, devices, etc.). */ -/* ARGSUSED */ -int +static int process_misc_ino_types(xfs_mount_t *mp, xfs_dinode_t *dino, xfs_ino_t lino, @@ -1693,27 +1692,27 @@ /* * must also have a zero size */ - if (INT_GET(dino->di_core.di_size, ARCH_CONVERT) != 0) { + if (dino->di_core.di_size) { switch (type) { case XR_INO_CHRDEV: do_warn(_("size of character device inode %llu != 0 " "(%lld bytes)\n"), lino, - INT_GET(dino->di_core.di_size, ARCH_CONVERT)); + be64_to_cpu(dino->di_core.di_size)); break; case XR_INO_BLKDEV: do_warn(_("size of block device inode %llu != 0 " "(%lld bytes)\n"), lino, - INT_GET(dino->di_core.di_size, ARCH_CONVERT)); + be64_to_cpu(dino->di_core.di_size)); break; case XR_INO_SOCK: do_warn(_("size of socket inode %llu != 0 " "(%lld bytes)\n"), lino, - INT_GET(dino->di_core.di_size, ARCH_CONVERT)); + be64_to_cpu(dino->di_core.di_size)); break; case XR_INO_FIFO: do_warn(_("size of fifo inode %llu != 0 " "(%lld bytes)\n"), lino, - INT_GET(dino->di_core.di_size, ARCH_CONVERT)); + be64_to_cpu(dino->di_core.di_size)); break; default: do_warn(_("Internal error - process_misc_ino_types, " @@ -1769,712 +1768,395 @@ return (0); } -/* - * returns 0 if the inode is ok, 1 if the inode is corrupt - * check_dups can be set to 1 *only* when called by the - * first pass of the duplicate block checking of phase 4. - * *dirty is set > 0 if the dinode has been altered and - * needs to be written out. - * - * for detailed, info, look at process_dinode() comments. - */ -/* ARGSUSED */ -int -process_dinode_int(xfs_mount_t *mp, - xfs_dinode_t *dino, - xfs_agnumber_t agno, - xfs_agino_t ino, - int was_free, /* 1 if inode is currently free */ - int *dirty, /* out == > 0 if inode is now dirty */ - int *cleared, /* out == 1 if inode was cleared */ - int *used, /* out == 1 if inode is in use */ - int verify_mode, /* 1 == verify but don't modify inode */ - int uncertain, /* 1 == inode is uncertain */ - int ino_discovery, /* 1 == check dirs for unknown inodes */ - int check_dups, /* 1 == check if inode claims - * duplicate blocks */ - int extra_attr_check, /* 1 == do attribute format and value checks */ - int *isa_dir, /* out == 1 if inode is a directory */ - xfs_ino_t *parent) /* out -- parent if ino is a dir */ +static inline int +dinode_fmt( + xfs_dinode_core_t *dinoc) { - xfs_drfsbno_t totblocks = 0; - xfs_drfsbno_t atotblocks = 0; - xfs_dinode_core_t *dinoc; - char *rstring; - int type; - int rtype; - int do_rt; - int err; - int retval = 0; - __uint64_t nextents; - __uint64_t anextents; - xfs_ino_t lino; - const int is_free = 0; - const int is_used = 1; - int repair = 0; - blkmap_t *ablkmap = NULL; - blkmap_t *dblkmap = NULL; - static char okfmts[] = { - 0, /* free inode */ - 1 << XFS_DINODE_FMT_DEV, /* FIFO */ - 1 << XFS_DINODE_FMT_DEV, /* CHR */ - 0, /* type 3 unused */ - (1 << XFS_DINODE_FMT_LOCAL) | - (1 << XFS_DINODE_FMT_EXTENTS) | - (1 << XFS_DINODE_FMT_BTREE), /* DIR */ - 0, /* type 5 unused */ - 1 << XFS_DINODE_FMT_DEV, /* BLK */ - 0, /* type 7 unused */ - (1 << XFS_DINODE_FMT_EXTENTS) | - (1 << XFS_DINODE_FMT_BTREE), /* REG */ - 0, /* type 9 unused */ - (1 << XFS_DINODE_FMT_LOCAL) | - (1 << XFS_DINODE_FMT_EXTENTS), /* LNK */ - 0, /* type 11 unused */ - 1 << XFS_DINODE_FMT_DEV, /* SOCK */ - 0, /* type 13 unused */ - 1 << XFS_DINODE_FMT_UUID, /* MNT */ - 0 /* type 15 unused */ - }; - - retval = 0; - totblocks = atotblocks = 0; - *dirty = *isa_dir = *cleared = 0; - *used = is_used; - type = rtype = XR_INO_UNKNOWN; - rstring = NULL; - do_rt = 0; + return be16_to_cpu(dinoc->di_mode) & S_IFMT; +} - dinoc = &dino->di_core; - lino = XFS_AGINO_TO_INO(mp, agno, ino); +static inline void +change_dinode_fmt( + xfs_dinode_core_t *dinoc, + int new_fmt) +{ + int mode = be16_to_cpu(dinoc->di_mode); - /* - * if in verify mode, don't modify the inode. - * - * if correcting, reset stuff that has known values - * - * if in uncertain mode, be silent on errors since we're - * trying to find out if these are inodes as opposed - * to assuming that they are. Just return the appropriate - * return code in that case. - */ + ASSERT((new_fmt & ~S_IFMT) == 0); - if (INT_GET(dinoc->di_magic, ARCH_CONVERT) != XFS_DINODE_MAGIC) { - retval++; - if (!verify_mode) { - do_warn(_("bad magic number 0x%x on inode %llu, "), - INT_GET(dinoc->di_magic, ARCH_CONVERT), lino); + mode &= ~S_IFMT; + mode |= new_fmt; + dinoc->di_mode = cpu_to_be16(mode); +} + +static int +check_dinode_mode_format( + xfs_dinode_core_t *dinoc) +{ + if ((uchar_t)dinoc->di_format >= XFS_DINODE_FMT_UUID) + return -1; /* FMT_UUID is not used */ + + switch (dinode_fmt(dinoc)) { + case S_IFIFO: + case S_IFCHR: + case S_IFBLK: + case S_IFSOCK: + return (dinoc->di_format != XFS_DINODE_FMT_DEV) ? -1 : 0; + + case S_IFDIR: + return (dinoc->di_format < XFS_DINODE_FMT_LOCAL || + dinoc->di_format > XFS_DINODE_FMT_BTREE) ? -1 : 0; + + case S_IFREG: + return (dinoc->di_format < XFS_DINODE_FMT_EXTENTS || + dinoc->di_format > XFS_DINODE_FMT_BTREE) ? -1 : 0; + + case S_IFLNK: + return (dinoc->di_format < XFS_DINODE_FMT_LOCAL || + dinoc->di_format > XFS_DINODE_FMT_EXTENTS) ? -1 : 0; + + default: ; + } + return 0; /* invalid modes are checked elsewhere */ +} + +/* + * If inode is a superblock inode, does type check to make sure is it valid. + * Returns 0 if it's valid, non-zero if it needs to be cleared. + */ + +static int +process_check_sb_inodes( + xfs_mount_t *mp, + xfs_dinode_core_t *dinoc, + xfs_ino_t lino, + int *type, + int *dirty) +{ + if (lino == mp->m_sb.sb_rootino) { + if (*type != XR_INO_DIR) { + do_warn(_("root inode %llu has bad type 0x%x\n"), + lino, dinode_fmt(dinoc)); + *type = XR_INO_DIR; if (!no_modify) { - do_warn(_("resetting magic number\n")); + do_warn(_("resetting to directory\n")); + change_dinode_fmt(dinoc, S_IFDIR); *dirty = 1; - INT_SET(dinoc->di_magic, ARCH_CONVERT, - XFS_DINODE_MAGIC); - } else { - do_warn(_("would reset magic number\n")); - } - } else if (!uncertain) { - do_warn(_("bad magic number 0x%x on inode %llu\n"), - INT_GET(dinoc->di_magic, ARCH_CONVERT), lino); + } else + do_warn(_("would reset to directory\n")); } + return 0; } - - if (!XFS_DINODE_GOOD_VERSION(dinoc->di_version) || - (!fs_inode_nlink && dinoc->di_version > XFS_DINODE_VERSION_1)) { - retval++; - if (!verify_mode) { - do_warn(_("bad version number 0x%x on inode %llu, "), - dinoc->di_version, lino); + if (lino == mp->m_sb.sb_uquotino) { + if (*type != XR_INO_DATA) { + do_warn(_("user quota inode %llu has bad type 0x%x\n"), + lino, dinode_fmt(dinoc)); + mp->m_sb.sb_uquotino = NULLFSINO; + return 1; + } + return 0; + } + if (lino == mp->m_sb.sb_gquotino) { + if (*type != XR_INO_DATA) { + do_warn(_("group quota inode %llu has bad type 0x%x\n"), + lino, dinode_fmt(dinoc)); + mp->m_sb.sb_gquotino = NULLFSINO; + return 1; + } + return 0; + } + if (lino == mp->m_sb.sb_rsumino) { + if (*type != XR_INO_RTSUM) { + do_warn(_("realtime summary inode %llu has bad type 0x%x, "), + lino, dinode_fmt(dinoc)); if (!no_modify) { - do_warn(_("resetting version number\n")); + do_warn(_("resetting to regular file\n")); + change_dinode_fmt(dinoc, S_IFREG); *dirty = 1; - dinoc->di_version = (fs_inode_nlink) ? - XFS_DINODE_VERSION_2 : - XFS_DINODE_VERSION_1; } else { - do_warn(_("would reset version number\n")); + do_warn(_("would reset to regular file\n")); } - } else if (!uncertain) { - do_warn(_("bad version number 0x%x on inode %llu\n"), - dinoc->di_version, lino); } + if (mp->m_sb.sb_rblocks == 0 && dinoc->di_nextents != 0) { + do_warn(_("bad # of extents (%u) for realtime summary inode %llu\n"), + be32_to_cpu(dinoc->di_nextents), lino); + return 1; + } + return 0; } - - /* - * blow out of here if the inode size is < 0 - */ - if (INT_GET(dinoc->di_size, ARCH_CONVERT) < 0) { - retval++; - if (!verify_mode) { - do_warn(_("bad (negative) size %lld on inode %llu\n"), - INT_GET(dinoc->di_size, ARCH_CONVERT), lino); + if (lino == mp->m_sb.sb_rbmino) { + if (*type != XR_INO_RTBITMAP) { + do_warn(_("realtime bitmap inode %llu has bad type 0x%x, "), + lino, dinode_fmt(dinoc)); if (!no_modify) { - *dirty += clear_dinode(mp, dino, lino); - *cleared = 1; - } else { + do_warn(_("resetting to regular file\n")); + change_dinode_fmt(dinoc, S_IFREG); *dirty = 1; - *cleared = 1; + } else { + do_warn(_("would reset to regular file\n")); } - *used = is_free; - } else if (!uncertain) { - do_warn(_("bad (negative) size %lld on inode %llu\n"), - INT_GET(dinoc->di_size, ARCH_CONVERT), lino); } - - return(1); - } - - /* - * was_free value is not meaningful if we're in verify mode - */ - if (!verify_mode && INT_GET(dinoc->di_mode, ARCH_CONVERT) == 0 && was_free == 1) { - /* - * easy case, inode free -- inode and map agree, clear - * it just in case to ensure that format, etc. are - * set correctly - */ - if (!no_modify) { - err = clear_dinode(mp, dino, lino); - if (err) { - *dirty = 1; - *cleared = 1; - } + if (mp->m_sb.sb_rblocks == 0 && dinoc->di_nextents != 0) { + do_warn(_("bad # of extents (%u) for realtime bitmap inode %llu\n"), + be32_to_cpu(dinoc->di_nextents), lino); + return 1; } - *used = is_free; - return(0); - } else if (!verify_mode && INT_GET(dinoc->di_mode, ARCH_CONVERT) == 0 && was_free == 0) { - /* - * the inode looks free but the map says it's in use. - * clear the inode just to be safe and mark the inode - * free. - */ - do_warn(_("imap claims a free inode %llu is in use, "), lino); + return 0; + } + return 0; +} - if (!no_modify) { - do_warn(_("correcting imap and clearing inode\n")); +/* + * general size/consistency checks: + * + * if the size <= size of the data fork, directories must be + * local inodes unlike regular files which would be extent inodes. + * all the other mentioned types have to have a zero size value. + * + * if the size and format don't match, get out now rather than + * risk trying to process a non-existent extents or btree + * type data fork. + */ +static int +process_check_inode_sizes( + xfs_mount_t *mp, + xfs_dinode_t *dino, + xfs_ino_t lino, + int type) +{ + xfs_dinode_core_t *dinoc = &dino->di_core; + xfs_fsize_t size = be64_to_cpu(dinoc->di_size); - err = clear_dinode(mp, dino, lino); - if (err) { - retval++; - *dirty = 1; - *cleared = 1; - } - } else { - do_warn(_("would correct imap and clear inode\n")); + switch (type) { - *dirty = 1; - *cleared = 1; + case XR_INO_DIR: + if (size <= XFS_DFORK_DSIZE(dino, mp) && + dinoc->di_format != XFS_DINODE_FMT_LOCAL) { + do_warn(_("mismatch between format (%d) and size " + "(%lld) in directory ino %llu\n"), + dinoc->di_format, size, lino); + return 1; } + break; - *used = is_free; - - return(retval > 0 ? 1 : 0); - } - - /* - * because of the lack of any write ordering guarantee, it's - * possible that the core got updated but the forks didn't. - * so rather than be ambitious (and probably incorrect), - * if there's an inconsistency, we get conservative and - * just pitch the file. blow off checking formats of - * free inodes since technically any format is legal - * as we reset the inode when we re-use it. - */ - if (INT_GET(dinoc->di_mode, ARCH_CONVERT) != 0 && - ((((INT_GET(dinoc->di_mode, ARCH_CONVERT) & S_IFMT) >> 12) > 15) || - (uchar_t) dinoc->di_format > XFS_DINODE_FMT_UUID || - (!(okfmts[(INT_GET(dinoc->di_mode, ARCH_CONVERT) & S_IFMT) >> 12] & - (1 << dinoc->di_format))))) { - /* bad inode format */ - retval++; - if (!uncertain) - do_warn(_("bad inode format in inode %llu\n"), lino); - if (!verify_mode) { - if (!no_modify) { - *dirty += clear_dinode(mp, dino, lino); - ASSERT(*dirty > 0); - } + case XR_INO_SYMLINK: + if (process_symlink_extlist(mp, lino, dino)) { + do_warn(_("bad data fork in symlink %llu\n"), lino); + return 1; } - *cleared = 1; - *used = is_free; - - return(retval > 0 ? 1 : 0); - } - - if (verify_mode) - return(retval > 0 ? 1 : 0); - - /* - * clear the next unlinked field if necessary on a good - * inode only during phase 4 -- when checking for inodes - * referencing duplicate blocks. then it's safe because - * we've done the inode discovery and have found all the inodes - * we're going to find. check_dups is set to 1 only during - * phase 4. Ugly. - */ - if (check_dups && !no_modify) - *dirty += clear_dinode_unlinked(mp, dino); - - /* set type and map type info */ + break; - switch (INT_GET(dinoc->di_mode, ARCH_CONVERT) & S_IFMT) { - case S_IFDIR: - type = XR_INO_DIR; - *isa_dir = 1; + case XR_INO_CHRDEV: /* fall through to FIFO case ... */ + case XR_INO_BLKDEV: /* fall through to FIFO case ... */ + case XR_INO_SOCK: /* fall through to FIFO case ... */ + case XR_INO_MOUNTPOINT: /* fall through to FIFO case ... */ + case XR_INO_FIFO: + if (process_misc_ino_types(mp, dino, lino, type)) + return 1; break; - case S_IFREG: - if (INT_GET(dinoc->di_flags, ARCH_CONVERT) & XFS_DIFLAG_REALTIME) - type = XR_INO_RTDATA; - else if (lino == mp->m_sb.sb_rbmino) - type = XR_INO_RTBITMAP; - else if (lino == mp->m_sb.sb_rsumino) - type = XR_INO_RTSUM; - else - type = XR_INO_DATA; + + case XR_INO_RTDATA: + /* + * if we have no realtime blocks, any inode claiming + * to be a real-time file is bogus + */ + if (mp->m_sb.sb_rblocks == 0) { + do_warn(_("found inode %llu claiming to be a " + "real-time file\n"), lino); + return 1; + } break; - case S_IFLNK: - type = XR_INO_SYMLINK; + + case XR_INO_RTBITMAP: + if (size != (__int64_t)mp->m_sb.sb_rbmblocks * + mp->m_sb.sb_blocksize) { + do_warn(_("realtime bitmap inode %llu has bad size " + "%lld (should be %lld)\n"), + lino, size, (__int64_t) mp->m_sb.sb_rbmblocks * + mp->m_sb.sb_blocksize); + return 1; + } break; - case S_IFCHR: - type = XR_INO_CHRDEV; + + case XR_INO_RTSUM: + if (size != mp->m_rsumsize) { + do_warn(_("realtime summary inode %llu has bad size " + "%lld (should be %d)\n"), + lino, size, mp->m_rsumsize); + return 1; + } break; - case S_IFBLK: - type = XR_INO_BLKDEV; + + default: break; - case S_IFSOCK: - type = XR_INO_SOCK; + } + return 0; +} + +/* + * check for illegal values of forkoff + */ +static int +process_check_inode_forkoff( + xfs_mount_t *mp, + xfs_dinode_core_t *dinoc, + xfs_ino_t lino) +{ + if (dinoc->di_forkoff == 0) + return 0; + + switch (dinoc->di_format) { + case XFS_DINODE_FMT_DEV: + if (dinoc->di_forkoff != (roundup(sizeof(xfs_dev_t), 8) >> 3)) { + do_warn(_("bad attr fork offset %d in dev inode %llu, " + "should be %d\n"), dinoc->di_forkoff, lino, + (int)(roundup(sizeof(xfs_dev_t), 8) >> 3)); + return 1; + } break; - case S_IFIFO: - type = XR_INO_FIFO; + case XFS_DINODE_FMT_LOCAL: /* fall through ... */ + case XFS_DINODE_FMT_EXTENTS: /* fall through ... */ + case XFS_DINODE_FMT_BTREE: + if (dinoc->di_forkoff >= (XFS_LITINO(mp) >> 3)) { + do_warn(_("bad attr fork offset %d in inode %llu, " + "max=%d\n"), dinoc->di_forkoff, lino, + XFS_LITINO(mp) >> 3); + return 1; + } break; default: - retval++; - if (!verify_mode) { - do_warn(_("bad inode type %#o inode %llu\n"), - (int) (INT_GET(dinoc->di_mode, ARCH_CONVERT) & S_IFMT), lino); - if (!no_modify) - *dirty += clear_dinode(mp, dino, lino); - else - *dirty = 1; - *cleared = 1; - *used = is_free; - } else if (!uncertain) { - do_warn(_("bad inode type %#o inode %llu\n"), - (int) (INT_GET(dinoc->di_mode, ARCH_CONVERT) & S_IFMT), lino); - } - return 1; + do_error(_("unexpected inode format %d\n"), dinoc->di_format); + break; } + return 0; +} - /* - * type checks for root, realtime inodes, and quota inodes - */ - if (lino == mp->m_sb.sb_rootino && type != XR_INO_DIR) { - do_warn(_("bad inode type for root inode %llu, "), lino); - type = XR_INO_DIR; - +/* + * Updates the inodes block and extent counts if they are wrong + */ +static int +process_inode_blocks_and_extents( + xfs_dinode_core_t *dinoc, + xfs_drfsbno_t nblocks, + __uint64_t nextents, + __uint64_t anextents, + xfs_ino_t lino, + int *dirty) +{ + if (nblocks != be64_to_cpu(dinoc->di_nblocks)) { if (!no_modify) { - do_warn(_("resetting to directory\n")); - INT_MOD_EXPR(dinoc->di_mode, ARCH_CONVERT, - &= ~(INT_GET(dinoc->di_mode, ARCH_CONVERT) & S_IFMT)); - INT_MOD_EXPR(dinoc->di_mode, ARCH_CONVERT, - |= INT_GET(dinoc->di_mode, ARCH_CONVERT) & S_IFDIR); + do_warn(_("correcting nblocks for inode %llu, " + "was %llu - counted %llu\n"), lino, + be64_to_cpu(dinoc->di_nblocks), nblocks); + dinoc->di_nblocks = cpu_to_be64(nblocks); + *dirty = 1; } else { - do_warn(_("would reset to directory\n")); + do_warn(_("bad nblocks %llu for inode %llu, " + "would reset to %llu\n"), + be64_to_cpu(dinoc->di_nblocks), lino, nblocks); } - } else if (lino == mp->m_sb.sb_rsumino) { - do_rt = 1; - rstring = _("summary"); - rtype = XR_INO_RTSUM; - } else if (lino == mp->m_sb.sb_rbmino) { - do_rt = 1; - rstring = _("bitmap"); - rtype = XR_INO_RTBITMAP; - } else if (lino == mp->m_sb.sb_uquotino) { - if (type != XR_INO_DATA) { - do_warn(_("user quota inode has bad type 0x%x\n"), - INT_GET(dinoc->di_mode, ARCH_CONVERT) & S_IFMT); + } - if (!no_modify) { - *dirty += clear_dinode(mp, dino, lino); - ASSERT(*dirty > 0); - } - - *cleared = 1; - *used = is_free; - *isa_dir = 0; - - mp->m_sb.sb_uquotino = NULLFSINO; - - return(1); - } - } else if (lino == mp->m_sb.sb_gquotino) { - if (type != XR_INO_DATA) { - do_warn(_("group quota inode has bad type 0x%x\n"), - INT_GET(dinoc->di_mode, ARCH_CONVERT) & S_IFMT); - - if (!no_modify) { - *dirty += clear_dinode(mp, dino, lino); - ASSERT(*dirty > 0); - } - - *cleared = 1; - *used = is_free; - *isa_dir = 0; - - mp->m_sb.sb_gquotino = NULLFSINO; - - return(1); - } + if (nextents > MAXEXTNUM) { + do_warn(_("too many data fork extents (%llu) in inode %llu\n"), + nextents, lino); + return 1; } - - if (do_rt && type != rtype) { - type = XR_INO_DATA; - - do_warn(_("bad inode type for realtime %s inode %llu, "), - rstring, lino); - + if (nextents != be32_to_cpu(dinoc->di_nextents)) { if (!no_modify) { - do_warn(_("resetting to regular file\n")); - INT_MOD_EXPR(dinoc->di_mode, ARCH_CONVERT, - &= ~(INT_GET(dinoc->di_mode, ARCH_CONVERT) & S_IFMT)); - INT_MOD_EXPR(dinoc->di_mode, ARCH_CONVERT, - |= INT_GET(dinoc->di_mode, ARCH_CONVERT) & S_IFREG); + do_warn(_("correcting nextents for inode %llu, " + "was %d - counted %llu\n"), lino, + be32_to_cpu(dinoc->di_nextents), nextents); + dinoc->di_nextents = cpu_to_be32(nextents); + *dirty = 1; } else { - do_warn(_("would reset to regular file\n")); - } - } - - /* - * only regular files with REALTIME or EXTSIZE flags set can have - * extsize set, or directories with EXTSZINHERIT. - */ - if (INT_GET(dinoc->di_extsize, ARCH_CONVERT) != 0) { - if ((type == XR_INO_RTDATA) || - (type == XR_INO_DIR && - (INT_GET(dinoc->di_flags, ARCH_CONVERT) & - XFS_DIFLAG_EXTSZINHERIT)) || - (type == XR_INO_DATA && - (INT_GET(dinoc->di_flags, ARCH_CONVERT) & - XFS_DIFLAG_EXTSIZE))) { - /* s'okay */ ; - } else { - do_warn( - _("bad non-zero extent size %u for non-realtime/extsize inode %llu, "), - INT_GET(dinoc->di_extsize, ARCH_CONVERT), lino); - - if (!no_modify) { - do_warn(_("resetting to zero\n")); - dinoc->di_extsize = 0; - *dirty = 1; - } else { - do_warn(_("would reset to zero\n")); - } + do_warn(_("bad nextents %d for inode %llu, would reset " + "to %llu\n"), be32_to_cpu(dinoc->di_nextents), + lino, nextents); } } - /* - * for realtime inodes, check sizes to see that - * they are consistent with the # of realtime blocks. - * also, verify that they contain only one extent and - * are extent format files. If anything's wrong, clear - * the inode -- we'll recreate it in phase 6. - */ - if (do_rt && - ((lino == mp->m_sb.sb_rbmino && - INT_GET(dinoc->di_size, ARCH_CONVERT) - != mp->m_sb.sb_rbmblocks * mp->m_sb.sb_blocksize) || - (lino == mp->m_sb.sb_rsumino && - INT_GET(dinoc->di_size, ARCH_CONVERT) != mp->m_rsumsize))) { - - do_warn(_("bad size %llu for realtime %s inode %llu\n"), - INT_GET(dinoc->di_size, ARCH_CONVERT), rstring, lino); - - if (!no_modify) { - *dirty += clear_dinode(mp, dino, lino); - ASSERT(*dirty > 0); - } - - *cleared = 1; - *used = is_free; - *isa_dir = 0; - - return(1); + if (anextents > MAXAEXTNUM) { + do_warn(_("too many attr fork extents (%llu) in inode %llu\n"), + anextents, lino); + return 1; } - - if (do_rt && mp->m_sb.sb_rblocks == 0 && INT_GET(dinoc->di_nextents, ARCH_CONVERT) != 0) { - do_warn(_("bad # of extents (%u) for realtime %s inode %llu\n"), - INT_GET(dinoc->di_nextents, ARCH_CONVERT), rstring, lino); - + if (anextents != be16_to_cpu(dinoc->di_anextents)) { if (!no_modify) { - *dirty += clear_dinode(mp, dino, lino); - ASSERT(*dirty > 0); - } - - *cleared = 1; - *used = is_free; - *isa_dir = 0; - - return(1); - } - - /* - * Setup nextents and anextents for blkmap_alloc calls. - */ - nextents = INT_GET(dinoc->di_nextents, ARCH_CONVERT); - if (nextents > INT_GET(dinoc->di_nblocks, ARCH_CONVERT) || nextents > XFS_MAX_INCORE_EXTENTS) - nextents = 1; - anextents = INT_GET(dinoc->di_anextents, ARCH_CONVERT); - if (anextents > INT_GET(dinoc->di_nblocks, ARCH_CONVERT) || anextents > XFS_MAX_INCORE_EXTENTS) - anextents = 1; - - /* - * general size/consistency checks: - * - * if the size <= size of the data fork, directories must be - * local inodes unlike regular files which would be extent inodes. - * all the other mentioned types have to have a zero size value. - * - * if the size and format don't match, get out now rather than - * risk trying to process a non-existent extents or btree - * type data fork. - */ - switch (type) { - case XR_INO_DIR: - if (INT_GET(dinoc->di_size, ARCH_CONVERT) <= - XFS_DFORK_DSIZE(dino, mp) && - (dinoc->di_format != XFS_DINODE_FMT_LOCAL)) { - do_warn( -_("mismatch between format (%d) and size (%lld) in directory ino %llu\n"), - dinoc->di_format, - INT_GET(dinoc->di_size, ARCH_CONVERT), - lino); - - if (!no_modify) { - *dirty += clear_dinode(mp, - dino, lino); - ASSERT(*dirty > 0); - } - - *cleared = 1; - *used = is_free; - *isa_dir = 0; - - return(1); - } - if (dinoc->di_format != XFS_DINODE_FMT_LOCAL) - dblkmap = blkmap_alloc(nextents); - break; - case XR_INO_SYMLINK: - if (process_symlink_extlist(mp, lino, dino)) { - do_warn(_("bad data fork in symlink %llu\n"), lino); - - if (!no_modify) { - *dirty += clear_dinode(mp, - dino, lino); - ASSERT(*dirty > 0); - } - - *cleared = 1; - *used = is_free; - *isa_dir = 0; - - return(1); - } - if (dinoc->di_format != XFS_DINODE_FMT_LOCAL) - dblkmap = blkmap_alloc(nextents); - break; - case XR_INO_CHRDEV: /* fall through to FIFO case ... */ - case XR_INO_BLKDEV: /* fall through to FIFO case ... */ - case XR_INO_SOCK: /* fall through to FIFO case ... */ - case XR_INO_MOUNTPOINT: /* fall through to FIFO case ... */ - case XR_INO_FIFO: - if (process_misc_ino_types(mp, dino, lino, type)) { - if (!no_modify) { - *dirty += clear_dinode(mp, dino, lino); - ASSERT(*dirty > 0); - } - - *cleared = 1; - *used = is_free; - *isa_dir = 0; - - return(1); - } - break; - case XR_INO_RTDATA: - /* - * if we have no realtime blocks, any inode claiming - * to be a real-time file is bogus - */ - if (mp->m_sb.sb_rblocks == 0) { - do_warn( - _("found inode %llu claiming to be a real-time file\n"), - lino); - - if (!no_modify) { - *dirty += clear_dinode(mp, dino, lino); - ASSERT(*dirty > 0); - } - - *cleared = 1; - *used = is_free; - *isa_dir = 0; - - return(1); - } - break; - case XR_INO_RTBITMAP: - if (INT_GET(dinoc->di_size, ARCH_CONVERT) != - (__int64_t)mp->m_sb.sb_rbmblocks * mp->m_sb.sb_blocksize) { - do_warn( - _("realtime bitmap inode %llu has bad size %lld (should be %lld)\n"), - lino, INT_GET(dinoc->di_size, ARCH_CONVERT), - (__int64_t) mp->m_sb.sb_rbmblocks * - mp->m_sb.sb_blocksize); - - if (!no_modify) { - *dirty += clear_dinode(mp, dino, lino); - ASSERT(*dirty > 0); - } - - *cleared = 1; - *used = is_free; - *isa_dir = 0; - - return(1); - } - dblkmap = blkmap_alloc(nextents); - break; - case XR_INO_RTSUM: - if (INT_GET(dinoc->di_size, ARCH_CONVERT) != mp->m_rsumsize) { - do_warn( - _("realtime summary inode %llu has bad size %lld (should be %d)\n"), - lino, INT_GET(dinoc->di_size, ARCH_CONVERT), - mp->m_rsumsize); - - if (!no_modify) { - *dirty += clear_dinode(mp, dino, lino); - ASSERT(*dirty > 0); - } - - *cleared = 1; - *used = is_free; - *isa_dir = 0; - - return(1); - } - dblkmap = blkmap_alloc(nextents); - break; - default: - break; - } - - /* - * check for illegal values of forkoff - */ - err = 0; - if (dinoc->di_forkoff != 0) { - switch (dinoc->di_format) { - case XFS_DINODE_FMT_DEV: - if (dinoc->di_forkoff != - (roundup(sizeof(xfs_dev_t), 8) >> 3)) { - do_warn( - _("bad attr fork offset %d in dev inode %llu, should be %d\n"), - (int) dinoc->di_forkoff, - lino, - (int) (roundup(sizeof(xfs_dev_t), 8) >> 3)); - err = 1; - } - break; - case XFS_DINODE_FMT_UUID: - if (dinoc->di_forkoff != - (roundup(sizeof(uuid_t), 8) >> 3)) { - do_warn( - _("bad attr fork offset %d in uuid inode %llu, should be %d\n"), - (int) dinoc->di_forkoff, - lino, - (int)(roundup(sizeof(uuid_t), 8) >> 3)); - err = 1; - } - break; - case XFS_DINODE_FMT_LOCAL: /* fall through ... */ - case XFS_DINODE_FMT_EXTENTS: /* fall through ... */ - case XFS_DINODE_FMT_BTREE: { - if (dinoc->di_forkoff >= (XFS_LITINO(mp) >> 3)) { - do_warn( - _("bad attr fork offset %d in inode %llu, max=%d\n"), - (int) dinoc->di_forkoff, - lino, XFS_LITINO(mp) >> 3); - err = 1; - } - break; - } - default: - do_error(_("unexpected inode format %d\n"), - (int) dinoc->di_format); - break; + do_warn(_("correcting anextents for inode %llu, " + "was %d - counted %llu\n"), lino, + be16_to_cpu(dinoc->di_anextents), anextents); + dinoc->di_anextents = cpu_to_be16(anextents); + *dirty = 1; + } else { + do_warn(_("bad anextents %d for inode %llu, would reset" + " to %llu\n"), be16_to_cpu(dinoc->di_anextents), + lino, anextents); } } + return 0; +} - if (err) { - if (!no_modify) { - *dirty += clear_dinode(mp, dino, lino); - ASSERT(*dirty > 0); - } +/* + * check data fork -- if it's bad, clear the inode + */ +static int +process_inode_data_fork( + xfs_mount_t *mp, + xfs_agnumber_t agno, + xfs_agino_t ino, + xfs_dinode_t *dino, + int type, + int *dirty, + xfs_drfsbno_t *totblocks, + __uint64_t *nextents, + blkmap_t **dblkmap, + int check_dups) +{ + xfs_dinode_core_t *dinoc = &dino->di_core; + xfs_ino_t lino = XFS_AGINO_TO_INO(mp, agno, ino); + int err = 0; - *cleared = 1; - *used = is_free; - *isa_dir = 0; - blkmap_free(dblkmap); - return(1); - } + *nextents = be32_to_cpu(dinoc->di_nextents); + if (*nextents > be64_to_cpu(dinoc->di_nblocks) || + *nextents > XFS_MAX_INCORE_EXTENTS) + *nextents = 1; + + if (dinoc->di_format != XFS_DINODE_FMT_LOCAL && type != XR_INO_RTDATA) + *dblkmap = blkmap_alloc(*nextents); + *nextents = 0; - /* - * check data fork -- if it's bad, clear the inode - */ - nextents = 0; switch (dinoc->di_format) { case XFS_DINODE_FMT_LOCAL: - err = process_lclinode(mp, agno, ino, dino, type, - dirty, &totblocks, &nextents, &dblkmap, - XFS_DATA_FORK, check_dups); + err = process_lclinode(mp, agno, ino, dino, type, dirty, + totblocks, nextents, dblkmap, XFS_DATA_FORK, + check_dups); break; case XFS_DINODE_FMT_EXTENTS: - err = process_exinode(mp, agno, ino, dino, type, - dirty, &totblocks, &nextents, &dblkmap, - XFS_DATA_FORK, check_dups); + err = process_exinode(mp, agno, ino, dino, type, dirty, + totblocks, nextents, dblkmap, XFS_DATA_FORK, + check_dups); break; case XFS_DINODE_FMT_BTREE: - err = process_btinode(mp, agno, ino, dino, type, - dirty, &totblocks, &nextents, &dblkmap, - XFS_DATA_FORK, check_dups); + err = process_btinode(mp, agno, ino, dino, type, dirty, + totblocks, nextents, dblkmap, XFS_DATA_FORK, + check_dups); break; case XFS_DINODE_FMT_DEV: /* fall through */ - case XFS_DINODE_FMT_UUID: err = 0; break; default: do_error(_("unknown format %d, ino %llu (mode = %d)\n"), - dinoc->di_format, lino, - INT_GET(dinoc->di_mode, ARCH_CONVERT)); + dinoc->di_format, lino, be16_to_cpu(dinoc->di_mode)); } if (err) { - /* - * problem in the data fork, clear out the inode - * and get out - */ do_warn(_("bad data fork in inode %llu\n"), lino); - if (!no_modify) { *dirty += clear_dinode(mp, dino, lino); ASSERT(*dirty > 0); } - - *cleared = 1; - *used = is_free; - *isa_dir = 0; - blkmap_free(dblkmap); - return(1); + return 1; } if (check_dups) { @@ -2486,465 +2168,635 @@ switch (dinoc->di_format) { case XFS_DINODE_FMT_LOCAL: err = process_lclinode(mp, agno, ino, dino, type, - dirty, &totblocks, &nextents, &dblkmap, + dirty, totblocks, nextents, dblkmap, XFS_DATA_FORK, 0); break; case XFS_DINODE_FMT_EXTENTS: err = process_exinode(mp, agno, ino, dino, type, - dirty, &totblocks, &nextents, &dblkmap, + dirty, totblocks, nextents, dblkmap, XFS_DATA_FORK, 0); break; case XFS_DINODE_FMT_BTREE: err = process_btinode(mp, agno, ino, dino, type, - dirty, &totblocks, &nextents, &dblkmap, + dirty, totblocks, nextents, dblkmap, XFS_DATA_FORK, 0); break; case XFS_DINODE_FMT_DEV: /* fall through */ - case XFS_DINODE_FMT_UUID: err = 0; break; default: do_error(_("unknown format %d, ino %llu (mode = %d)\n"), dinoc->di_format, lino, - INT_GET(dinoc->di_mode, ARCH_CONVERT)); + be16_to_cpu(dinoc->di_mode)); } - if (no_modify && err != 0) { - *cleared = 1; - *used = is_free; - *isa_dir = 0; - blkmap_free(dblkmap); - return(1); - } + if (no_modify && err != 0) + return 1; ASSERT(err == 0); } + return 0; +} - /* - * check attribute fork if necessary. attributes are - * always stored in the regular filesystem. - */ +/* + * Process extended attribute fork in inode + */ +static int +process_inode_attr_fork( + xfs_mount_t *mp, + xfs_agnumber_t agno, + xfs_agino_t ino, + xfs_dinode_t *dino, + int type, + int *dirty, + xfs_drfsbno_t *atotblocks, + __uint64_t *anextents, + int check_dups, + int extra_attr_check, + int *retval) +{ + xfs_dinode_core_t *dinoc = &dino->di_core; + xfs_ino_t lino = XFS_AGINO_TO_INO(mp, agno, ino); + blkmap_t *ablkmap = NULL; + int repair = 0; + int err; + + if (!XFS_DFORK_Q(dino)) { + *anextents = 0; + if (dinoc->di_aformat != XFS_DINODE_FMT_EXTENTS) { + do_warn(_("bad attribute format %d in inode %llu, "), + dinoc->di_aformat, lino); + if (!no_modify) { + do_warn(_("resetting value\n")); + dinoc->di_aformat = XFS_DINODE_FMT_EXTENTS; + *dirty = 1; + } else + do_warn(_("would reset value\n")); + } + return 0; + } - if (!XFS_DFORK_Q(dino) && - dinoc->di_aformat != XFS_DINODE_FMT_EXTENTS) { - do_warn(_("bad attribute format %d in inode %llu, "), - dinoc->di_aformat, lino); - if (!no_modify) { - do_warn(_("resetting value\n")); - dinoc->di_aformat = XFS_DINODE_FMT_EXTENTS; - *dirty = 1; - } else - do_warn(_("would reset value\n")); - anextents = 0; - } else if (XFS_DFORK_Q(dino)) { + *anextents = be16_to_cpu(dinoc->di_anextents); + if (*anextents > be64_to_cpu(dinoc->di_nblocks) || + *anextents > XFS_MAX_INCORE_EXTENTS) + *anextents = 1; + + switch (dinoc->di_aformat) { + case XFS_DINODE_FMT_LOCAL: + *anextents = 0; + err = process_lclinode(mp, agno, ino, dino, type, dirty, + atotblocks, anextents, &ablkmap, + XFS_ATTR_FORK, check_dups); + break; + case XFS_DINODE_FMT_EXTENTS: + ablkmap = blkmap_alloc(*anextents); + *anextents = 0; + err = process_exinode(mp, agno, ino, dino, type, dirty, + atotblocks, anextents, &ablkmap, + XFS_ATTR_FORK, check_dups); + break; + case XFS_DINODE_FMT_BTREE: + ablkmap = blkmap_alloc(*anextents); + *anextents = 0; + err = process_btinode(mp, agno, ino, dino, type, dirty, + atotblocks, anextents, &ablkmap, + XFS_ATTR_FORK, check_dups); + break; + default: + do_warn(_("illegal attribute format %d, ino %llu\n"), + dinoc->di_aformat, lino); + err = 1; + break; + } + + if (err) { + /* + * clear the attribute fork if necessary. we can't + * clear the inode because we've already put the + * inode space info into the blockmap. + * + * XXX - put the inode onto the "move it" list and + * log the the attribute scrubbing + */ + do_warn(_("bad attribute fork in inode %llu"), lino); + + if (!no_modify) { + if (delete_attr_ok) { + do_warn(_(", clearing attr fork\n")); + *dirty += clear_dinode_attr(mp, dino, lino); + dinoc->di_aformat = XFS_DINODE_FMT_LOCAL; + } else { + do_warn("\n"); + *dirty += clear_dinode(mp, dino, lino); + } + ASSERT(*dirty > 0); + } else { + do_warn(_(", would clear attr fork\n")); + } + + *atotblocks = 0; + *anextents = 0; + blkmap_free(ablkmap); + *retval = 1; + + return delete_attr_ok ? 0 : 1; + } + + if (check_dups) { switch (dinoc->di_aformat) { case XFS_DINODE_FMT_LOCAL: - anextents = 0; err = process_lclinode(mp, agno, ino, dino, - type, dirty, &atotblocks, &anextents, &ablkmap, - XFS_ATTR_FORK, check_dups); + type, dirty, atotblocks, anextents, + &ablkmap, XFS_ATTR_FORK, 0); break; case XFS_DINODE_FMT_EXTENTS: - ablkmap = blkmap_alloc(anextents); - anextents = 0; err = process_exinode(mp, agno, ino, dino, - type, dirty, &atotblocks, &anextents, &ablkmap, - XFS_ATTR_FORK, check_dups); + type, dirty, atotblocks, anextents, + &ablkmap, XFS_ATTR_FORK, 0); break; case XFS_DINODE_FMT_BTREE: - ablkmap = blkmap_alloc(anextents); - anextents = 0; err = process_btinode(mp, agno, ino, dino, - type, dirty, &atotblocks, &anextents, &ablkmap, - XFS_ATTR_FORK, check_dups); + type, dirty, atotblocks, anextents, + &ablkmap, XFS_ATTR_FORK, 0); break; default: - anextents = 0; - do_warn(_("illegal attribute format %d, ino %llu\n"), - dinoc->di_aformat, lino); - err = 1; - break; + do_error(_("illegal attribute fmt %d, ino %llu\n"), + dinoc->di_aformat, lino); } - if (err) { - /* - * clear the attribute fork if necessary. we can't - * clear the inode because we've already put the - * inode space info into the blockmap. - * - * XXX - put the inode onto the "move it" list and - * log the the attribute scrubbing - */ - do_warn(_("bad attribute fork in inode %llu"), lino); + if (no_modify && err != 0) { + blkmap_free(ablkmap); + return 1; + } + ASSERT(err == 0); + } + + /* + * do attribute semantic-based consistency checks now + */ + + /* get this only in phase 3, not in both phase 3 and 4 */ + if (extra_attr_check && + process_attributes(mp, lino, dino, ablkmap, &repair)) { + do_warn(_("problem with attribute contents in inode %llu\n"), + lino); + if (!repair) { + /* clear attributes if not done already */ if (!no_modify) { - if (delete_attr_ok) { - do_warn(_(", clearing attr fork\n")); - *dirty += clear_dinode_attr(mp, - dino, lino); - } else { - do_warn("\n"); - *dirty += clear_dinode(mp, - dino, lino); - } - ASSERT(*dirty > 0); + *dirty += clear_dinode_attr(mp, dino, lino); + dinoc->di_aformat = XFS_DINODE_FMT_LOCAL; } else { - do_warn(_(", would clear attr fork\n")); + do_warn(_("would clear attr fork\n")); } + *atotblocks = 0; + *anextents = 0; + } + else { + *dirty = 1; /* it's been repaired */ + } + } + blkmap_free(ablkmap); + return 0; +} - atotblocks = 0; - anextents = 0; +/* + * check nlinks feature, if it's a version 1 inode, + * just leave nlinks alone. even if it's set wrong, + * it'll be reset when read in. + */ - if (delete_attr_ok) { - if (!no_modify) - dinoc->di_aformat = XFS_DINODE_FMT_LOCAL; +static int +process_check_inode_nlink_version( + xfs_dinode_core_t *dinoc, + xfs_ino_t lino) +{ + int dirty = 0; + + if (dinoc->di_version > XFS_DINODE_VERSION_1 && !fs_inode_nlink) { + /* + * do we have a fs/inode version mismatch with a valid + * version 2 inode here that has to stay version 2 or + * lose links? + */ + if (be32_to_cpu(dinoc->di_nlink) > XFS_MAXLINK_1) { + /* + * yes. are nlink inodes allowed? + */ + if (fs_inode_nlink_allowed) { + /* + * yes, update status variable which will + * cause sb to be updated later. + */ + fs_inode_nlink = 1; + do_warn(_("version 2 inode %llu claims > %u links, "), + lino, XFS_MAXLINK_1); + if (!no_modify) { + do_warn(_("updating superblock " + "version number\n")); + } else { + do_warn(_("would update superblock " + "version number\n")); + } } else { - *cleared = 1; - *used = is_free; - *isa_dir = 0; - blkmap_free(dblkmap); - blkmap_free(ablkmap); + /* + * no, have to convert back to onlinks + * even if we lose some links + */ + do_warn(_("WARNING: version 2 inode %llu " + "claims > %u links, "), + lino, XFS_MAXLINK_1); + if (!no_modify) { + do_warn(_("converting back to version 1,\n" + "this may destroy %d links\n"), + be32_to_cpu(dinoc->di_nlink) - + XFS_MAXLINK_1); + + dinoc->di_version = XFS_DINODE_VERSION_1; + dinoc->di_nlink = cpu_to_be32(XFS_MAXLINK_1); + dinoc->di_onlink = cpu_to_be16(XFS_MAXLINK_1); + dirty = 1; + } else { + do_warn(_("would convert back to version 1,\n" + "\tthis might destroy %d links\n"), + be32_to_cpu(dinoc->di_nlink) - + XFS_MAXLINK_1); + } } - return(1); - - } else if (check_dups) { - switch (dinoc->di_aformat) { - case XFS_DINODE_FMT_LOCAL: - err = process_lclinode(mp, agno, ino, dino, - type, dirty, &atotblocks, &anextents, - &ablkmap, XFS_ATTR_FORK, 0); - break; - case XFS_DINODE_FMT_EXTENTS: - err = process_exinode(mp, agno, ino, dino, - type, dirty, &atotblocks, &anextents, - &ablkmap, XFS_ATTR_FORK, 0); - break; - case XFS_DINODE_FMT_BTREE: - err = process_btinode(mp, agno, ino, dino, - type, dirty, &atotblocks, &anextents, - &ablkmap, XFS_ATTR_FORK, 0); - break; - default: - do_error( - _("illegal attribute fmt %d, ino %llu\n"), - dinoc->di_aformat, lino); + } else { + /* + * do we have a v2 inode that we could convert back + * to v1 without losing any links? if we do and + * we have a mismatch between superblock bits and the + * version bit, alter the version bit in this case. + * + * the case where we lost links was handled above. + */ + do_warn(_("found version 2 inode %llu, "), lino); + if (!no_modify) { + do_warn(_("converting back to version 1\n")); + dinoc->di_version = XFS_DINODE_VERSION_1; + dinoc->di_onlink = cpu_to_be16( + be32_to_cpu(dinoc->di_nlink)); + dirty = 1; + } else { + do_warn(_("would convert back to version 1\n")); } + } + } + + /* + * ok, if it's still a version 2 inode, it's going + * to stay a version 2 inode. it should have a zero + * onlink field, so clear it. + */ + if (dinoc->di_version > XFS_DINODE_VERSION_1 && + dinoc->di_onlink != 0 && fs_inode_nlink > 0) { + if (!no_modify) { + do_warn(_("clearing obsolete nlink field in " + "version 2 inode %llu, was %d, now 0\n"), + lino, be16_to_cpu(dinoc->di_onlink)); + dinoc->di_onlink = 0; + dirty = 1; + } else { + do_warn(_("would clear obsolete nlink field in " + "version 2 inode %llu, currently %d\n"), + lino, be16_to_cpu(dinoc->di_onlink)); + } + } + return dirty; +} + +/* + * returns 0 if the inode is ok, 1 if the inode is corrupt + * check_dups can be set to 1 *only* when called by the + * first pass of the duplicate block checking of phase 4. + * *dirty is set > 0 if the dinode has been altered and + * needs to be written out. + * + * for detailed, info, look at process_dinode() comments. + */ +/* ARGSUSED */ +int +process_dinode_int(xfs_mount_t *mp, + xfs_dinode_t *dino, + xfs_agnumber_t agno, + xfs_agino_t ino, + int was_free, /* 1 if inode is currently free */ + int *dirty, /* out == > 0 if inode is now dirty */ + int *used, /* out == 1 if inode is in use */ + int verify_mode, /* 1 == verify but don't modify inode */ + int uncertain, /* 1 == inode is uncertain */ + int ino_discovery, /* 1 == check dirs for unknown inodes */ + int check_dups, /* 1 == check if inode claims + * duplicate blocks */ + int extra_attr_check, /* 1 == do attribute format and value checks */ + int *isa_dir, /* out == 1 if inode is a directory */ + xfs_ino_t *parent) /* out -- parent if ino is a dir */ +{ + xfs_drfsbno_t totblocks = 0; + xfs_drfsbno_t atotblocks = 0; + xfs_dinode_core_t *dinoc; + int di_mode; + int type; + int retval = 0; + __uint64_t nextents; + __uint64_t anextents; + xfs_ino_t lino; + const int is_free = 0; + const int is_used = 1; + blkmap_t *dblkmap = NULL; + + *dirty = *isa_dir = 0; + *used = is_used; + type = XR_INO_UNKNOWN; + + dinoc = &dino->di_core; + lino = XFS_AGINO_TO_INO(mp, agno, ino); + di_mode = be16_to_cpu(dinoc->di_mode); + + /* + * if in verify mode, don't modify the inode. + * + * if correcting, reset stuff that has known values + * + * if in uncertain mode, be silent on errors since we're + * trying to find out if these are inodes as opposed + * to assuming that they are. Just return the appropriate + * return code in that case. + * + * If uncertain is set, verify_mode MUST be set. + */ + ASSERT(uncertain == 0 || verify_mode != 0); + + if (be16_to_cpu(dinoc->di_magic) != XFS_DINODE_MAGIC) { + retval = 1; + if (!uncertain) + do_warn(_("bad magic number 0x%x on inode %llu%c"), + be16_to_cpu(dinoc->di_magic), lino, + verify_mode ? '\n' : ','); + if (!verify_mode) { + if (!no_modify) { + do_warn(_(" resetting magic number\n")); + dinoc->di_magic = cpu_to_be16(XFS_DINODE_MAGIC); + *dirty = 1; + } else + do_warn(_(" would reset magic number\n")); + } + } + + if (!XFS_DINODE_GOOD_VERSION(dinoc->di_version) || + (!fs_inode_nlink && dinoc->di_version > XFS_DINODE_VERSION_1)) { + retval = 1; + if (!uncertain) + do_warn(_("bad version number 0x%x on inode %llu%c"), + dinoc->di_version, lino, + verify_mode ? '\n' : ','); + if (!verify_mode) { + if (!no_modify) { + do_warn(_(" resetting version number\n")); + dinoc->di_version = (fs_inode_nlink) ? + XFS_DINODE_VERSION_2 : + XFS_DINODE_VERSION_1; + *dirty = 1; + } else + do_warn(_(" would reset version number\n")); + } + } + + /* + * blow out of here if the inode size is < 0 + */ + if ((xfs_fsize_t)be64_to_cpu(dinoc->di_size) < 0) { + if (!uncertain) + do_warn(_("bad (negative) size %lld on inode %llu\n"), + be64_to_cpu(dinoc->di_size), lino); + if (verify_mode) + return 1; + goto clear_bad_out; + } + + /* + * if not in verify mode, check to sii if the inode and imap + * agree that the inode is free + */ + if (!verify_mode && di_mode == 0) { + /* + * was_free value is not meaningful if we're in verify mode + */ + if (was_free) { + /* + * easy case, inode free -- inode and map agree, clear + * it just in case to ensure that format, etc. are + * set correctly + */ + if (!no_modify) + *dirty += clear_dinode(mp, dino, lino); + *used = is_free; + return 0; + } + /* + * the inode looks free but the map says it's in use. + * clear the inode just to be safe and mark the inode + * free. + */ + do_warn(_("imap claims a free inode %llu is in use, "), lino); + if (!no_modify) { + do_warn(_("correcting imap and clearing inode\n")); + *dirty += clear_dinode(mp, dino, lino); + retval = 1; + } else + do_warn(_("would correct imap and clear inode\n")); + *used = is_free; + return retval; + } - if (no_modify && err != 0) { - *cleared = 1; - *used = is_free; - *isa_dir = 0; - blkmap_free(dblkmap); - blkmap_free(ablkmap); - return(1); - } + /* + * because of the lack of any write ordering guarantee, it's + * possible that the core got updated but the forks didn't. + * so rather than be ambitious (and probably incorrect), + * if there's an inconsistency, we get conservative and + * just pitch the file. blow off checking formats of + * free inodes since technically any format is legal + * as we reset the inode when we re-use it. + */ + if (di_mode != 0 && check_dinode_mode_format(dinoc) != 0) { + if (!uncertain) + do_warn(_("bad inode format in inode %llu\n"), lino); + if (verify_mode) + return 1; + goto clear_bad_out; + } - ASSERT(err == 0); - } + if (verify_mode) + return retval; - /* - * do attribute semantic-based consistency checks now - */ + /* + * clear the next unlinked field if necessary on a good + * inode only during phase 4 -- when checking for inodes + * referencing duplicate blocks. then it's safe because + * we've done the inode discovery and have found all the inodes + * we're going to find. check_dups is set to 1 only during + * phase 4. Ugly. + */ + if (check_dups && !no_modify) + *dirty += clear_dinode_unlinked(mp, dino); - /* get this only in phase 3, not in both phase 3 and 4 */ - if (extra_attr_check) { - if ((err = process_attributes(mp, lino, dino, ablkmap, - &repair))) { - do_warn( - _("problem with attribute contents in inode %llu\n"), lino); - if(!repair) { - /* clear attributes if not done already */ - if (!no_modify) { - *dirty += clear_dinode_attr( - mp, dino, lino); - dinoc->di_aformat = - XFS_DINODE_FMT_LOCAL; - } else { - do_warn( - _("would clear attr fork\n")); - } - atotblocks = 0; - anextents = 0; - } - else { - *dirty = 1; /* it's been repaired */ - } - } - } - blkmap_free(ablkmap); + /* set type and map type info */ - } else - anextents = 0; + switch (di_mode & S_IFMT) { + case S_IFDIR: + type = XR_INO_DIR; + *isa_dir = 1; + break; + case S_IFREG: + if (be16_to_cpu(dinoc->di_flags) & XFS_DIFLAG_REALTIME) + type = XR_INO_RTDATA; + else if (lino == mp->m_sb.sb_rbmino) + type = XR_INO_RTBITMAP; + else if (lino == mp->m_sb.sb_rsumino) + type = XR_INO_RTSUM; + else + type = XR_INO_DATA; + break; + case S_IFLNK: + type = XR_INO_SYMLINK; + break; + case S_IFCHR: + type = XR_INO_CHRDEV; + break; + case S_IFBLK: + type = XR_INO_BLKDEV; + break; + case S_IFSOCK: + type = XR_INO_SOCK; + break; + case S_IFIFO: + type = XR_INO_FIFO; + break; + default: + do_warn(_("bad inode type %#o inode %llu\n"), + di_mode & S_IFMT, lino); + goto clear_bad_out; + } /* - * enforce totblocks is 0 for misc types - */ - if (process_misc_ino_types_blocks(totblocks, lino, type)) { - if (!no_modify) { - *dirty += clear_dinode(mp, dino, lino); - ASSERT(*dirty > 0); - } - *cleared = 1; - *used = is_free; - *isa_dir = 0; - blkmap_free(dblkmap); - return(1); - } + * type checks for superblock inodes + */ + if (process_check_sb_inodes(mp, dinoc, lino, &type, dirty) != 0) + goto clear_bad_out; /* - * correct space counters if required + * only regular files with REALTIME or EXTSIZE flags set can have + * extsize set, or directories with EXTSZINHERIT. */ - if (totblocks + atotblocks != INT_GET(dinoc->di_nblocks, ARCH_CONVERT)) { - if (!no_modify) { - do_warn( - _("correcting nblocks for inode %llu, was %llu - counted %llu\n"), - lino, INT_GET(dinoc->di_nblocks, ARCH_CONVERT), - totblocks + atotblocks); - *dirty = 1; - INT_SET(dinoc->di_nblocks, ARCH_CONVERT, totblocks + atotblocks); - } else { - do_warn( - _("bad nblocks %llu for inode %llu, would reset to %llu\n"), - INT_GET(dinoc->di_nblocks, ARCH_CONVERT), lino, - totblocks + atotblocks); + if (dinoc->di_extsize) { + if ((type == XR_INO_RTDATA) || + (type == XR_INO_DIR && (be16_to_cpu(dinoc->di_flags) & + XFS_DIFLAG_EXTSZINHERIT)) || + (type == XR_INO_DATA && (be16_to_cpu(dinoc->di_flags) & + XFS_DIFLAG_EXTSIZE))) { + /* s'okay */ ; + } else { + do_warn(_("bad non-zero extent size %u for " + "non-realtime/extsize inode %llu, "), + be32_to_cpu(dinoc->di_extsize), lino); + if (!no_modify) { + do_warn(_("resetting to zero\n")); + dinoc->di_extsize = 0; + *dirty = 1; + } else + do_warn(_("would reset to zero\n")); } } - if (nextents > MAXEXTNUM) { - do_warn(_("too many data fork extents (%llu) in inode %llu\n"), - nextents, lino); + /* + * general size/consistency checks: + */ + if (process_check_inode_sizes(mp, dino, lino, type) != 0) + goto clear_bad_out; - if (!no_modify) { - *dirty += clear_dinode(mp, dino, lino); - ASSERT(*dirty > 0); - } - *cleared = 1; - *used = is_free; - *isa_dir = 0; - blkmap_free(dblkmap); + /* + * check for illegal values of forkoff + */ + if (process_check_inode_forkoff(mp, dinoc, lino) != 0) + goto clear_bad_out; - return(1); - } - if (nextents != INT_GET(dinoc->di_nextents, ARCH_CONVERT)) { - if (!no_modify) { - do_warn( - _("correcting nextents for inode %llu, was %d - counted %llu\n"), - lino, INT_GET(dinoc->di_nextents, ARCH_CONVERT), - nextents); - *dirty = 1; - INT_SET(dinoc->di_nextents, ARCH_CONVERT, - (xfs_extnum_t) nextents); - } else { - do_warn( - _("bad nextents %d for inode %llu, would reset to %llu\n"), - INT_GET(dinoc->di_nextents, ARCH_CONVERT), - lino, nextents); - } - } + /* + * check data fork -- if it's bad, clear the inode + */ + if (process_inode_data_fork(mp, agno, ino, dino, type, dirty, + &totblocks, &nextents, &dblkmap, check_dups) != 0) + goto bad_out; - if (anextents > MAXAEXTNUM) { - do_warn(_("too many attr fork extents (%llu) in inode %llu\n"), - anextents, lino); + /* + * check attribute fork if necessary. attributes are + * always stored in the regular filesystem. + */ + if (process_inode_attr_fork(mp, agno, ino, dino, type, dirty, + &atotblocks, &anextents, check_dups, extra_attr_check, + &retval)) + goto bad_out; - if (!no_modify) { - *dirty += clear_dinode(mp, dino, lino); - ASSERT(*dirty > 0); - } - *cleared = 1; - *used = is_free; - *isa_dir = 0; - blkmap_free(dblkmap); - return(1); - } - if (anextents != INT_GET(dinoc->di_anextents, ARCH_CONVERT)) { - if (!no_modify) { - do_warn( - _("correcting anextents for inode %llu, was %d - counted %llu\n"), - lino, - INT_GET(dinoc->di_anextents, ARCH_CONVERT), - anextents); - *dirty = 1; - INT_SET(dinoc->di_anextents, ARCH_CONVERT, - (xfs_aextnum_t) anextents); - } else { - do_warn( - _("bad anextents %d for inode %llu, would reset to %llu\n"), - INT_GET(dinoc->di_anextents, ARCH_CONVERT), - lino, anextents); - } - } + /* + * enforce totblocks is 0 for misc types + */ + if (process_misc_ino_types_blocks(totblocks, lino, type)) + goto clear_bad_out; + + /* + * correct space counters if required + */ + if (process_inode_blocks_and_extents(dinoc, totblocks + atotblocks, + nextents, anextents, lino, dirty) != 0) + goto clear_bad_out; /* * do any semantic type-based checking here */ switch (type) { case XR_INO_DIR: - if (XFS_SB_VERSION_HASDIRV2(&mp->m_sb)) - err = process_dir2(mp, lino, dino, ino_discovery, - dirty, "", parent, dblkmap); - else - err = process_dir(mp, lino, dino, ino_discovery, - dirty, "", parent, dblkmap); - if (err) - do_warn( - _("problem with directory contents in inode %llu\n"), - lino); - break; - case XR_INO_RTBITMAP: - /* process_rtbitmap XXX */ - err = 0; - break; - case XR_INO_RTSUM: - /* process_rtsummary XXX */ - err = 0; + if (process_dir2(mp, lino, dino, ino_discovery, dirty, "", + parent, dblkmap) != 0) { + do_warn(_("problem with directory contents in " + "inode %llu\n"), lino); + goto clear_bad_out; + } break; case XR_INO_SYMLINK: - if ((err = process_symlink(mp, lino, dino, dblkmap))) + if (process_symlink(mp, lino, dino, dblkmap) != 0) { do_warn(_("problem with symbolic link in inode %llu\n"), lino); - break; - case XR_INO_DATA: /* fall through to FIFO case ... */ - case XR_INO_RTDATA: /* fall through to FIFO case ... */ - case XR_INO_CHRDEV: /* fall through to FIFO case ... */ - case XR_INO_BLKDEV: /* fall through to FIFO case ... */ - case XR_INO_SOCK: /* fall through to FIFO case ... */ - case XR_INO_FIFO: - err = 0; + goto clear_bad_out; + } break; default: - printf(_("Unexpected inode type\n")); - abort(); + break; } if (dblkmap) blkmap_free(dblkmap); - if (err) { - /* - * problem in the inode type-specific semantic - * checking, clear out the inode and get out - */ - if (!no_modify) { - *dirty += clear_dinode(mp, dino, lino); - ASSERT(*dirty > 0); - } - *cleared = 1; - *used = is_free; - *isa_dir = 0; - - return(1); - } - /* * check nlinks feature, if it's a version 1 inode, * just leave nlinks alone. even if it's set wrong, * it'll be reset when read in. */ - if (dinoc->di_version > XFS_DINODE_VERSION_1 && !fs_inode_nlink) { - /* - * do we have a fs/inode version mismatch with a valid - * version 2 inode here that has to stay version 2 or - * lose links? - */ - if (INT_GET(dinoc->di_nlink, ARCH_CONVERT) > XFS_MAXLINK_1) { - /* - * yes. are nlink inodes allowed? - */ - if (fs_inode_nlink_allowed) { - /* - * yes, update status variable which will - * cause sb to be updated later. - */ - fs_inode_nlink = 1; - do_warn( - _("version 2 inode %llu claims > %u links, "), - lino, XFS_MAXLINK_1); - if (!no_modify) { - do_warn( - _("updating superblock version number\n")); - } else { - do_warn( - _("would update superblock version number\n")); - } - } else { - /* - * no, have to convert back to onlinks - * even if we lose some links - */ - do_warn( - _("WARNING: version 2 inode %llu claims > %u links, "), - lino, XFS_MAXLINK_1); - if (!no_modify) { - do_warn( - _("converting back to version 1,\n\tthis may destroy %d links\n"), - INT_GET(dinoc->di_nlink, - ARCH_CONVERT) - - XFS_MAXLINK_1); - - dinoc->di_version = - XFS_DINODE_VERSION_1; - INT_SET(dinoc->di_nlink, ARCH_CONVERT, - XFS_MAXLINK_1); - INT_SET(dinoc->di_onlink, ARCH_CONVERT, - XFS_MAXLINK_1); - - *dirty = 1; - } else { - do_warn( - _("would convert back to version 1,\n\tthis might destroy %d links\n"), - INT_GET(dinoc->di_nlink, - ARCH_CONVERT) - - XFS_MAXLINK_1); - } - } - } else { - /* - * do we have a v2 inode that we could convert back - * to v1 without losing any links? if we do and - * we have a mismatch between superblock bits and the - * version bit, alter the version bit in this case. - * - * the case where we lost links was handled above. - */ - do_warn(_("found version 2 inode %llu, "), lino); - if (!no_modify) { - do_warn(_("converting back to version 1\n")); - - dinoc->di_version = - XFS_DINODE_VERSION_1; - INT_SET(dinoc->di_onlink, ARCH_CONVERT, - INT_GET(dinoc->di_nlink, ARCH_CONVERT)); - - *dirty = 1; - } else { - do_warn(_("would convert back to version 1\n")); - } - } - } + *dirty = process_check_inode_nlink_version(dinoc, lino); - /* - * ok, if it's still a version 2 inode, it's going - * to stay a version 2 inode. it should have a zero - * onlink field, so clear it. - */ - if (dinoc->di_version > XFS_DINODE_VERSION_1 && - INT_GET(dinoc->di_onlink, ARCH_CONVERT) > 0 && - fs_inode_nlink > 0) { - if (!no_modify) { - do_warn( -_("clearing obsolete nlink field in version 2 inode %llu, was %d, now 0\n"), - lino, INT_GET(dinoc->di_onlink, ARCH_CONVERT)); - dinoc->di_onlink = 0; - *dirty = 1; - } else { - do_warn( -_("would clear obsolete nlink field in version 2 inode %llu, currently %d\n"), - lino, INT_GET(dinoc->di_onlink, ARCH_CONVERT)); - *dirty = 1; - } - } + return retval; - return(retval > 0 ? 1 : 0); +clear_bad_out: + if (!no_modify) { + *dirty += clear_dinode(mp, dino, lino); + ASSERT(*dirty > 0); + } +bad_out: + *used = is_free; + *isa_dir = 0; + if (dblkmap) + blkmap_free(dblkmap); + return 1; } /* @@ -2983,8 +2835,6 @@ * claimed blocks using the bitmap. * Outs: * dirty -- whether we changed the inode (1 == yes) - * cleared -- whether we cleared the inode (1 == yes). In - * no modify mode, if we would have cleared it * used -- 1 if the inode is used, 0 if free. In no modify * mode, whether the inode should be used or free * isa_dir -- 1 if the inode is a directory, 0 if not. In @@ -2994,30 +2844,29 @@ */ int -process_dinode(xfs_mount_t *mp, - xfs_dinode_t *dino, - xfs_agnumber_t agno, - xfs_agino_t ino, - int was_free, - int *dirty, - int *cleared, - int *used, - int ino_discovery, - int check_dups, - int extra_attr_check, - int *isa_dir, - xfs_ino_t *parent) +process_dinode( + xfs_mount_t *mp, + xfs_dinode_t *dino, + xfs_agnumber_t agno, + xfs_agino_t ino, + int was_free, + int *dirty, + int *used, + int ino_discovery, + int check_dups, + int extra_attr_check, + int *isa_dir, + xfs_ino_t *parent) { - const int verify_mode = 0; - const int uncertain = 0; + const int verify_mode = 0; + const int uncertain = 0; #ifdef XR_INODE_TRACE fprintf(stderr, "processing inode %d/%d\n", agno, ino); #endif - return(process_dinode_int(mp, dino, agno, ino, was_free, dirty, - cleared, used, verify_mode, uncertain, - ino_discovery, check_dups, extra_attr_check, - isa_dir, parent)); + return process_dinode_int(mp, dino, agno, ino, was_free, dirty, used, + verify_mode, uncertain, ino_discovery, + check_dups, extra_attr_check, isa_dir, parent); } /* @@ -3027,25 +2876,24 @@ * if the inode passes the cursory sanity check, 1 otherwise. */ int -verify_dinode(xfs_mount_t *mp, - xfs_dinode_t *dino, - xfs_agnumber_t agno, - xfs_agino_t ino) -{ - xfs_ino_t parent; - int cleared = 0; - int used = 0; - int dirty = 0; - int isa_dir = 0; - const int verify_mode = 1; - const int check_dups = 0; - const int ino_discovery = 0; - const int uncertain = 0; - - return(process_dinode_int(mp, dino, agno, ino, 0, &dirty, - &cleared, &used, verify_mode, - uncertain, ino_discovery, check_dups, - 0, &isa_dir, &parent)); +verify_dinode( + xfs_mount_t *mp, + xfs_dinode_t *dino, + xfs_agnumber_t agno, + xfs_agino_t ino) +{ + xfs_ino_t parent; + int used = 0; + int dirty = 0; + int isa_dir = 0; + const int verify_mode = 1; + const int check_dups = 0; + const int ino_discovery = 0; + const int uncertain = 0; + + return process_dinode_int(mp, dino, agno, ino, 0, &dirty, &used, + verify_mode, uncertain, ino_discovery, + check_dups, 0, &isa_dir, &parent); } /* @@ -3054,23 +2902,22 @@ * returns 0 if the inode passes the cursory sanity check, 1 otherwise. */ int -verify_uncertain_dinode(xfs_mount_t *mp, - xfs_dinode_t *dino, - xfs_agnumber_t agno, - xfs_agino_t ino) -{ - xfs_ino_t parent; - int cleared = 0; - int used = 0; - int dirty = 0; - int isa_dir = 0; - const int verify_mode = 1; - const int check_dups = 0; - const int ino_discovery = 0; - const int uncertain = 1; - - return(process_dinode_int(mp, dino, agno, ino, 0, &dirty, - &cleared, &used, verify_mode, - uncertain, ino_discovery, check_dups, - 0, &isa_dir, &parent)); +verify_uncertain_dinode( + xfs_mount_t *mp, + xfs_dinode_t *dino, + xfs_agnumber_t agno, + xfs_agino_t ino) +{ + xfs_ino_t parent; + int used = 0; + int dirty = 0; + int isa_dir = 0; + const int verify_mode = 1; + const int check_dups = 0; + const int ino_discovery = 0; + const int uncertain = 1; + + return process_dinode_int(mp, dino, agno, ino, 0, &dirty, &used, + verify_mode, uncertain, ino_discovery, + check_dups, 0, &isa_dir, &parent); } Index: ci/xfsprogs/repair/dinode.h =================================================================== --- ci.orig/xfsprogs/repair/dinode.h 2007-11-16 14:45:56.000000000 +1100 +++ ci/xfsprogs/repair/dinode.h 2007-11-16 14:46:32.000000000 +1100 @@ -84,7 +84,6 @@ xfs_agino_t ino, int was_free, int *dirty, - int *tossit, int *used, int check_dirs, int check_dups, ------------KBCi25FieZfzpyKYHMgMHb Content-Disposition: attachment; filename=dir_size_check.patch Content-Type: text/x-patch; name=dir_size_check.patch Content-Transfer-Encoding: 7bit Index: repair/xfsprogs/repair/dinode.c =================================================================== --- repair.orig/xfsprogs/repair/dinode.c +++ repair/xfsprogs/repair/dinode.c @@ -1937,6 +1937,11 @@ process_check_inode_sizes( dinoc->di_format, size, lino); return 1; } + if (size > XFS_DIR2_LEAF_OFFSET) { + do_warn(_("directory inode %llu has bad size %lld\n"), + lino, size); + return 1; + } break; case XR_INO_SYMLINK: ------------KBCi25FieZfzpyKYHMgMHb Content-Disposition: attachment; filename=fix_dir_rebuild_without_dotdot_entry.patch Content-Type: text/x-patch; name=fix_dir_rebuild_without_dotdot_entry.patch Content-Transfer-Encoding: 7bit Index: repair/xfsprogs/repair/phase6.c =================================================================== --- repair.orig/xfsprogs/repair/phase6.c +++ repair/xfsprogs/repair/phase6.c @@ -36,6 +36,40 @@ static struct fsxattr zerofsx; static xfs_ino_t orphanage_ino; /* + * Data structures used to keep track of directories where the ".." + * entries are updated. These must be rebuilt after the initial pass + */ +typedef struct dotdot_update { + struct dotdot_update *next; + ino_tree_node_t *irec; + xfs_agnumber_t agno; + int ino_offset; +} dotdot_update_t; + +static dotdot_update_t *dotdot_update_list; +static int dotdot_update; + +static void +add_dotdot_update( + xfs_agnumber_t agno, + ino_tree_node_t *irec, + int ino_offset) +{ + dotdot_update_t *dir = malloc(sizeof(dotdot_update_t)); + + if (!dir) + do_error(_("malloc failed add_dotdot_update (%u bytes)\n"), + sizeof(dotdot_update_t)); + + dir->next = dotdot_update_list; + dir->irec = irec; + dir->agno = agno; + dir->ino_offset = ino_offset; + + dotdot_update_list = dir; +} + +/* * Data structures and routines to keep track of directory entries * and whether their leaf entry has been seen. Also used for name * duplicate checking and rebuilding step if required. @@ -2276,6 +2310,13 @@ longform_dir2_entry_check_data( } /* + * if just scanning to rebuild a directory due to a ".." + * update, just continue + */ + if (dotdot_update) + continue; + + /* * skip the '..' entry since it's checked when the * directory is reached by something else. if it never * gets reached, it'll be moved to the orphanage and we'll @@ -2364,6 +2405,8 @@ _("entry \"%s\" in dir %llu points to an set_inode_parent(irec, ino_offset, ip->i_ino); add_inode_reached(irec, ino_offset); add_inode_ref(current_irec, current_ino_offset); + add_dotdot_update(XFS_INO_TO_AGNO(mp, inum), irec, + ino_offset); } else { junkit = 1; do_warn( @@ -2613,9 +2656,7 @@ longform_dir2_entry_check(xfs_mount_t *m dir_hash_tab_t *hashtab) { xfs_dir2_block_t *block; - xfs_dir2_leaf_entry_t *blp; xfs_dabuf_t **bplist; - xfs_dir2_block_tail_t *btp; xfs_dablk_t da_bno; freetab_t *freetab; int num_bps; @@ -2678,22 +2719,29 @@ longform_dir2_entry_check(xfs_mount_t *m } fixit = (*num_illegal != 0) || dir2_is_badino(ino) || *need_dot; - /* check btree and freespace */ - if (isblock) { - block = bplist[0]->data; - btp = XFS_DIR2_BLOCK_TAIL_P(mp, block); - blp = XFS_DIR2_BLOCK_LEAF_P(btp); - seeval = dir_hash_see_all(hashtab, blp, - INT_GET(btp->count, ARCH_CONVERT), - INT_GET(btp->stale, ARCH_CONVERT)); - if (dir_hash_check(hashtab, ip, seeval)) - fixit |= 1; - } else if (isleaf) { - fixit |= longform_dir2_check_leaf(mp, ip, hashtab, freetab); - } else { - fixit |= longform_dir2_check_node(mp, ip, hashtab, freetab); + if (!dotdot_update) { + /* check btree and freespace */ + if (isblock) { + xfs_dir2_block_tail_t *btp; + xfs_dir2_leaf_entry_t *blp; + + block = bplist[0]->data; + btp = XFS_DIR2_BLOCK_TAIL_P(mp, block); + blp = XFS_DIR2_BLOCK_LEAF_P(btp); + seeval = dir_hash_see_all(hashtab, blp, + be32_to_cpu(btp->count), + be32_to_cpu(btp->stale)); + if (dir_hash_check(hashtab, ip, seeval)) + fixit |= 1; + } else if (isleaf) { + fixit |= longform_dir2_check_leaf(mp, ip, hashtab, + freetab); + } else { + fixit |= longform_dir2_check_node(mp, ip, hashtab, + freetab); + } } - if (!no_modify && fixit) { + if (!no_modify && (fixit || dotdot_update)) { dir_hash_dup_names(hashtab); for (i = 0; i < freetab->naents; i++) if (bplist[i]) @@ -3141,6 +3189,23 @@ shortform_dir2_entry_check(xfs_mount_t * ASSERT(ip->i_d.di_size <= ifp->if_bytes); /* + * if just rebuild a directory due to a "..", update and return + */ + if (dotdot_update) { + parent = get_inode_parent(current_irec, current_ino_offset); + if (no_modify) { + do_warn(_("would set .. in sf dir inode %llu to %llu\n"), + ino, parent); + } else { + do_warn(_("setting .. in sf dir inode %llu to %llu\n"), + ino, parent); + XFS_DIR2_SF_PUT_INUMBER(sfp, &parent, &sfp->hdr.parent); + *ino_dirty = 1; + } + return; + } + + /* * no '.' entry in shortform dirs, just bump up ref count by 1 * '..' was already (or will be) accounted for and checked when * the directory is reached or will be taken care of when the @@ -3151,7 +3216,8 @@ shortform_dir2_entry_check(xfs_mount_t * /* * Initialise i8 counter -- the parent inode number counts as well. */ - i8 = (XFS_DIR2_SF_GET_INUMBER(sfp, &sfp->hdr.parent) > XFS_DIR2_MAX_SHORT_INUM); + i8 = (XFS_DIR2_SF_GET_INUMBER(sfp, &sfp->hdr.parent) > + XFS_DIR2_MAX_SHORT_INUM); /* * now run through entries, stop at first bad entry, don't need @@ -3283,6 +3349,7 @@ shortform_dir2_entry_check(xfs_mount_t * "duplicate name"), fname, lino, ino); goto do_junkit; } + if (!inode_isadir(irec, ino_offset)) { /* * check easy case first, regular inode, just bump @@ -3315,6 +3382,8 @@ shortform_dir2_entry_check(xfs_mount_t * set_inode_parent(irec, ino_offset, ino); add_inode_reached(irec, ino_offset); add_inode_ref(current_irec, current_ino_offset); + add_dotdot_update(XFS_INO_TO_AGNO(mp, lino), + irec, ino_offset); } else { junkit = 1; do_warn(_("entry \"%s\" in directory inode %llu" @@ -3432,10 +3501,11 @@ do_junkit: static void process_dir_inode( xfs_mount_t *mp, - xfs_ino_t ino, + xfs_agnumber_t agno, ino_tree_node_t *irec, int ino_offset) { + xfs_ino_t ino; xfs_bmap_free_t flist; xfs_fsblock_t first; xfs_inode_t *ip; @@ -3445,13 +3515,15 @@ process_dir_inode( int need_dot, committed; int dirty, num_illegal, error, nres; + ino = XFS_AGINO_TO_INO(mp, agno, irec->ino_startnum + ino_offset); + /* * open up directory inode, check all entries, * then call prune_dir_entries to remove all * remaining illegal directory entries. */ - ASSERT(!is_inode_refchecked(ino, irec, ino_offset)); + ASSERT(!is_inode_refchecked(ino, irec, ino_offset) || dotdot_update); error = libxfs_iget(mp, NULL, ino, 0, &ip, 0); if (error) { @@ -3853,15 +3925,32 @@ traverse_function( for (i = 0; i < XFS_INODES_PER_CHUNK; i++) { if (inode_isadir(irec, i)) - process_dir_inode(wq->mp, - XFS_AGINO_TO_INO(wq->mp, agno, - irec->ino_startnum + i), irec, i); + process_dir_inode(wq->mp, agno, irec, i); } } cleanup_inode_prefetch(pf_args); } static void +update_missing_dotdot_entries( + xfs_mount_t *mp) +{ + dotdot_update_t *dir; + + /* + * these entries parents were updated, rebuild them again + * set dotdot_update flag so processing routines do not count links + */ + dotdot_update = 1; + while (dotdot_update_list) { + dir = dotdot_update_list; + dotdot_update_list = dir->next; + process_dir_inode(mp, dir->agno, dir->irec, dir->ino_offset); + free(dir); + } +} + +static void traverse_ags( xfs_mount_t *mp) { @@ -3974,6 +4063,11 @@ _(" - resetting contents of realt */ traverse_ags(mp); + /* + * any directories that had updated ".." entries, rebuild them now + */ + update_missing_dotdot_entries(mp); + do_log(_(" - traversal finished ...\n")); do_log(_(" - moving disconnected inodes to %s ...\n"), ORPHANAGE); ------------KBCi25FieZfzpyKYHMgMHb-- From owner-xfs@oss.sgi.com Tue Jul 1 01:06:02 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Jul 2008 01:06:05 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m61861ON004902 for ; Tue, 1 Jul 2008 01:06:01 -0700 X-ASG-Debug-ID: 1214899622-269e028d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from deliver.uni-koblenz.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 09055185AC70 for ; Tue, 1 Jul 2008 01:07:02 -0700 (PDT) Received: from deliver.uni-koblenz.de (deliver.uni-koblenz.de [141.26.64.15]) by cuda.sgi.com with ESMTP id fUOn0Sp57SoaqrBx for ; Tue, 01 Jul 2008 01:07:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by deliver.uni-koblenz.de (Postfix) with ESMTP id 2C4DC7801972; Tue, 1 Jul 2008 10:07:02 +0200 (CEST) Received: from deliver.uni-koblenz.de ([127.0.0.1]) by localhost (deliver.uni-koblenz.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28283-04; Tue, 1 Jul 2008 10:07:01 +0200 (CEST) Received: from bruch.uni-koblenz.de (bruch.uni-koblenz.de [141.26.64.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTP id 14B127898220; Tue, 1 Jul 2008 10:07:01 +0200 (CEST) Message-ID: <4869E5A4.4020900@uni-koblenz.de> Date: Tue, 01 Jul 2008 10:07:00 +0200 From: Christoph Litauer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: markgw@sgi.com CC: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: rfc: kill ino64 mount option Subject: Re: rfc: kill ino64 mount option References: <20080627153928.GA31384@lst.de> <20080628000914.GE29319@disturbed> <486589E7.9010705@sgi.com> In-Reply-To: <486589E7.9010705@sgi.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: amavisd-new at uni-koblenz.de X-Barracuda-Connect: deliver.uni-koblenz.de[141.26.64.15] X-Barracuda-Start-Time: 1214899624 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=BSF_SC5_SA210e X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54841 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC5_SA210e Custom Rule SA210e X-Virus-Status: Clean X-archive-position: 16670 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: litauer@uni-koblenz.de Precedence: bulk X-list: xfs Mark Goodwin schrieb: > > > Dave Chinner wrote: >> On Fri, Jun 27, 2008 at 05:39:28PM +0200, Christoph Hellwig wrote: >>> Does anyone have objections to kill the ino64 mount option? It's purely >>> a debug tool to force inode numbers outside of the range representable >>> in 32bits and is quite invasive for something that could easily be >>> debugged by just having a large enough filesystem.. >> >> It's the "large enough fs" that is the problem. XFSQA uses >> small partitions for the most part, and this allows testing >> of 64 bit inode numbers with a standard qa config. >> >> That being said, I don't really if it goes or stays... > > Although ino64 has interoperability issues with 32bit apps, it does > have significant performance advantages over inode32 for some > storage topologies and workloads, i.e. it's generally desirable to > keep inodes near their data, but with large configs inode32 can't > always oblige. ino64 is not just a debug tool. > > We have a design proposal known as "inode32+" that essentially removes > the direct mapping between inode number and disk offset. This will > provide all the layout and performance benefits of ino64 without the > interop issues. Until inode32+ is available, we need to keep ino64. Hi, as I have massive performance problems using xfs with millions of inodes, I am very interested in this "incode32+". My server is a 32 bit machine, so I am not able to use inode64. Is it available? -- Regards Christoph ________________________________________________________________________ Christoph Litauer litauer@uni-koblenz.de Uni Koblenz, Computing Center, http://www.uni-koblenz.de/~litauer Postfach 201602, 56016 Koblenz Fon: +49 261 287-1311, Fax: -100 1311 PGP-Fingerprint: F39C E314 2650 650D 8092 9514 3A56 FBD8 79E3 27B2 From owner-xfs@oss.sgi.com Tue Jul 1 01:07:49 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Jul 2008 01:07:55 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m6187n0x005404 for ; Tue, 1 Jul 2008 01:07:49 -0700 X-ASG-Debug-ID: 1214899731-3e4200c70000-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 DC2CE2A242E for ; Tue, 1 Jul 2008 01:08:51 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 7hUteJ3rcpSyIIq5 for ; Tue, 01 Jul 2008 01:08:51 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1KDauq-0005rM-Sh; Tue, 01 Jul 2008 08:08:44 +0000 Date: Tue, 1 Jul 2008 04:08:44 -0400 From: Christoph Hellwig To: Takashi Sato Cc: akpm@linux-foundation.org, viro@ZenIV.linux.org.uk, "linux-ext4@vger.kernel.org" , "xfs@oss.sgi.com" , "dm-devel@redhat.com" , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , axboe@kernel.dk, mtk.manpages@googlemail.com X-ASG-Orig-Subj: Re: [PATCH 1/3] Implement generic freeze feature Subject: Re: [PATCH 1/3] Implement generic freeze feature Message-ID: <20080701080844.GA16691@infradead.org> References: <20080630212323t-sato@mail.jp.nec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080630212323t-sato@mail.jp.nec.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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: 1214899731 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=MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54841 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16671 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs > { > struct super_block *sb; > > + if (test_and_set_bit(BD_FREEZE_OP, &bdev->bd_state)) > + return ERR_PTR(-EBUSY); > + > + sb = get_super(bdev); > + > + /* If super_block has been already frozen, return. */ > + if (sb && sb->s_frozen != SB_UNFROZEN) { > + drop_super(sb); > + clear_bit(BD_FREEZE_OP, &bdev->bd_state); > + return sb; > + } > + > + if (sb) > + drop_super(sb); > + > down(&bdev->bd_mount_sem); > sb = get_super(bdev); > if (sb && !(sb->s_flags & MS_RDONLY)) { > @@ -219,6 +234,8 @@ struct super_block *freeze_bdev(struct b > } > > sync_blockdev(bdev); > + clear_bit(BD_FREEZE_OP, &bdev->bd_state); > + Please only clear BD_FREEZE_OP in thaw_bdev, that way you can also get rid of the frozen check above, and the double-get_super. Also bd_mount_sem could be removed that way by checking for BD_FREEZE_OP in the unmount path. > /* > + * ioctl_freeze - Freeze the filesystem. > + * > + * @filp: target file > + * > + * Call freeze_bdev() to freeze the filesystem. > + */ This is not a kerneldoc comment. But I think it can be simply removed anyway, as it's a quite trivial function with static scope. > +/* > + * ioctl_thaw - Thaw the filesystem. > + * > + * @filp: target file > + * > + * Call thaw_bdev() to thaw the filesystem. > + */ Same here. From owner-xfs@oss.sgi.com Tue Jul 1 01:09:28 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Jul 2008 01:09:30 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m6189R8q005956 for ; Tue, 1 Jul 2008 01:09:27 -0700 X-ASG-Debug-ID: 1214899830-7cb501320000-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 A5431D7ED8E for ; Tue, 1 Jul 2008 01:10:30 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id 4qIVDGZTKMniZ4Vf for ; Tue, 01 Jul 2008 01:10:30 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1KDawU-0002q5-OJ; Tue, 01 Jul 2008 08:10:26 +0000 Date: Tue, 1 Jul 2008 04:10:26 -0400 From: Christoph Hellwig To: Takashi Sato Cc: akpm@linux-foundation.org, viro@ZenIV.linux.org.uk, "linux-ext4@vger.kernel.org" , "xfs@oss.sgi.com" , "dm-devel@redhat.com" , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" , axboe@kernel.dk, mtk.manpages@googlemail.com X-ASG-Orig-Subj: Re: [PATCH 3/3] Add timeout feature Subject: Re: [PATCH 3/3] Add timeout feature Message-ID: <20080701081026.GB16691@infradead.org> References: <20080630212450t-sato@mail.jp.nec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080630212450t-sato@mail.jp.nec.com> User-Agent: Mutt/1.5.18 (2008-05-17) 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: 1214899830 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.1, rules version 3.1.54842 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16672 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs I still disagree with this whole patch. There is not reason to let the freeze request timeout - an auto-unfreezing will only confuse the hell out of the caller. The only reason where the current XFS freeze call can hang and this would be theoretically useful is when the filesystem is already frozen by someone else, but this should be fixed by refusing to do the second freeze, as suggested in my comment to patch 1. From owner-xfs@oss.sgi.com Tue Jul 1 01:12:05 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Jul 2008 01:12:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m618C4nd006602 for ; Tue, 1 Jul 2008 01:12:04 -0700 X-ASG-Debug-ID: 1214899987-5e21014a0000-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 482A0184F5B4; Tue, 1 Jul 2008 01:13:07 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id tA5t0MK1wz7BdDcK; Tue, 01 Jul 2008 01:13:07 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1KDaz4-0005FR-V1; Tue, 01 Jul 2008 08:13:06 +0000 Date: Tue, 1 Jul 2008 04:13:06 -0400 From: Christoph Hellwig To: Barry Naujok Cc: "xfs@oss.sgi.com" X-ASG-Orig-Subj: Re: REVIEW: xfs_repair fixes for bad directories Subject: Re: REVIEW: xfs_repair fixes for bad directories Message-ID: <20080701081306.GA11135@infradead.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) 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: 1214899987 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.1, rules version 3.1.54841 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16673 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs On Tue, Jul 01, 2008 at 06:00:17PM +1000, Barry Naujok wrote: > Two issues have been encounted with xfs_repair and badly corrupted > directories. > > 1. A huge size (inode di_size) can cause malloc which will fail. > Patch dir_size_check.patch checks for a valid directory size > and if it's bad, junks the directory. The di_size for a dir > only counts the data blocks being used, not all the other > associated metadata. This is limited to 32GB by the > XFS_DIR2_LEAF_OFFSET value in XFS. Anything greater than this > must be invalid. This one looks good. > 2. An update a while ago to xfs_repair attempts to fix invalid > ".." entries for subdirectories where there is a valid parent > with the appropriate entry. It was a partial fix that never > did the full job, especially if the subdirectory was short- > form or it has already been processed. > > Patch fix_dir_rebuild_without_dotdot_entry.patch creates a > post-processing queue after the main scan to update any > directories with an invalid ".." entry. For this one I'll need to read the surrounding code first to do a useful review, so it'll take some time. From owner-xfs@oss.sgi.com Tue Jul 1 01:29:16 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Jul 2008 01:29:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=ANY_BOUNCE_MESSAGE,AWL, BAYES_20,VBOUNCE_MESSAGE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m618TGAn007918 for ; Tue, 1 Jul 2008 01:29:16 -0700 X-ASG-Debug-ID: 1214901018-3e4501a20000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from omr-m23.mx.aol.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 881662A2373 for ; Tue, 1 Jul 2008 01:30:18 -0700 (PDT) Received: from omr-m23.mx.aol.com (omr-m23.mx.aol.com [64.12.136.131]) by cuda.sgi.com with ESMTP id SFpePFG5K2iMJWWk for ; Tue, 01 Jul 2008 01:30:18 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from rly-df05.mx.aol.com (rly-df05.mx.aol.com [205.188.252.9]) by omr-m23.mx.aol.com (v117.7) with ESMTP id MAILOMRM235-7e004869eb0c378; Tue, 01 Jul 2008 04:30:04 -0400 Received: from localhost (localhost) by rly-df05.mx.aol.com (8.14.1/8.14.1) id m618Tu00009417; Tue, 1 Jul 2008 04:30:04 -0400 Date: Tue, 1 Jul 2008 04:30:04 -0400 From: Mail Delivery Subsystem Message-Id: <200807010830.m618Tu00009417@rly-df05.mx.aol.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="m618Tu00009417.1214901004/rly-df05.mx.aol.com" X-ASG-Orig-Subj: Returned mail: see transcript for details Subject: Returned mail: see transcript for details Auto-Submitted: auto-generated (failure) X-AOL-INRLY: net-50-114.mweb.co.za [196.211.50.114] rly-df05 X-AOL-IP: 205.188.252.9 X-Barracuda-Connect: omr-m23.mx.aol.com[64.12.136.131] X-Barracuda-Start-Time: 1214901019 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16674 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: MAILER-DAEMON@aol.com Precedence: bulk X-list: xfs This is a MIME-encapsulated message --m618Tu00009417.1214901004/rly-df05.mx.aol.com The original message was received at Tue, 1 Jul 2008 04:29:37 -0400 from net-50-114.mweb.co.za [196.211.50.114] *** ATTENTION *** Your e-mail is being returned to you because there was a problem with its delivery. The address which was undeliverable is listed in the section labeled: "----- The following addresses had permanent fatal errors -----". The reason your mail is being returned to you is listed in the section labeled: "----- Transcript of Session Follows -----". The line beginning with "<<<" describes the specific reason your e-mail could not be delivered. The next line contains a second error message which is a general translation for other e-mail servers. Please direct further questions regarding this message to your e-mail administrator. --AOL Postmaster ----- The following addresses had permanent fatal errors ----- (reason: 554 TRANSACTION FAILED - Unrepairable Virus Detected. Your mail has not been sent.) ----- Transcript of session follows ----- ... while talking to air-df08.mail.aol.com.: >>> DATA <<< 554 TRANSACTION FAILED - Unrepairable Virus Detected. Your mail has not been sent. 554 5.0.0 Service unavailable --m618Tu00009417.1214901004/rly-df05.mx.aol.com Content-Type: message/delivery-status Reporting-MTA: dns; rly-df05.mx.aol.com Arrival-Date: Tue, 1 Jul 2008 04:29:37 -0400 Final-Recipient: RFC822; winningtouch@aol.com Action: failed Status: 5.0.0 Remote-MTA: DNS; air-df08.mail.aol.com Diagnostic-Code: SMTP; 554 TRANSACTION FAILED - Unrepairable Virus Detected. Your mail has not been sent. Last-Attempt-Date: Tue, 1 Jul 2008 04:30:04 -0400 --m618Tu00009417.1214901004/rly-df05.mx.aol.com Content-Type: text/rfc822-headers Received: from oss.sgi.com (net-50-114.mweb.co.za [196.211.50.114]) by rly-df05.mx.aol.com (v121.5) with ESMTP id MAILRELAYINDF051-54c4869eae839b; Tue, 01 Jul 2008 04:29:33 -0400 From: linux-xfs@oss.sgi.com To: winningtouch@aol.com Subject: Delivery reports about your e-mail Date: Tue, 1 Jul 2008 10:29:26 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0006_D08D677A.98F7EAF5" 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 X-AOL-IP: 196.211.50.114 X-AOL-SCOLL-SCORE:0:2:265791696:9395240 X-AOL-SCOLL-URL_COUNT: X-AOL-SCOLL-AUTHENTICATION: listenair ; SPF_helo : n X-AOL-SCOLL-AUTHENTICATION: listenair ; SPF_822_from : n Message-ID: <200807010429.54c4869eae839b@rly-df05.mx.aol.com> --m618Tu00009417.1214901004/rly-df05.mx.aol.com-- From owner-xfs@oss.sgi.com Tue Jul 1 02:11:41 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Jul 2008 02:11:45 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,STOX_REPLY_TYPE autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m619Be0W010394 for ; Tue, 1 Jul 2008 02:11:41 -0700 X-ASG-Debug-ID: 1214903562-305d00ee0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from tyo201.gate.nec.co.jp (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0611FD7F2B7 for ; Tue, 1 Jul 2008 02:12:42 -0700 (PDT) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by cuda.sgi.com with ESMTP id 5Cl7B57YTwXbvMY0 for ; Tue, 01 Jul 2008 02:12:42 -0700 (PDT) Received: from mailgate4.nec.co.jp ([10.7.69.184]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id m619CXiZ022778; Tue, 1 Jul 2008 18:12:33 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id m619CXw03868; Tue, 1 Jul 2008 18:12:33 +0900 (JST) Received: from kuichi.jp.nec.com (kuichi.jp.nec.com [10.26.220.17]) by mailsv4.nec.co.jp (8.13.8/8.13.4) with ESMTP id m619CWbR005745; Tue, 1 Jul 2008 18:12:32 +0900 (JST) Received: from TNESB07336 ([10.64.168.65] [10.64.168.65]) by mail.jp.nec.com with ESMTP; Tue, 1 Jul 2008 18:12:32 +0900 Message-Id: <6B16FAEFB450496A9AA95BFF27BD6AE6@nsl.ad.nec.co.jp> From: "Takashi Sato" To: "Alasdair G Kergon" Cc: , , , , , , , , References: <20080630212005t-sato@mail.jp.nec.com> <20080630135433.GA22522@agk.fab.redhat.com> In-Reply-To: <20080630135433.GA22522@agk.fab.redhat.com> X-ASG-Orig-Subj: Re: [dm-devel] [PATCH 0/3] freeze feature ver 1.8 Subject: Re: [dm-devel] [PATCH 0/3] freeze feature ver 1.8 Date: Tue, 1 Jul 2008 18:12:32 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-Barracuda-Connect: TYO201.gate.nec.co.jp[202.32.8.193] X-Barracuda-Start-Time: 1214903563 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.1, rules version 3.1.54846 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16675 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: t-sato@yk.jp.nec.com Precedence: bulk X-list: xfs Hi, Alasdair G Kergon wrote: >> Currently, ext3 in mainline Linux doesn't have the freeze feature which >> suspends write requests. So, we cannot take a backup which keeps >> the filesystem's consistency with the storage device's features >> (snapshot and replication) while it is mounted. >> In many case, a commercial filesystem (e.g. VxFS) has >> the freeze feature and it would be used to get the consistent backup. >> If Linux's standard filesytem ext3 has the freeze feature, we can do it >> without a commercial filesystem. > > Is the following a fair summary? Yes, you are right. We'd like to use the freeze feature without device-mapper/LVM. > 1. Some filesystems have a freeze/thaw feature. XFS exports this to > userspace directly through a couple of ioctls, but other filesystems > don't. For filesystems on device-mapper block devices it is exported to > userspace through the DM_DEV_SUSPEND ioctl which LVM uses. > > 2. There is a desire to access this feature from userspace on non-XFS > filesystems without having to use device-mapper/LVM. > > Alasdair Cheers, Takashi From owner-xfs@oss.sgi.com Tue Jul 1 03:52:00 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Jul 2008 03:52:07 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m61Aq0QT016501 for ; Tue, 1 Jul 2008 03:52:00 -0700 X-ASG-Debug-ID: 1214909580-69f8015a0000-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 84451123A92A for ; Tue, 1 Jul 2008 03:53:00 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com with ESMTP id ntehcwwXRHrqHbHK for ; Tue, 01 Jul 2008 03:53:00 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m61AqrNK027962; Tue, 1 Jul 2008 06:52:53 -0400 Received: from pobox.fab.redhat.com (pobox.fab.redhat.com [10.33.63.12]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m61Aqpik013057; Tue, 1 Jul 2008 06:52:52 -0400 Received: from agk.fab.redhat.com (agk.fab.redhat.com [10.33.0.19]) by pobox.fab.redhat.com (8.13.1/8.13.1) with ESMTP id m61AqpHv015837; Tue, 1 Jul 2008 06:52:51 -0400 Received: from agk by agk.fab.redhat.com with local (Exim 4.34) id 1KDdTf-0005Sz-6u; Tue, 01 Jul 2008 11:52:51 +0100 Date: Tue, 1 Jul 2008 11:52:51 +0100 From: Alasdair G Kergon To: Takashi Sato Cc: Christoph Hellwig , axboe@kernel.dk, mtk.manpages@googlemail.com, "linux-kernel@vger.kernel.org" , "xfs@oss.sgi.com" , "dm-devel@redhat.com" , viro@ZenIV.linux.org.uk, "linux-fsdevel@vger.kernel.org" , akpm@linux-foundation.org, "linux-ext4@vger.kernel.org" X-ASG-Orig-Subj: Re: [dm-devel] Re: [PATCH 3/3] Add timeout feature Subject: Re: [dm-devel] Re: [PATCH 3/3] Add timeout feature Message-ID: <20080701105251.GC22522@agk.fab.redhat.com> Mail-Followup-To: Takashi Sato , Christoph Hellwig , axboe@kernel.dk, mtk.manpages@googlemail.com, "linux-kernel@vger.kernel.org" , "xfs@oss.sgi.com" , "dm-devel@redhat.com" , viro@ZenIV.linux.org.uk, "linux-fsdevel@vger.kernel.org" , akpm@linux-foundation.org, "linux-ext4@vger.kernel.org" References: <20080630212450t-sato@mail.jp.nec.com> <20080701081026.GB16691@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080701081026.GB16691@infradead.org> User-Agent: Mutt/1.4.1i Organization: Red Hat UK Ltd. Registered in England and Wales, number 03798903. Registered Office: Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE. X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-Barracuda-Connect: mx1.redhat.com[66.187.233.31] X-Barracuda-Start-Time: 1214909583 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16676 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: agk@redhat.com Precedence: bulk X-list: xfs On Tue, Jul 01, 2008 at 04:10:26AM -0400, Christoph Hellwig wrote: > I still disagree with this whole patch. Same here - if you want a timeout, what stops you from implementing it in a userspace process? If your concern is that the process might die without thawing the filesystem, take a look at the userspace LVM/multipath code for ideas - lock into memory, disable OOM killer, run from ramdisk etc. In practice, those techniques seem to be good enough. > call can hang and this would be theoretically useful is when the > filesystem is already frozen by someone else, but this should be fixed > by refusing to do the second freeze, as suggested in my comment to patch > 1. Similarly if a device-mapper device is involved, how should the following sequence behave - A, B or C? 1. dmsetup suspend (freezes) 2. FIFREEZE 3. FITHAW 4. dmsetup resume (thaws) A: 1 succeeds, freezes 2 succeeds, remains frozen 3 succeeds, remains frozen 4 succeeds, thaws B: 1 succeeds, freezes 2 fails, remains frozen 3 shouldn't be called because 2 failed but if it is: succeeds, thaws 4 succeeds (already thawed, but still does the device-mapper parts) C: 1 succeeds, freezes 2 fails, remains frozen 3 fails (because device-mapper owns the freeze/thaw), remains frozen 4 succeeds, thaws Alasdair -- agk@redhat.com From owner-xfs@oss.sgi.com Tue Jul 1 07:12:34 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Jul 2008 07:12:39 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m61EBuEL002280 for ; Tue, 1 Jul 2008 07:12:33 -0700 Received: from [134.15.251.2] (melb-sw-corp-251-2.corp.sgi.com [134.15.251.2]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id AAA01516; Wed, 2 Jul 2008 00:12:46 +1000 Message-ID: <486A3B5B.20402@sgi.com> Date: Wed, 02 Jul 2008 00:12:43 +1000 From: Mark Goodwin Reply-To: markgw@sgi.com Organization: SGI Engineering User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Christoph Litauer CC: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: rfc: kill ino64 mount option References: <20080627153928.GA31384@lst.de> <20080628000914.GE29319@disturbed> <486589E7.9010705@sgi.com> <4869E5A4.4020900@uni-koblenz.de> In-Reply-To: <4869E5A4.4020900@uni-koblenz.de> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16677 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: markgw@sgi.com Precedence: bulk X-list: xfs Christoph Litauer wrote: > Mark Goodwin schrieb: > .. >> We have a design proposal known as "inode32+" that essentially removes >> the direct mapping between inode number and disk offset. This will >> provide all the layout and performance benefits of ino64 without the >> interop issues. Until inode32+ is available, we need to keep ino64. > > Hi, > > as I have massive performance problems using xfs with millions of > inodes, I am very interested in this "incode32+". can you please post some details of the problems you're seeing? > My server is a 32 bit machine, so I am not able to use inode64. > Is it available? inode32+ is only a design at the moment. An implementation is several months away. Until then, you'll have to update your server to 64bit. Thanks -- Mark From owner-xfs@oss.sgi.com Tue Jul 1 07:44:10 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Jul 2008 07:44:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m61Ei9gM004650 for ; Tue, 1 Jul 2008 07:44:10 -0700 X-ASG-Debug-ID: 1214923510-4d26019e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from deliver.uni-koblenz.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1032D2A4684 for ; Tue, 1 Jul 2008 07:45:10 -0700 (PDT) Received: from deliver.uni-koblenz.de (deliver.uni-koblenz.de [141.26.64.15]) by cuda.sgi.com with ESMTP id Vr1ESNTtDBUP33I0 for ; Tue, 01 Jul 2008 07:45:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by deliver.uni-koblenz.de (Postfix) with ESMTP id C193C789A3D6; Tue, 1 Jul 2008 16:45:09 +0200 (CEST) Received: from deliver.uni-koblenz.de ([127.0.0.1]) by localhost (deliver.uni-koblenz.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26174-06; Tue, 1 Jul 2008 16:45:08 +0200 (CEST) Received: from bruch.uni-koblenz.de (bruch.uni-koblenz.de [141.26.64.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by deliver.uni-koblenz.de (Postfix) with ESMTP id 143BF789A177; Tue, 1 Jul 2008 16:45:08 +0200 (CEST) Message-ID: <486A42F3.3090207@uni-koblenz.de> Date: Tue, 01 Jul 2008 16:45:07 +0200 From: Christoph Litauer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: markgw@sgi.com CC: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: rfc: kill ino64 mount option Subject: Re: rfc: kill ino64 mount option References: <20080627153928.GA31384@lst.de> <20080628000914.GE29319@disturbed> <486589E7.9010705@sgi.com> <4869E5A4.4020900@uni-koblenz.de> <486A3B5B.20402@sgi.com> In-Reply-To: <486A3B5B.20402@sgi.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: amavisd-new at uni-koblenz.de X-Barracuda-Connect: deliver.uni-koblenz.de[141.26.64.15] X-Barracuda-Start-Time: 1214923512 X-Barracuda-Bayes: INNOCENT GLOBAL 0.1099 1.0000 -1.3335 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.33 X-Barracuda-Spam-Status: No, SCORE=-1.33 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=BSF_SC5_SA210e X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54866 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC5_SA210e Custom Rule SA210e X-Virus-Status: Clean X-archive-position: 16678 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: litauer@uni-koblenz.de Precedence: bulk X-list: xfs Mark Goodwin schrieb: > > > Christoph Litauer wrote: >> Mark Goodwin schrieb: >> .. >>> We have a design proposal known as "inode32+" that essentially removes >>> the direct mapping between inode number and disk offset. This will >>> provide all the layout and performance benefits of ino64 without the >>> interop issues. Until inode32+ is available, we need to keep ino64. >> >> Hi, >> >> as I have massive performance problems using xfs with millions of >> inodes, I am very interested in this "incode32+". > > can you please post some details of the problems you're seeing? Please see thread "Performance problems with millions of inodes". If you don't have it anymore, I can send it to you. > >> My server is a 32 bit machine, so I am not able to use inode64. >> Is it available? > > inode32+ is only a design at the moment. An implementation is several > months away. Until then, you'll have to update your server to 64bit. This is, sadly, not an option at the moment ... -- Regards Christoph ________________________________________________________________________ Christoph Litauer litauer@uni-koblenz.de Uni Koblenz, Computing Center, http://www.uni-koblenz.de/~litauer Postfach 201602, 56016 Koblenz Fon: +49 261 287-1311, Fax: -100 1311 PGP-Fingerprint: F39C E314 2650 650D 8092 9514 3A56 FBD8 79E3 27B2 From owner-xfs@oss.sgi.com Tue Jul 1 08:14:41 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Jul 2008 08:14:44 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_52 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m61FEerY007384 for ; Tue, 1 Jul 2008 08:14:41 -0700 X-ASG-Debug-ID: 1214925342-4d2402fd0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sovereign.computergmbh.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1498F2A4A08 for ; Tue, 1 Jul 2008 08:15:42 -0700 (PDT) Received: from sovereign.computergmbh.de (sovereign.computergmbh.de [85.214.69.204]) by cuda.sgi.com with ESMTP id DrSSskCD9XhUYagD for ; Tue, 01 Jul 2008 08:15:42 -0700 (PDT) Received: by sovereign.computergmbh.de (Postfix, from userid 25121) id E92CA18032F4A; Tue, 1 Jul 2008 17:15:40 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by sovereign.computergmbh.de (Postfix) with ESMTP id E19871C0E7213 for ; Tue, 1 Jul 2008 17:15:40 +0200 (CEST) Date: Tue, 1 Jul 2008 17:15:40 +0200 (CEST) From: Jan Engelhardt To: xfs@oss.sgi.com X-ASG-Orig-Subj: grub fails boot after update Subject: grub fails boot after update Message-ID: User-Agent: Alpine 1.10 (LNX 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Barracuda-Connect: sovereign.computergmbh.de[85.214.69.204] X-Barracuda-Start-Time: 1214925343 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0002 1.0000 -2.0195 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.1, rules version 3.1.54869 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16679 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jengelh@medozas.de Precedence: bulk X-list: xfs From Novell Bugzilla, I gather that XFS has a serious problem with grub. Since I'd like to keep XFS for the time being, is there any way to fix this issue, or make dead sure that a given file is on disk? Like ioctl(fd, XFS_FLUSH_I_MEAN_IT)? ---------- Forwarded message ---------- https://bugzilla.novell.com/show_bug.cgi?id=223773 --- Comment #39 2008-07-01 08:44:49 MDT --- I agree with comment #37: XFS really does suck, especially when it comes to booting Linux on a PC. Fortunately we do not support it any more for new installations, an ext2 /boot partition is highly recommended. The problem is that with XFS, sync(2) returns, but the data isn't synced. The first time yast calls grub install, grub does not find the new stage1.5, because it is not on the disk yet, despite a successful sync; thus it modifies stage2 to do the job. On the second invocation, stage1.5 is found and installed, but stage2 already is modified. So once again this isn't a grub bug, but an XFS bug with FS semantics. From owner-xfs@oss.sgi.com Tue Jul 1 08:48:55 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Jul 2008 08:48:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m61FmtS3014919 for ; Tue, 1 Jul 2008 08:48:55 -0700 X-ASG-Debug-ID: 1214927396-153700570000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from filer.fsl.cs.sunysb.edu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 60C231BAADDE; Tue, 1 Jul 2008 08:49:57 -0700 (PDT) Received: from filer.fsl.cs.sunysb.edu (filer.fsl.cs.sunysb.edu [130.245.126.2]) by cuda.sgi.com with ESMTP id sTmWh6PidrY4kK7P; Tue, 01 Jul 2008 08:49:57 -0700 (PDT) Received: from josefsipek.net (baal.fsl.cs.sunysb.edu [130.245.126.78]) by filer.fsl.cs.sunysb.edu (8.12.11.20060308/8.13.8) with ESMTP id m61Fnj7e023020; Tue, 1 Jul 2008 11:49:46 -0400 Received: by josefsipek.net (Postfix, from userid 1000) id 6044B1C00D88; Tue, 1 Jul 2008 11:49:46 -0400 (EDT) Date: Tue, 1 Jul 2008 11:49:46 -0400 From: "Josef 'Jeff' Sipek" To: Niv Sardi , xfs@oss.sgi.com, Niv Sardi X-ASG-Orig-Subj: Re: [PATCH] Give a transaction to xfs_attr_set_int Subject: Re: [PATCH] Give a transaction to xfs_attr_set_int Message-ID: <20080701154946.GB20383@josefsipek.net> References: <1214196150-5427-1-git-send-email-xaiki@sgi.com> <1214196150-5427-2-git-send-email-xaiki@sgi.com> <1214196150-5427-3-git-send-email-xaiki@sgi.com> <1214196150-5427-4-git-send-email-xaiki@sgi.com> <1214196150-5427-5-git-send-email-xaiki@sgi.com> <20080629220859.GL29319@disturbed> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080629220859.GL29319@disturbed> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: filer.fsl.cs.sunysb.edu[130.245.126.2] X-Barracuda-Start-Time: 1214927397 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.1, rules version 3.1.54873 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16680 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jeffpc@josefsipek.net Precedence: bulk X-list: xfs On Mon, Jun 30, 2008 at 08:08:59AM +1000, Dave Chinner wrote: ... > > @@ -356,6 +381,8 @@ xfs_attr_set_int(xfs_inode_t *dp, const char *name, int namelen, > > if (!error && (flags & ATTR_KERNOTIME) == 0) { > > xfs_ichgtime(dp, XFS_ICHGTIME_CHG); > > } > > + if (tpp) > > + tpp = &args.trans; > > That's busted too. Can you please review all the places where you > return transactio pointers to the caller via a function parameterrr > for this bug as you've made in at least a couple of places. Niv: Why not return the pointer as a return value? Josef 'Jeff' Sipek. -- Humans were created by water to transport it upward. From owner-xfs@oss.sgi.com Tue Jul 1 08:54:20 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Jul 2008 08:54:23 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: *** X-Spam-Status: No, score=3.0 required=5.0 tests=BAYES_50,HTML_MESSAGE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m61FsKbk015537 for ; Tue, 1 Jul 2008 08:54:20 -0700 X-ASG-Debug-ID: 1214927721-0bad01240000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from edge.itt.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 73D1012D2C62 for ; Tue, 1 Jul 2008 08:55:21 -0700 (PDT) Received: from edge.itt.com (edge.itt.com [151.190.254.13]) by cuda.sgi.com with ESMTP id ONFV2UKkSzBzVYSn for ; Tue, 01 Jul 2008 08:55:21 -0700 (PDT) Received: from fwexhub3.itt.net (10.32.76.113) by edge.itt.com (10.32.16.13) with Microsoft SMTP Server (TLS) id 8.1.278.0; Tue, 1 Jul 2008 11:55:10 -0400 Received: from corpchsert01.edocorp.com (10.240.16.17) by fwexhub3.itt.net (10.32.76.113) with Microsoft SMTP Server (TLS) id 8.1.278.0; Tue, 1 Jul 2008 11:55:21 -0400 Received: from corpchsefe01.edocorp.com ([10.240.16.22]) by corpchsert01.edocorp.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Jul 2008 11:56:05 -0400 Received: from corpistert01.edocorp.com ([10.244.194.17]) by corpchsefe01.edocorp.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Jul 2008 11:56:04 -0400 Received: from corpistemb01.edocorp.com ([10.244.194.14]) by corpistert01.edocorp.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Jul 2008 11:56:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 MIME-Version: 1.0 X-ASG-Orig-Subj: XFS Compatibility Questions Subject: XFS Compatibility Questions Date: Tue, 1 Jul 2008 11:54:50 -0400 Message-ID: <0EEA30D7D649274EB38B0B140022557F23B36C@corpistemb01.edocorp.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: XFS Compatibility Questions Thread-Index: AcjbksuaLgg19kLgRYm2fT61/hoe0g== From: "Arensdorf, Christopher" To: X-OriginalArrivalTime: 01 Jul 2008 15:56:04.0678 (UTC) FILETIME=[F7A87660:01C8DB92] X-Barracuda-Connect: edge.itt.com[151.190.254.13] X-Barracuda-Start-Time: 1214927722 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4997 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 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.1, rules version 3.1.54872 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 7bit Content-length: 1446 X-archive-position: 16681 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Chris.Arensdorf@itt.com Precedence: bulk X-list: xfs Hello, My name is Chris and I'm with ITT Corporation in Nashua, NH. We're currently looking to upgrade one of our products to make use of InfiniBand technology, and unfortunately we're running QFS which does not support InfiniBand. We're interested in exploring the idea of using XFS so I had a few questions I was hoping you might be able to answer that I didn't seem to find in the FAQ section. Is XFS compatible with InfiniBand? Is XFS compatible with RHEL 5.0 or higher? Is XFS compatible with Fibre Channel? Is XFS compatible with Solaris 10 x86? Thanks very much for your time and I look forward to hearing back from you. Chris Arensdorf ITT Corporation 85 Northwest Blvd Nashua, NH 03063 Ph: (603) 459-2290 (Direct) Ph: (603) 459-2200 (Main) chris.arensdorf@edocorp.com ________________________________ This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of ITT Corporation. The recipient should check this e-mail and any attachments for the presence of viruses. ITT accepts no liability for any damage caused by any virus transmitted by this e-mail. [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Tue Jul 1 08:54:20 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Jul 2008 08:54:24 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m61FsK10015547 for ; Tue, 1 Jul 2008 08:54:20 -0700 X-ASG-Debug-ID: 1214927723-158702170000-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 B2BE82A4DF4 for ; Tue, 1 Jul 2008 08:55:23 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id o2aCQAMFSN3UPp2K for ; Tue, 01 Jul 2008 08:55:23 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1KDiCQ-00084C-GL; Tue, 01 Jul 2008 15:55:22 +0000 Date: Tue, 1 Jul 2008 11:55:22 -0400 From: Christoph Hellwig To: Jan Engelhardt Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: grub fails boot after update Subject: Re: grub fails boot after update Message-ID: <20080701155522.GA29722@infradead.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) 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: 1214927723 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.1, rules version 3.1.54873 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16682 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@infradead.org Precedence: bulk X-list: xfs sync works perfectly fine on xfs. Grub just doesn't understand what sync means, and because of that it's buggy on all filesystems, just with less a chance on others. The fix is pretty simple and that is stopping to try to access the filesystem with it's own driver through the block device node. From owner-xfs@oss.sgi.com Tue Jul 1 18:58:39 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Jul 2008 18:58:43 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m621wYZj030941 for ; Tue, 1 Jul 2008 18:58:37 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id LAA16381; Wed, 2 Jul 2008 11:59:20 +1000 Message-ID: <486AE0F8.5080506@sgi.com> Date: Wed, 02 Jul 2008 11:59:20 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Mark Goodwin CC: Christoph Hellwig , Lachlan McIlroy , xfs-dev , xfs-oss Subject: Re: [PATCH] Fix use after free when closing log/rt devices References: <48647746.5010007@sgi.com> <20080627063219.GA25015@infradead.org> <48648B2B.3080709@sgi.com> <20080627090822.GA17374@infradead.org> In-Reply-To: <20080627090822.GA17374@infradead.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16683 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Christoph Hellwig wrote: > On Fri, Jun 27, 2008 at 04:39:39PM +1000, Mark Goodwin wrote: >> do we have any QA tests that test external log? > > Most QA tests will use the external log if you set it up that way. But > ithout slab poisoning this won't be noticed either. I think you need: USE_EXTERNAL=yes SCRATCH_LOGDEV=somelogdevice TEST_LOGDEV=somelogdevice to get the scratch and test mounts using an external log. There are no explicit external log tests (logdev=) that I can see. --Tim From owner-xfs@oss.sgi.com Tue Jul 1 19:53:55 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Jul 2008 19:53:57 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m622rtVV001504 for ; Tue, 1 Jul 2008 19:53:55 -0700 X-ASG-Debug-ID: 1214967296-4995018b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6C4071860317 for ; Tue, 1 Jul 2008 19:54:57 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id 6KUdSymz7qdWpfBu for ; Tue, 01 Jul 2008 19:54:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALaJakh5LBzp/2dsb2JhbACyPw X-IronPort-AV: E=Sophos;i="4.27,735,1204464600"; d="scan'208";a="140003910" Received: from ppp121-44-28-233.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.28.233]) by ipmail01.adl6.internode.on.net with ESMTP; 02 Jul 2008 12:24:55 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KDsUg-0003m9-Cw; Wed, 02 Jul 2008 12:54:54 +1000 Date: Wed, 2 Jul 2008 12:54:54 +1000 From: Dave Chinner To: Timothy Shimmin Cc: Mark Goodwin , Christoph Hellwig , Lachlan McIlroy , xfs-dev , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] Fix use after free when closing log/rt devices Subject: Re: [PATCH] Fix use after free when closing log/rt devices Message-ID: <20080702025454.GW29319@disturbed> Mail-Followup-To: Timothy Shimmin , Mark Goodwin , Christoph Hellwig , Lachlan McIlroy , xfs-dev , xfs-oss References: <48647746.5010007@sgi.com> <20080627063219.GA25015@infradead.org> <48648B2B.3080709@sgi.com> <20080627090822.GA17374@infradead.org> <486AE0F8.5080506@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <486AE0F8.5080506@sgi.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1214967298 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=MARKETING_SUBJECT X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.54916 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 MARKETING_SUBJECT Subject contains popular marketing words X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16684 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Wed, Jul 02, 2008 at 11:59:20AM +1000, Timothy Shimmin wrote: > Christoph Hellwig wrote: > > On Fri, Jun 27, 2008 at 04:39:39PM +1000, Mark Goodwin wrote: > >> do we have any QA tests that test external log? > > > > Most QA tests will use the external log if you set it up that way. But > > ithout slab poisoning this won't be noticed either. > > I think you need: > USE_EXTERNAL=yes > SCRATCH_LOGDEV=somelogdevice > TEST_LOGDEV=somelogdevice > to get the scratch and test mounts using an external log. Yes. Typically I used to use SCRATCH_LOGDEV=/dev/ram0 so I didn't need another block device on the machine just for an external log on a throw-away filesystem.... > There are no explicit external log tests (logdev=) that I can see. It should be easy to write one using files and multiple loopback devices. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Tue Jul 1 20:42:02 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Jul 2008 20:42:10 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m623fxr3008701 for ; Tue, 1 Jul 2008 20:42:00 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id NAA18319; Wed, 2 Jul 2008 13:42:58 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1116) id 0250058C4C29; Wed, 2 Jul 2008 13:42:57 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 983964 - fix mount option parsing in remount Message-Id: <20080702034258.0250058C4C29@chook.melbourne.sgi.com> Date: Wed, 2 Jul 2008 13:42:57 +1000 (EST) From: tes@sgi.com (Tim Shimmin) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16685 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Fix mount option parsing in remount. Remount currently happily accept any option thrown at it, although the only filesystem specific option it actually handles is barrier/nobarrier. And it actually doesn't handle these correctly either because it only uses the value it parsed when we're doing a ro->rw transition. In addition to that there's also a bad bug in xfs_parseargs which doesn't touch the actual option in the mount point except for a single one, XFS_MOUNT_SMALL_INUMS and thus forced any filesystem that's every remounted in some way to not support 64bit inodes with no way to recover unless unmounted. This patch changes xfs_fs_remount to use it's own linux/parser.h based options parse instead of xfs_parseargs and reject all options except for barrier/nobarrier and to the right thing in general. Eventually I'd like to have a single big option table used for mount aswell but that can wait for a while. Signed-off-by: Christoph Hellwig Date: Wed Jul 2 13:41:58 AEST 2008 Workarea: chook.melbourne.sgi.com:/build/tes/2.6.x-xfs-quilt Inspected by: hch@lst.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:31382a fs/xfs/linux-2.6/xfs_super.c - 1.434 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_super.c.diff?r1=text&tr1=1.434&r2=text&tr2=1.433&f=h - fix mount option parsing in remount From owner-xfs@oss.sgi.com Tue Jul 1 21:17:51 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Jul 2008 21:17:55 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m624HnCB010902 for ; Tue, 1 Jul 2008 21:17:51 -0700 X-ASG-Debug-ID: 1214972331-235301510000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bby1mta03.pmc-sierra.bc.ca (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 4904FD80B3F for ; Tue, 1 Jul 2008 21:18:51 -0700 (PDT) Received: from bby1mta03.pmc-sierra.bc.ca (bby1mta03.pmc-sierra.com [216.241.235.118]) by cuda.sgi.com with ESMTP id W6hCAbKDnJsQ8LlT for ; Tue, 01 Jul 2008 21:18:51 -0700 (PDT) Received: from bby1mta03.pmc-sierra.bc.ca (localhost.pmc-sierra.bc.ca [127.0.0.1]) by localhost (Postfix) with SMTP id 6159610704C3 for ; Tue, 1 Jul 2008 21:21:24 -0700 (PDT) Received: from bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca (BBY1EXG02.pmc-sierra.bc.ca [216.241.231.167]) by bby1mta03.pmc-sierra.bc.ca (Postfix) with SMTP id 1779610703BC for ; Tue, 1 Jul 2008 21:21:22 -0700 (PDT) Received: from BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca ([216.241.231.156]) by bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Jul 2008 21:19:24 -0700 Received: from [209.68.166.73] ([209.68.166.73]) by BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca with Microsoft SMTPSVC(6.0.3790.2825); Tue, 1 Jul 2008 21:19:23 -0700 Message-ID: <486B01A6.4030104@pmc-sierra.com> Date: Wed, 02 Jul 2008 09:48:46 +0530 From: Sagar Borikar Organization: PMC Sierra Inc User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Sagar Borikar , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Xfs Access to block zero exception and system crash Subject: Re: Xfs Access to block zero exception and system crash References: <20080625084931.GI16257@build-svl-1.agami.com> <340C71CD25A7EB49BFA81AE8C839266701323BE8@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080626070215.GI11558@disturbed> <4864BD5D.1050202@pmc-sierra.com> <4864C001.2010308@pmc-sierra.com> <20080628000516.GD29319@disturbed> <340C71CD25A7EB49BFA81AE8C8392667028A1CA7@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080629215647.GJ29319@disturbed> <20080630034112.055CF18904C4@bby1mta01.pmc-sierra.bc.ca> <4868B46C.9000200@pmc-sierra.com> <20080701064437.GR29319@disturbed> In-Reply-To: <20080701064437.GR29319@disturbed> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jul 2008 04:19:24.0141 (UTC) FILETIME=[CF0271D0:01C8DBFA] X-PMX-Version: 5.4.2.338381, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.7.2.40440 X-PMC-SpamCheck: Gauge=IIIIIII, Probability=7%, Report='BODY_SIZE_1300_1399 0, BODY_SIZE_5000_LESS 0, __BOUNCE_CHALLENGE_SUBJ 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' X-Barracuda-Connect: bby1mta03.pmc-sierra.com[216.241.235.118] X-Barracuda-Start-Time: 1214972332 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4130 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 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.1, rules version 3.1.54920 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16686 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sagar_borikar@pmc-sierra.com Precedence: bulk X-list: xfs Dave Chinner wrote: > On Mon, Jun 30, 2008 at 03:54:44PM +0530, Sagar Borikar wrote: > >> After running my test for 20 min, when I check the fragmentation status >> of file system, I observe that it >> is severely fragmented. >> > > Depends on your definition of fragmentation.... > > >> [root@NAS001ee5ab9c85 ~]# xfs_db -c frag -r /dev/RAIDA/vol >> actual 94343, ideal 107, fragmentation factor 99.89% >> > > And that one is a bad one ;) > > Still, there are a lot of extents - ~1000 to a file - which > will be stressing the btree extent format code. > > >> Do you think, this can cause the issue? >> > > Sure - just like any other workload that generates enough > extents. Like I said originally, we've fixed so many problems > in this code since 2.6.18 I'd suggest that your only sane > hope for us to help you track done the problem is to upgrade > to a current kernel and go from there.... > > Cheers,, > > Dave. > Thanks again Dave. But we can't upgrade the kernel as it is already in production and on field. So do you think, periodic cleaning of file system using xfs_fsr can solve the issue? If not, could you kindly direct me what all patches were fixing similar problem? I can try back porting them. Thanks Sagar From owner-xfs@oss.sgi.com Tue Jul 1 22:12:39 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Jul 2008 22:12:40 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m625CcBU013973 for ; Tue, 1 Jul 2008 22:12:38 -0700 X-ASG-Debug-ID: 1214975619-436302710000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6648118597D3 for ; Tue, 1 Jul 2008 22:13:39 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id xh9PaNPGl2nEPnse for ; Tue, 01 Jul 2008 22:13:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPqoakh5LBzp/2dsb2JhbACyHw X-IronPort-AV: E=Sophos;i="4.27,735,1204464600"; d="scan'208";a="140102806" Received: from ppp121-44-28-233.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.28.233]) by ipmail01.adl6.internode.on.net with ESMTP; 02 Jul 2008 14:43:38 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KDuev-0006jG-Fs; Wed, 02 Jul 2008 15:13:37 +1000 Date: Wed, 2 Jul 2008 15:13:37 +1000 From: Dave Chinner To: Sagar Borikar Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Xfs Access to block zero exception and system crash Subject: Re: Xfs Access to block zero exception and system crash Message-ID: <20080702051337.GX29319@disturbed> Mail-Followup-To: Sagar Borikar , xfs@oss.sgi.com References: <20080626070215.GI11558@disturbed> <4864BD5D.1050202@pmc-sierra.com> <4864C001.2010308@pmc-sierra.com> <20080628000516.GD29319@disturbed> <340C71CD25A7EB49BFA81AE8C8392667028A1CA7@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080629215647.GJ29319@disturbed> <20080630034112.055CF18904C4@bby1mta01.pmc-sierra.bc.ca> <4868B46C.9000200@pmc-sierra.com> <20080701064437.GR29319@disturbed> <486B01A6.4030104@pmc-sierra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <486B01A6.4030104@pmc-sierra.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1214975621 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3523 1.0000 -0.1448 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.14 X-Barracuda-Spam-Status: No, SCORE=-0.14 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.1, rules version 3.1.54923 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16687 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Wed, Jul 02, 2008 at 09:48:46AM +0530, Sagar Borikar wrote: > Dave Chinner wrote: >> On Mon, Jun 30, 2008 at 03:54:44PM +0530, Sagar Borikar wrote: >> Sure - just like any other workload that generates enough >> extents. Like I said originally, we've fixed so many problems >> in this code since 2.6.18 I'd suggest that your only sane >> hope for us to help you track done the problem is to upgrade >> to a current kernel and go from there.... >> > Thanks again Dave. But we can't upgrade the kernel as it is already in > production and on field. Yes, but you can run it in your test environment where you are reproducing this problem, right? > So do you think, periodic cleaning of file system using xfs_fsr can > solve the issue? No, at best it would only delay the problem (whatever it is). > If not, could you > kindly direct me what all patches were fixing similar problem? I can try > back porting them. I don't have time to try to identify some set of changes from the past 3-4 years that might fix your problem. There may not even be a patch that fixes your problem, which is one of the reasons why I've asked if you can reproduce it on a current kernel.... I pointed you the files that the bug could lie in earlier in the thread. You can find the history of changes to those files via the mainline git repository or via the XFS CVS repository. You'd probably do best to look at the git tree because all the changes are well described in the commit logs and you should be able to isolate ones that fix btree problems fairly easily... Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Tue Jul 1 22:34:44 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Jul 2008 22:34:47 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m625Yg7d015697 for ; Tue, 1 Jul 2008 22:34:44 -0700 X-ASG-Debug-ID: 1214976944-310903e60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bby1mta02.pmc-sierra.bc.ca (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 49111D8107D for ; Tue, 1 Jul 2008 22:35:45 -0700 (PDT) Received: from bby1mta02.pmc-sierra.bc.ca (bby1mta02.pmc-sierra.com [216.241.235.117]) by cuda.sgi.com with ESMTP id qFXhqzqvzD8QsATh for ; Tue, 01 Jul 2008 22:35:45 -0700 (PDT) Received: from bby1mta02.pmc-sierra.bc.ca (localhost.pmc-sierra.bc.ca [127.0.0.1]) by localhost (Postfix) with SMTP id 495D08E0246 for ; Tue, 1 Jul 2008 22:38:19 -0700 (PDT) Received: from bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca (BBY1EXG02.pmc-sierra.bc.ca [216.241.231.167]) by bby1mta02.pmc-sierra.bc.ca (Postfix) with SMTP id 4025D8E023C for ; Tue, 1 Jul 2008 22:38:19 -0700 (PDT) Received: from BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca ([216.241.231.156]) by bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca with Microsoft SMTPSVC(6.0.3790.3959); Tue, 1 Jul 2008 22:36:20 -0700 Received: from [209.68.166.73] ([209.68.166.73]) by BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca with Microsoft SMTPSVC(6.0.3790.2825); Tue, 1 Jul 2008 22:36:19 -0700 Message-ID: <486B13AD.2010500@pmc-sierra.com> Date: Wed, 02 Jul 2008 11:05:41 +0530 From: Sagar Borikar Organization: PMC Sierra Inc User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Sagar Borikar , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Xfs Access to block zero exception and system crash Subject: Re: Xfs Access to block zero exception and system crash References: <20080626070215.GI11558@disturbed> <4864BD5D.1050202@pmc-sierra.com> <4864C001.2010308@pmc-sierra.com> <20080628000516.GD29319@disturbed> <340C71CD25A7EB49BFA81AE8C8392667028A1CA7@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080629215647.GJ29319@disturbed> <20080630034112.055CF18904C4@bby1mta01.pmc-sierra.bc.ca> <4868B46C.9000200@pmc-sierra.com> <20080701064437.GR29319@disturbed> <486B01A6.4030104@pmc-sierra.com> <20080702051337.GX29319@disturbed> In-Reply-To: <20080702051337.GX29319@disturbed> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jul 2008 05:36:20.0111 (UTC) FILETIME=[8E5791F0:01C8DC05] X-Barracuda-Connect: bby1mta02.pmc-sierra.com[216.241.235.117] X-Barracuda-Start-Time: 1214976945 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4868 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 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.1, rules version 3.1.54926 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16688 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sagar_borikar@pmc-sierra.com Precedence: bulk X-list: xfs Dave Chinner wrote: > On Wed, Jul 02, 2008 at 09:48:46AM +0530, Sagar Borikar wrote: > >> Dave Chinner wrote: >> >>> On Mon, Jun 30, 2008 at 03:54:44PM +0530, Sagar Borikar wrote: >>> Sure - just like any other workload that generates enough >>> extents. Like I said originally, we've fixed so many problems >>> in this code since 2.6.18 I'd suggest that your only sane >>> hope for us to help you track done the problem is to upgrade >>> to a current kernel and go from there.... >>> >>> >> Thanks again Dave. But we can't upgrade the kernel as it is already in >> production and on field. >> > > Yes, but you can run it in your test environment where you are > reproducing this problem, right? > > Unfortunately the architecture is customized mips for which the standard kernel port is not available and we have to port the new kernel in order to try this which is why I was hesitating to do this. >> So do you think, periodic cleaning of file system using xfs_fsr can >> solve the issue? >> > > No, at best it would only delay the problem (whatever it is). > > >> If not, could you >> kindly direct me what all patches were fixing similar problem? I can try >> back porting them. >> > > I don't have time to try to identify some set of changes from the > past 3-4 years that might fix your problem. There may not even be a > patch that fixes your problem, which is one of the reasons why I've > asked if you can reproduce it on a current kernel.... > > I pointed you the files that the bug could lie in earlier in the > thread. You can find the history of changes to those files via the > mainline git repository or via the XFS CVS repository. You'd > probably do best to look at the git tree because all the changes are > well described in the commit logs and you should be able to isolate > ones that fix btree problems fairly easily... > > Cheers, > > Dave. > Sure I'll go through these changelogs. Thanks for all your help and really appreciate your time. I hope you don't mind to help me in future if I find something new :) Regards, Sagar From owner-xfs@oss.sgi.com Tue Jul 1 23:13:29 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Jul 2008 23:13:42 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m626DSSY018353 for ; Tue, 1 Jul 2008 23:13:29 -0700 X-ASG-Debug-ID: 1214979270-79f602900000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from postoffice2.aconex.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0541718607AE for ; Tue, 1 Jul 2008 23:14:30 -0700 (PDT) Received: from postoffice2.aconex.com (prod.aconex.com [203.89.192.138]) by cuda.sgi.com with ESMTP id A78DuKs9sroIDqmm for ; Tue, 01 Jul 2008 23:14:30 -0700 (PDT) Received: from postoffice.aconex.com (localhost [127.0.0.1]) by postoffice2.aconex.com (Spam Firewall) with ESMTP id 8522D2DA56C; Wed, 2 Jul 2008 16:14:25 +1000 (EST) Received: from postoffice.aconex.com (postoffice.yarra.acx [192.168.3.1]) by postoffice2.aconex.com with ESMTP id baqKr9sjY5amGsbW; Wed, 02 Jul 2008 16:14:25 +1000 (EST) Received: from [192.168.0.100] (c220-239-214-222.fernt2.vic.optusnet.com.au [220.239.214.222]) by postoffice.aconex.com (Postfix) with ESMTP id 4D77C92C0E3; Wed, 2 Jul 2008 16:14:25 +1000 (EST) X-ASG-Orig-Subj: Re: Xfs Access to block zero exception and system crash Subject: Re: Xfs Access to block zero exception and system crash From: Nathan Scott To: Sagar Borikar Cc: xfs@oss.sgi.com In-Reply-To: <486B13AD.2010500@pmc-sierra.com> References: <20080626070215.GI11558@disturbed> <4864BD5D.1050202@pmc-sierra.com> <4864C001.2010308@pmc-sierra.com> <20080628000516.GD29319@disturbed> <340C71CD25A7EB49BFA81AE8C8392667028A1CA7@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080629215647.GJ29319@disturbed> <20080630034112.055CF18904C4@bby1mta01.pmc-sierra.bc.ca> <4868B46C.9000200@pmc-sierra.com> <20080701064437.GR29319@disturbed> <486B01A6.4030104@pmc-sierra.com> <20080702051337.GX29319@disturbed> <486B13AD.2010500@pmc-sierra.com> Content-Type: text/plain Date: Wed, 02 Jul 2008 16:13:11 +1000 Message-Id: <1214979191.6025.22.camel@verge.scott.net.au> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: prod.aconex.com[203.89.192.138] X-Barracuda-Start-Time: 1214979271 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0024 1.0000 -2.0055 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.1, rules version 3.1.54927 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16689 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: nscott@aconex.com Precedence: bulk X-list: xfs On Wed, 2008-07-02 at 11:05 +0530, Sagar Borikar wrote: > > Unfortunately the architecture is customized mips for which the > standard > kernel port is > not available and we have to port the new kernel in order to try > this > which is why I was > hesitating to do this. You can always try the reverse - replace fs/xfs from your mips build tree with the one from the current/a recent kernel. Theres very few changes in the surrounding kernel code that xfs needs. cheers. -- Nathan From owner-xfs@oss.sgi.com Tue Jul 1 23:37:11 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Jul 2008 23:37:15 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m626b7LE020112 for ; Tue, 1 Jul 2008 23:37:09 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA21948; Wed, 2 Jul 2008 16:38:00 +1000 Message-ID: <486B2248.5080400@sgi.com> Date: Wed, 02 Jul 2008 16:38:00 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Niv Sardi CC: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: [PATCH] Move attr log alloc size calculator to another function. References: <1214196150-5427-1-git-send-email-xaiki@sgi.com> <1214196150-5427-2-git-send-email-xaiki@sgi.com> <20080626082438.GB23954@infradead.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16690 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Niv Sardi wrote: > Attached updated patch. > > Christoph Hellwig writes: >> On Mon, Jun 23, 2008 at 02:42:27PM +1000, Niv Sardi wrote: >>> From: Niv Sardi >>> >>> We will need that to be able to calculate the size of log we need for >>> a specific attr (for parent pointers in create). We need the local so >>> that we can fail if we run into ENOSPC when trying to alloc blocks > > Updated Comments, structs instead of typdefs > >>> Signed-off-by: Niv Sardi >>> --- >>> fs/xfs/xfs_attr.c | 78 +++++++++++++++++++++++++++++++--------------------- >>> fs/xfs/xfs_attr.h | 2 +- >>> 2 files changed, 47 insertions(+), 33 deletions(-) >>> >>> diff --git a/fs/xfs/xfs_attr.c b/fs/xfs/xfs_attr.c >>> index e58f321..0d19e90 100644 >>> --- a/fs/xfs/xfs_attr.c >>> +++ b/fs/xfs/xfs_attr.c >>> @@ -185,6 +185,43 @@ xfs_attr_get( >>> } >>> >>> int >>> +xfs_attr_calc_size( >> should be marked STATIC, > > The whole idea is to be able to use it in xfs_create(). > I guess in isolation it just looks weird as the only caller is within the file. In isolation it would make sense to be STATIC. (Then again, in isolation, it looks strange returning the "local" parameter - as you said, you need it elsewhere). And I guess, Christoph's point was that it could go in as an isolated cleanup patch if it was made static. --Tim From owner-xfs@oss.sgi.com Tue Jul 1 23:56:09 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 01 Jul 2008 23:56:13 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m626u7FV021416 for ; Tue, 1 Jul 2008 23:56:09 -0700 X-ASG-Debug-ID: 1214981830-7488016d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from build-svl-1.agami.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CDD0A2A6978 for ; Tue, 1 Jul 2008 23:57:10 -0700 (PDT) Received: from build-svl-1.agami.com (colo-nat-pool.agami.com [216.218.227.40]) by cuda.sgi.com with ESMTP id fAr2CMyef5nfFFET for ; Tue, 01 Jul 2008 23:57:10 -0700 (PDT) Received: from build-svl-1.agami.com (localhost.localdomain [127.0.0.1]) by build-svl-1.agami.com (8.13.7/8.13.7) with ESMTP id m626utqG004043; Tue, 1 Jul 2008 23:56:55 -0700 Received: (from dchinner@localhost) by build-svl-1.agami.com (8.13.7/8.13.7/Submit) id m626uqri004042; Tue, 1 Jul 2008 23:56:52 -0700 X-Authentication-Warning: build-svl-1.agami.com: dchinner set sender to dchinner@agami.com using -f Date: Tue, 1 Jul 2008 23:56:52 -0700 From: Dave Chinner To: Nathan Scott Cc: Sagar Borikar , xfs@oss.sgi.com, sandeen@sandeen.net X-ASG-Orig-Subj: Re: Xfs Access to block zero exception and system crash Subject: Re: Xfs Access to block zero exception and system crash Message-ID: <20080702065652.GS14251@build-svl-1.agami.com> Mail-Followup-To: Nathan Scott , Sagar Borikar , xfs@oss.sgi.com, sandeen@sandeen.net References: <20080628000516.GD29319@disturbed> <340C71CD25A7EB49BFA81AE8C8392667028A1CA7@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080629215647.GJ29319@disturbed> <20080630034112.055CF18904C4@bby1mta01.pmc-sierra.bc.ca> <4868B46C.9000200@pmc-sierra.com> <20080701064437.GR29319@disturbed> <486B01A6.4030104@pmc-sierra.com> <20080702051337.GX29319@disturbed> <486B13AD.2010500@pmc-sierra.com> <1214979191.6025.22.camel@verge.scott.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1214979191.6025.22.camel@verge.scott.net.au> User-Agent: Mutt/1.4.2.3i X-Barracuda-Connect: colo-nat-pool.agami.com[216.218.227.40] X-Barracuda-Start-Time: 1214981830 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0002 1.0000 -2.0195 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.1, rules version 3.1.54929 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16691 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dchinner@agami.com Precedence: bulk X-list: xfs On Wed, Jul 02, 2008 at 04:13:11PM +1000, Nathan Scott wrote: > On Wed, 2008-07-02 at 11:05 +0530, Sagar Borikar wrote: > > > > Unfortunately the architecture is customized mips for which the > > standard > > kernel port is > > not available and we have to port the new kernel in order to try > > this > > which is why I was > > hesitating to do this. > > You can always try the reverse - replace fs/xfs from your mips build > tree with the one from the current/a recent kernel. Theres very few > changes in the surrounding kernel code that xfs needs. Eric should be able to comment on the pitfalls in doing this having tried to backport a 2.6.25 fs/xfs to a 2.6.18 RHEL kernel. Eric - any comments? Cheers, Dave. -- Dave Chinner dchinner@agami.com From owner-xfs@oss.sgi.com Wed Jul 2 00:13:26 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 02 Jul 2008 00:13:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m627DKs2025195 for ; Wed, 2 Jul 2008 00:13:22 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA22889; Wed, 2 Jul 2008 17:14:18 +1000 Message-ID: <486B2ACA.2050506@sgi.com> Date: Wed, 02 Jul 2008 17:14:18 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Niv Sardi CC: xfs@oss.sgi.com Subject: Re: [PATCH] Move xfs_attr_rolltrans to xfs_trans_roll References: <1214196150-5427-1-git-send-email-xaiki@sgi.com> <1214196150-5427-2-git-send-email-xaiki@sgi.com> <1214196150-5427-3-git-send-email-xaiki@sgi.com> In-Reply-To: <1214196150-5427-3-git-send-email-xaiki@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16692 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Niv Sardi wrote: > Move it from the attr code to the transaction code and make the attr > code call the new function. > > We rolltrans is really usefull whenever we want to use rolling > transaction, should be generic, it isn't dependent on any part of the > attr code anyway. > So you just have some renames on calls and change where func definition is located. And you've added comments. > +/* > + * Roll from one trans in the sequence of PERMANENT transactions to > + * the next: permanent transactions are only flushed out when commited > + * with XFS_TRANS_RELEASE_LOG_RES, but we still want as soon as > + * possible to let chunks of it go to the log. So we commit the chunck > + * we've been working on and get a new transaction to continue. > + */ typos: s/chunck/chunk/ s/commited/committed/ --Tim From owner-xfs@oss.sgi.com Wed Jul 2 01:24:38 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 02 Jul 2008 01:25:03 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m628OZef001976 for ; Wed, 2 Jul 2008 01:24:37 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA24539; Wed, 2 Jul 2008 18:25:26 +1000 Message-ID: <486B3B76.8020303@sgi.com> Date: Wed, 02 Jul 2008 18:25:26 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Niv Sardi CC: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: [PATCH] Introduce xfs_trans_bmap_add_attrfork. References: <1214196150-5427-1-git-send-email-xaiki@sgi.com> <1214196150-5427-2-git-send-email-xaiki@sgi.com> <1214196150-5427-3-git-send-email-xaiki@sgi.com> <1214196150-5427-4-git-send-email-xaiki@sgi.com> <20080626092856.GA27069@infradead.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16693 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Niv Sardi wrote: > Updated patch attached, > Moved case where there is no transaction back into > xfs_bmap_add_attrfork() and rely on caller to call xfs_trans_roll(), > > Christoph Hellwig writes: >>> +xfs_bmap_add_attrfork( > [...] >> Care to add this below xfs_trans_bmap_add_attrfork? Also please >> us struct xfs_inode instead of the typedef. > > Done, > >>> + if (tpp) { >>> + ASSERT(*tpp); >>> + tp = *tpp; >>> + } else { > [...] >> I think it would be much cleaner if all the transaction setup, joining >> etc was done in xfs_bmap_add_attrfork, and xfs_trans_bmap_add_attrfork >> just gets an always non-NULL xfs_trans pointer. That would mean >> the common code would become just a helper, and >> xfs_trans_bmap_add_attrfork would be a small wrapper including the >> xfs_trans_roll. Alternatively the caller could always do the roll. > > I think I got it right, but error handeling is a bit weird this way, > looks logically identical. > > > > ------------------------------------------------------------------------ > > > Thanks for this extensive review =) > > + if (error) > + goto error1; > + > + if (XFS_IFORK_Q(ip)) > + goto error1; > + > + ASSERT(ip->i_d.di_anextents == 0); > + VN_HOLD(XFS_ITOV(ip)); > + xfs_trans_ijoin(tp, ip, XFS_ILOCK_EXCL); > + xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); > + > + error = xfs_trans_bmap_add_attrfork(NULL, ip, size, rsvd); > + if (error) > + return error; > + return xfs_trans_commit(tp, XFS_TRANS_PERM_LOG_RES); I was kind of expecting the transaction, &tp, to be passed into xfs_trans_bmap_add_attrfork(). (And then xfs_trans_bmap_add_attrfork() which calls xfs_bmap_finish() which calls xfs_trans_dup() and so from that point on we would then have to update tp if we were to use it.) So how come we pass in NULL? I'm tired so I'm probably missing something obvious. --Tim From owner-xfs@oss.sgi.com Wed Jul 2 04:02:02 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 02 Jul 2008 04:02:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m62B20WU012270 for ; Wed, 2 Jul 2008 04:02:02 -0700 X-ASG-Debug-ID: 1214996582-6cb802fe0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bby1mta01.pmc-sierra.bc.ca (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 23A89D82AEC for ; Wed, 2 Jul 2008 04:03:02 -0700 (PDT) Received: from bby1mta01.pmc-sierra.bc.ca (bby1mta01.pmc-sierra.com [216.241.235.116]) by cuda.sgi.com with ESMTP id egSCjQAobVNjBnYh for ; Wed, 02 Jul 2008 04:03:02 -0700 (PDT) Received: from bby1mta01.pmc-sierra.bc.ca (localhost.pmc-sierra.bc.ca [127.0.0.1]) by localhost (Postfix) with SMTP id DBBA91890433; Wed, 2 Jul 2008 04:06:05 -0700 (PDT) Received: from bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca (BBY1EXG02.pmc-sierra.bc.ca [216.241.231.167]) by bby1mta01.pmc-sierra.bc.ca (Postfix) with SMTP id CF0BB1890426; Wed, 2 Jul 2008 04:06:05 -0700 (PDT) Received: from BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca ([216.241.231.156]) by bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Jul 2008 04:03:37 -0700 Received: from [209.68.166.73] ([209.68.166.73]) by BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca with Microsoft SMTPSVC(6.0.3790.2825); Wed, 2 Jul 2008 04:03:37 -0700 Message-ID: <486B6062.6040201@pmc-sierra.com> Date: Wed, 02 Jul 2008 16:32:58 +0530 From: Sagar Borikar Organization: PMC Sierra Inc User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Nathan Scott , Sagar Borikar , xfs@oss.sgi.com, sandeen@sandeen.net X-ASG-Orig-Subj: Re: Xfs Access to block zero exception and system crash Subject: Re: Xfs Access to block zero exception and system crash References: <20080628000516.GD29319@disturbed> <340C71CD25A7EB49BFA81AE8C8392667028A1CA7@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080629215647.GJ29319@disturbed> <20080630034112.055CF18904C4@bby1mta01.pmc-sierra.bc.ca> <4868B46C.9000200@pmc-sierra.com> <20080701064437.GR29319@disturbed> <486B01A6.4030104@pmc-sierra.com> <20080702051337.GX29319@disturbed> <486B13AD.2010500@pmc-sierra.com> <1214979191.6025.22.camel@verge.scott.net.au> <20080702065652.GS14251@build-svl-1.agami.com> In-Reply-To: <20080702065652.GS14251@build-svl-1.agami.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jul 2008 11:03:37.0269 (UTC) FILETIME=[47001650:01C8DC33] X-Barracuda-Connect: bby1mta01.pmc-sierra.com[216.241.235.116] X-Barracuda-Start-Time: 1214996583 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0069 1.0000 -1.9760 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.98 X-Barracuda-Spam-Status: No, SCORE=-1.98 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.1, rules version 3.1.54944 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16694 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sagar_borikar@pmc-sierra.com Precedence: bulk X-list: xfs Dave Chinner wrote: > On Wed, Jul 02, 2008 at 04:13:11PM +1000, Nathan Scott wrote: > >> On Wed, 2008-07-02 at 11:05 +0530, Sagar Borikar wrote: >> >>> Unfortunately the architecture is customized mips for which the >>> standard >>> kernel port is >>> not available and we have to port the new kernel in order to try >>> this >>> which is why I was >>> hesitating to do this. >>> >> You can always try the reverse - replace fs/xfs from your mips build >> tree with the one from the current/a recent kernel. Theres very few >> changes in the surrounding kernel code that xfs needs. >> > > Eric should be able to comment on the pitfalls in doing this having > tried to backport a 2.6.25 fs/xfs to a 2.6.18 RHEL kernel. Eric - > any comments? > > Cheers, > > Dave. > Eric, Could you please let me know about bits and pieces that we need to remember while back porting xfs to 2.6.18? If you share patches which takes care of it, that would be great. Thanks Sagar From owner-xfs@oss.sgi.com Wed Jul 2 12:21:07 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 02 Jul 2008 12:21:15 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m62JL6pF024974 for ; Wed, 2 Jul 2008 12:21:07 -0700 X-ASG-Debug-ID: 1215026528-1e8802510000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B652E186317B for ; Wed, 2 Jul 2008 12:22:08 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id BegmWCwKjpfuogWC for ; Wed, 02 Jul 2008 12:22:08 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m62JLxNW018879 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 2 Jul 2008 21:21:59 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m62JLxEW018877 for xfs@oss.sgi.com; Wed, 2 Jul 2008 21:21:59 +0200 Date: Wed, 2 Jul 2008 21:21:59 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: "a" and "foo" files in the top dir of linux-2.6-xfs Subject: "a" and "foo" files in the top dir of linux-2.6-xfs Message-ID: <20080702192159.GA18817@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1215026529 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.1, rules version 3.1.54978 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16695 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs There's two empty files named "a" and "foo" in the top level directory of linux-2.6-xfs. cvs log claims they're Niv's faul with some really strange commit messages.. From owner-xfs@oss.sgi.com Wed Jul 2 12:21:31 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 02 Jul 2008 12:21:41 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m62JLV6X025031 for ; Wed, 2 Jul 2008 12:21:31 -0700 X-ASG-Debug-ID: 1215026553-796003a60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 553461863193 for ; Wed, 2 Jul 2008 12:22:33 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id vbxtqEwJpka1o69e for ; Wed, 02 Jul 2008 12:22:33 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m62JMONW018914 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 2 Jul 2008 21:22:24 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m62JMOn8018912 for xfs@oss.sgi.com; Wed, 2 Jul 2008 21:22:24 +0200 Date: Wed, 2 Jul 2008 21:22:24 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH] kill XFS_PURGE_INODE Subject: Re: [PATCH] kill XFS_PURGE_INODE Message-ID: <20080702192224.GB18817@lst.de> References: <20080616062634.GA5971@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080616062634.GA5971@lst.de> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1215026554 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.1, rules version 3.1.54978 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16696 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Ping? Already got a review from Dave. On Mon, Jun 16, 2008 at 08:26:34AM +0200, Christoph Hellwig wrote: > Just a useless alias for IRELE. > > > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/quota/xfs_qm.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_qm.c 2008-06-05 20:21:04.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/quota/xfs_qm.c 2008-06-05 20:22:37.000000000 +0200 > @@ -444,11 +444,11 @@ xfs_qm_unmount_quotas( > } > } > if (uqp) { > - XFS_PURGE_INODE(uqp); > + IRELE(uqp); > mp->m_quotainfo->qi_uquotaip = NULL; > } > if (gqp) { > - XFS_PURGE_INODE(gqp); > + IRELE(gqp); > mp->m_quotainfo->qi_gquotaip = NULL; > } > out: > @@ -1239,11 +1239,11 @@ xfs_qm_destroy_quotainfo( > xfs_qm_list_destroy(&qi->qi_dqlist); > > if (qi->qi_uquotaip) { > - XFS_PURGE_INODE(qi->qi_uquotaip); > + IRELE(qi->qi_uquotaip); > qi->qi_uquotaip = NULL; /* paranoia */ > } > if (qi->qi_gquotaip) { > - XFS_PURGE_INODE(qi->qi_gquotaip); > + IRELE(qi->qi_gquotaip); > qi->qi_gquotaip = NULL; > } > mutex_destroy(&qi->qi_quotaofflock); > @@ -1393,7 +1393,7 @@ xfs_qm_qino_alloc( > * locked exclusively and joined to the transaction already. > */ > ASSERT(xfs_isilocked(*ip, XFS_ILOCK_EXCL)); > - VN_HOLD(XFS_ITOV((*ip))); > + IHOLD(*ip); > > /* > * Make the changes in the superblock, and log those too. > Index: linux-2.6-xfs/fs/xfs/quota/xfs_qm_syscalls.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_qm_syscalls.c 2008-05-23 09:31:39.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/quota/xfs_qm_syscalls.c 2008-06-05 20:21:09.000000000 +0200 > @@ -362,11 +362,11 @@ xfs_qm_scall_quotaoff( > * if we don't need them anymore. > */ > if ((dqtype & XFS_QMOPT_UQUOTA) && XFS_QI_UQIP(mp)) { > - XFS_PURGE_INODE(XFS_QI_UQIP(mp)); > + IRELE(XFS_QI_UQIP(mp)); > XFS_QI_UQIP(mp) = NULL; > } > if ((dqtype & (XFS_QMOPT_GQUOTA|XFS_QMOPT_PQUOTA)) && XFS_QI_GQIP(mp)) { > - XFS_PURGE_INODE(XFS_QI_GQIP(mp)); > + IRELE(XFS_QI_GQIP(mp)); > XFS_QI_GQIP(mp) = NULL; > } > out_error: > Index: linux-2.6-xfs/fs/xfs/quota/xfs_quota_priv.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_quota_priv.h 2008-05-23 09:31:39.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/quota/xfs_quota_priv.h 2008-06-05 20:21:09.000000000 +0200 > @@ -158,9 +158,6 @@ for ((dqp) = (qlist)->qh_next; (dqp) != > #define XFS_IS_SUSER_DQUOT(dqp) \ > (!((dqp)->q_core.d_id)) > > -#define XFS_PURGE_INODE(ip) \ > - IRELE(ip); > - > #define DQFLAGTO_TYPESTR(d) (((d)->dq_flags & XFS_DQ_USER) ? "USR" : \ > (((d)->dq_flags & XFS_DQ_GROUP) ? "GRP" : \ > (((d)->dq_flags & XFS_DQ_PROJ) ? "PRJ":"???"))) ---end quoted text--- From owner-xfs@oss.sgi.com Wed Jul 2 12:35:38 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 02 Jul 2008 12:35:40 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m62JZc0U026515 for ; Wed, 2 Jul 2008 12:35:38 -0700 X-ASG-Debug-ID: 1215027399-1c0700340000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 083CF12D6607 for ; Wed, 2 Jul 2008 12:36:39 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id XTzys3CWWks2qK9y for ; Wed, 02 Jul 2008 12:36:39 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m62JaUNW019830 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Wed, 2 Jul 2008 21:36:30 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m62JaUx2019828 for xfs@oss.sgi.com; Wed, 2 Jul 2008 21:36:30 +0200 Date: Wed, 2 Jul 2008 21:36:30 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH] fix compilation without CONFIG_PROC_FS Subject: [PATCH] fix compilation without CONFIG_PROC_FS Message-ID: <20080702193630.GA19715@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1215027401 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.1, rules version 3.1.54979 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16697 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_stats.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_stats.h 2008-06-27 15:16:21.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_stats.h 2008-06-27 15:19:18.000000000 +0200 @@ -146,11 +146,12 @@ extern void xfs_cleanup_procfs(void); static inline int xfs_init_procfs(void) { - return 0 -}; + return 0; +} + static inline void xfs_cleanup_procfs(void) { -}; +} #endif /* !CONFIG_PROC_FS */ From owner-xfs@oss.sgi.com Wed Jul 2 16:39:29 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 02 Jul 2008 16:39:58 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from relay.sgi.com (relay1.corp.sgi.com [192.26.58.214]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m62NdS4a013490 for ; Wed, 2 Jul 2008 16:39:28 -0700 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by relay1.corp.sgi.com (Postfix) with ESMTP id C73958F80F4; Wed, 2 Jul 2008 16:40:28 -0700 (PDT) Received: from itchy (xaiki@itchy.melbourne.sgi.com [134.14.55.96]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m62NeLjm2421942; Thu, 3 Jul 2008 09:40:23 +1000 (AEST) From: Niv Sardi To: Timothy Shimmin Cc: Christoph Hellwig , xfs@oss.sgi.com Subject: Re: [PATCH] Introduce xfs_trans_bmap_add_attrfork. References: <1214196150-5427-1-git-send-email-xaiki@sgi.com> <1214196150-5427-2-git-send-email-xaiki@sgi.com> <1214196150-5427-3-git-send-email-xaiki@sgi.com> <1214196150-5427-4-git-send-email-xaiki@sgi.com> <20080626092856.GA27069@infradead.org> <486B3B76.8020303@sgi.com> Date: Thu, 03 Jul 2008 09:39:52 +1000 In-Reply-To: <486B3B76.8020303@sgi.com> (Timothy Shimmin's message of "Wed, 02 Jul 2008 18:25:26 +1000") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.0.60 (i486-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16698 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: xaiki@sgi.com Precedence: bulk X-list: xfs Timothy Shimmin writes: [...] >> + if (error) >> + goto error1; >> + >> + if (XFS_IFORK_Q(ip)) >> + goto error1; >> + >> + ASSERT(ip->i_d.di_anextents == 0); >> + VN_HOLD(XFS_ITOV(ip)); >> + xfs_trans_ijoin(tp, ip, XFS_ILOCK_EXCL); >> + xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); >> + >> + error = xfs_trans_bmap_add_attrfork(NULL, ip, size, rsvd); >> + if (error) >> + return error; >> + return xfs_trans_commit(tp, XFS_TRANS_PERM_LOG_RES); > > I was kind of expecting the transaction, &tp, to be passed into > xfs_trans_bmap_add_attrfork(). > (And then xfs_trans_bmap_add_attrfork() which calls > xfs_bmap_finish() which calls xfs_trans_dup() and so from that > point on we would then have to update tp if we were to use it.) > > So how come we pass in NULL? > I'm tired so I'm probably missing something obvious. No you're right, it took me a while to remember you're working out of git. I haven't really re-read it properly yet but thanks for this one. Cheers, -- Niv Sardi From owner-xfs@oss.sgi.com Wed Jul 2 18:56:59 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 02 Jul 2008 18:57:01 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m631uvSX022088 for ; Wed, 2 Jul 2008 18:56:58 -0700 X-ASG-Debug-ID: 1215050279-77ff01d90000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5F96E12D7D86 for ; Wed, 2 Jul 2008 18:57:59 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id QVO2rzJUalrtdOFE for ; Wed, 02 Jul 2008 18:57:59 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 3C59FAC626C; Wed, 2 Jul 2008 20:57:59 -0500 (CDT) Message-ID: <486C322D.7080203@sandeen.net> Date: Wed, 02 Jul 2008 20:58:05 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Donald Douwsma CC: xfs-oss X-ASG-Orig-Subj: Re: [PATCH] re-remove xfs custom bitops Subject: Re: [PATCH] re-remove xfs custom bitops References: <480EB397.1040304@sandeen.net> <4829C360.5060500@sandeen.net> <482BF841.8050704@sgi.com> <48669A45.1050104@sandeen.net> <4868A114.9080106@sgi.com> In-Reply-To: <4868A114.9080106@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1215050280 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.1, rules version 3.1.55001 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16699 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Donald Douwsma wrote: > First time round I hit an Oops on xfstests/177 while running the auto group > on ppc32. I dont seem to hit it running the single test, its intermittent. Funky. Do you ever hit it w/ the patch reverted? -Eric From owner-xfs@oss.sgi.com Wed Jul 2 20:53:36 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 02 Jul 2008 20:53:41 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m633raxT000632 for ; Wed, 2 Jul 2008 20:53:36 -0700 X-ASG-Debug-ID: 1215057279-406203bd0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C1B022AE471 for ; Wed, 2 Jul 2008 20:54:39 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id wy1UmpstozGgGG7r for ; Wed, 02 Jul 2008 20:54:39 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 7957AAC626C; Wed, 2 Jul 2008 22:54:38 -0500 (CDT) Message-ID: <486C4D7E.8060608@sandeen.net> Date: Wed, 02 Jul 2008 22:54:38 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: Jan Engelhardt , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: grub fails boot after update Subject: Re: grub fails boot after update References: <20080701155522.GA29722@infradead.org> In-Reply-To: <20080701155522.GA29722@infradead.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1215057279 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.1, rules version 3.1.55009 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16700 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Christoph Hellwig wrote: > sync works perfectly fine on xfs. Grub just doesn't understand what > sync means, and because of that it's buggy on all filesystems, just > with less a chance on others. The fix is pretty simple and that is > stopping to try to access the filesystem with it's own driver through > the block device node. Aye. And from the bug: >> I agree with comment #37: XFS really does suck, especially when it comes to >> booting Linux on a PC. Now that's just inflammatory. :) >> Fortunately we do not support it any more for new >> installations, an ext2 /boot partition is highly recommended. I didn't read the details of the bug but the conclusion is right though - grub is busted, just use ext3 on /boot to work around it. >> The problem is that with XFS, sync(2) returns, but the data isn't synced. >> The first time yast calls grub install, grub does not find the new stage1.5, >> because it is not on the disk yet, despite a successful sync; thus it modifies >> stage2 to do the job. On the second invocation, stage1.5 is found and >> installed, but stage2 already is modified. >> >> So once again this isn't a grub bug, but an XFS bug with FS semantics. No, that's wrong as hch said. (FWIW the issue is that xfs data is safe on disk, metadata is safe in the log, but grub tries to read the fs directly as if it were frozen and expects to find metadata at the final spot on disk, .) Syncing a live filesystem and then thinking you can go read (or worse, write!) directly from (to) disk is a busted notion in many ways. It's the same problem as thinking you can do "sync" and then take a block-based snapshot. There's a reason DM for example freezes before this. There was a bug w/ grub vs. ext3 causing corruption for the exact same sorts of reasons; it's just a little harder to hit. This really is grub that is busted, but I'd still just suggest using ext3 to (mostly) work around the breakage for the foreseeable future. The other option is to teach grub to always do its io via the filesystem not the block device while the fs is mounted (IIRC there are various & sundry non-intuitive commands which actually nudge grub towards or away from this desired behavior... --with-stage2=/path is one I think, skipping the "verification" phase (i.e. trying to read the block dev while mounted) is another) BTW the patch to "wait 10s for the fs to settle" is pure bunk and will not definitively fix the problem. It's not even worth committing IMHO. -Eric From owner-xfs@oss.sgi.com Wed Jul 2 20:56:11 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 02 Jul 2008 20:56:21 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m633uAWm001060 for ; Wed, 2 Jul 2008 20:56:11 -0700 X-ASG-Debug-ID: 1215057433-29ba00f60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6A2F5A644E5 for ; Wed, 2 Jul 2008 20:57:14 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id A6AKOiWz2kPSJoSe for ; Wed, 02 Jul 2008 20:57:14 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id A335FA84103; Wed, 2 Jul 2008 22:57:13 -0500 (CDT) Message-ID: <486C4E19.6080203@sandeen.net> Date: Wed, 02 Jul 2008 22:57:13 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: "Arensdorf, Christopher" CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS Compatibility Questions Subject: Re: XFS Compatibility Questions References: <0EEA30D7D649274EB38B0B140022557F23B36C@corpistemb01.edocorp.com> In-Reply-To: <0EEA30D7D649274EB38B0B140022557F23B36C@corpistemb01.edocorp.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1215057434 X-Barracuda-Bayes: INNOCENT GLOBAL 0.1731 1.0000 -0.9725 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.97 X-Barracuda-Spam-Status: No, SCORE=-0.97 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.1, rules version 3.1.55008 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16701 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Arensdorf, Christopher wrote: > Hello, > > My name is Chris and I'm with ITT Corporation in Nashua, NH. We're currently looking to upgrade one of our products to make use of InfiniBand technology, and unfortunately we're running QFS which does not support InfiniBand. We're interested in exploring the idea of using XFS so I had a few questions I was hoping you might be able to answer that I didn't seem to find in the FAQ section. > > Is XFS compatible with InfiniBand? XFS just needs a block device to talk to; the transport to the block device etc should not matter. > Is XFS compatible with RHEL 5.0 or higher? Compatible yes but not supported or shipped by Red Hat. > Is XFS compatible with Fibre Channel? See the first answer. (but anyway the the short answer is Yes.) > Is XFS compatible with Solaris 10 x86? AFAIK XFS has never been ported to Solaris. It's only a production FS on Linux & Irix. -Eric > Thanks very much for your time and I look forward to hearing back from you. From owner-xfs@oss.sgi.com Wed Jul 2 21:02:19 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 02 Jul 2008 21:02:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m6342JCL001822 for ; Wed, 2 Jul 2008 21:02:19 -0700 X-ASG-Debug-ID: 1215057801-240101810000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 71EEBD9443D for ; Wed, 2 Jul 2008 21:03:22 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id 6BB6OGih8wPCQQ4R for ; Wed, 02 Jul 2008 21:03:22 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 8B630A84102; Wed, 2 Jul 2008 23:03:21 -0500 (CDT) Message-ID: <486C4F89.9030009@sandeen.net> Date: Wed, 02 Jul 2008 23:03:21 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Sagar Borikar CC: Nathan Scott , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Xfs Access to block zero exception and system crash Subject: Re: Xfs Access to block zero exception and system crash References: <20080628000516.GD29319@disturbed> <340C71CD25A7EB49BFA81AE8C8392667028A1CA7@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080629215647.GJ29319@disturbed> <20080630034112.055CF18904C4@bby1mta01.pmc-sierra.bc.ca> <4868B46C.9000200@pmc-sierra.com> <20080701064437.GR29319@disturbed> <486B01A6.4030104@pmc-sierra.com> <20080702051337.GX29319@disturbed> <486B13AD.2010500@pmc-sierra.com> <1214979191.6025.22.camel@verge.scott.net.au> <20080702065652.GS14251@build-svl-1.agami.com> <486B6062.6040201@pmc-sierra.com> In-Reply-To: <486B6062.6040201@pmc-sierra.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1215057802 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.1, rules version 3.1.55008 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16702 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Sagar Borikar wrote: > > Dave Chinner wrote: >> On Wed, Jul 02, 2008 at 04:13:11PM +1000, Nathan Scott wrote: >>> You can always try the reverse - replace fs/xfs from your mips build >>> tree with the one from the current/a recent kernel. Theres very few >>> changes in the surrounding kernel code that xfs needs. >>> >> Eric should be able to comment on the pitfalls in doing this having >> tried to backport a 2.6.25 fs/xfs to a 2.6.18 RHEL kernel. Eric - >> any comments? >> >> Cheers, >> >> Dave. >> > Eric, Could you please let me know about bits and pieces that we need to > remember while back porting xfs to 2.6.18? > If you share patches which takes care of it, that would be great. http://sandeen.net/rhel5_xfs/xfs-2.6.25-for-rhel5-testing.tar.bz2 should be pretty close. It was quick 'n' dirty and it has some warts but would give an idea of what backporting was done (see patches/ and the associated quilt series; quilt push -a to apply them all) -Eric From owner-xfs@oss.sgi.com Wed Jul 2 21:47:01 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 02 Jul 2008 21:47:03 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m634l1s4004597 for ; Wed, 2 Jul 2008 21:47:01 -0700 X-ASG-Debug-ID: 1215060483-3097025b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from opera.rednote.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 98BD4D94A82 for ; Wed, 2 Jul 2008 21:48:04 -0700 (PDT) Received: from opera.rednote.net (opera.rednote.net [75.125.70.226]) by cuda.sgi.com with ESMTP id bOqkML1GLIWk3nEb for ; Wed, 02 Jul 2008 21:48:04 -0700 (PDT) Received: from jdc.jasonjgw.net (localhost6.localdomain6 [IPv6:::1]) by opera.rednote.net (8.14.2/8.14.2) with ESMTP id m634m0MH003787 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 3 Jul 2008 04:48:02 GMT Received: from jdc.jasonjgw.net (ip6-localhost [IPv6:::1]) by jdc.jasonjgw.net (8.14.3/8.14.3/Debian-4) with ESMTP id m634ltwF020723 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 3 Jul 2008 14:47:55 +1000 Received: (from jason@localhost) by jdc.jasonjgw.net (8.14.3/8.14.3/Submit) id m634ltlq020722 for xfs@oss.sgi.com; Thu, 3 Jul 2008 14:47:55 +1000 Date: Thu, 3 Jul 2008 14:47:55 +1000 From: Jason White To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: grub fails boot after update Subject: Re: grub fails boot after update Message-ID: <20080703044755.GA13630@jdc.jasonjgw.net> Mail-Followup-To: xfs@oss.sgi.com References: <20080701155522.GA29722@infradead.org> <486C4D7E.8060608@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <486C4D7E.8060608@sandeen.net> User-Agent: Mutt/1.5.18 (2008-05-17) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: ClamAV 0.93.1/7623/Thu Jul 3 01:28:16 2008 on opera.rednote.net X-Virus-Status: Clean X-Barracuda-Connect: opera.rednote.net[75.125.70.226] X-Barracuda-Start-Time: 1215060484 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.1, rules version 3.1.55011 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-archive-position: 16703 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jason@jasonjgw.net Precedence: bulk X-list: xfs On Wed, Jul 02, 2008 at 10:54:38PM -0500, Eric Sandeen wrote: > This really is grub that is busted, but I'd still just suggest using > ext3 to (mostly) work around the breakage for the foreseeable future. > > The other option is to teach grub to always do its io via the filesystem > not the block device while the fs is mounted (IIRC there are various & > sundry non-intuitive commands which actually nudge grub towards or away > from this desired behavior... --with-stage2=/path is one I think, > skipping the "verification" phase (i.e. trying to read the block dev > while mounted) is another) Does grub 2 (still in development when last I checked) improve on this situation? I managed to get Grub 1 installed on machines with XFS root file systems by running the install from within the grub "shell" environment rather than using grub-install. Maybe this skips the checks that attempt to read the block device directly. I also recall that grub-install failed. From owner-xfs@oss.sgi.com Wed Jul 2 22:14:04 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 02 Jul 2008 22:14:08 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m635E2Tr007042 for ; Wed, 2 Jul 2008 22:14:04 -0700 X-ASG-Debug-ID: 1215062104-6dad005d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bby1mta01.pmc-sierra.bc.ca (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 82E6AD94B21 for ; Wed, 2 Jul 2008 22:15:05 -0700 (PDT) Received: from bby1mta01.pmc-sierra.bc.ca (bby1mta01.pmc-sierra.com [216.241.235.116]) by cuda.sgi.com with ESMTP id X46MIiRAmP9gobKW for ; Wed, 02 Jul 2008 22:15:05 -0700 (PDT) Received: from bby1mta01.pmc-sierra.bc.ca (localhost.pmc-sierra.bc.ca [127.0.0.1]) by localhost (Postfix) with SMTP id 5A7E11890173; Wed, 2 Jul 2008 22:18:09 -0700 (PDT) Received: from bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca (BBY1EXG02.pmc-sierra.bc.ca [216.241.231.167]) by bby1mta01.pmc-sierra.bc.ca (Postfix) with SMTP id 4C0981890156; Wed, 2 Jul 2008 22:18:09 -0700 (PDT) Received: from BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca ([216.241.231.156]) by bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Jul 2008 22:15:39 -0700 Received: from [209.68.166.73] ([209.68.166.73]) by BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca with Microsoft SMTPSVC(6.0.3790.2825); Wed, 2 Jul 2008 22:15:38 -0700 Message-ID: <486C6053.7010503@pmc-sierra.com> Date: Thu, 03 Jul 2008 10:44:59 +0530 From: Sagar Borikar Organization: PMC Sierra Inc User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Eric Sandeen CC: Nathan Scott , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Xfs Access to block zero exception and system crash Subject: Re: Xfs Access to block zero exception and system crash References: <20080628000516.GD29319@disturbed> <340C71CD25A7EB49BFA81AE8C8392667028A1CA7@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080629215647.GJ29319@disturbed> <20080630034112.055CF18904C4@bby1mta01.pmc-sierra.bc.ca> <4868B46C.9000200@pmc-sierra.com> <20080701064437.GR29319@disturbed> <486B01A6.4030104@pmc-sierra.com> <20080702051337.GX29319@disturbed> <486B13AD.2010500@pmc-sierra.com> <1214979191.6025.22.camel@verge.scott.net.au> <20080702065652.GS14251@build-svl-1.agami.com> <486B6062.6040201@pmc-sierra.com> <486C4F89.9030009@sandeen.net> In-Reply-To: <486C4F89.9030009@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 03 Jul 2008 05:15:39.0155 (UTC) FILETIME=[D5167630:01C8DCCB] X-Barracuda-Connect: bby1mta01.pmc-sierra.com[216.241.235.116] X-Barracuda-Start-Time: 1215062105 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0186 1.0000 -1.8999 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.90 X-Barracuda-Spam-Status: No, SCORE=-1.90 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.1, rules version 3.1.55013 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16704 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sagar_borikar@pmc-sierra.com Precedence: bulk X-list: xfs Eric Sandeen wrote: > Sagar Borikar wrote: > >> Dave Chinner wrote: >> >>> On Wed, Jul 02, 2008 at 04:13:11PM +1000, Nathan Scott wrote: >>> > > > >>>> You can always try the reverse - replace fs/xfs from your mips build >>>> tree with the one from the current/a recent kernel. Theres very few >>>> changes in the surrounding kernel code that xfs needs. >>>> >>>> >>> Eric should be able to comment on the pitfalls in doing this having >>> tried to backport a 2.6.25 fs/xfs to a 2.6.18 RHEL kernel. Eric - >>> any comments? >>> >>> Cheers, >>> >>> Dave. >>> >>> >> Eric, Could you please let me know about bits and pieces that we need to >> remember while back porting xfs to 2.6.18? >> If you share patches which takes care of it, that would be great. >> > > http://sandeen.net/rhel5_xfs/xfs-2.6.25-for-rhel5-testing.tar.bz2 > > should be pretty close. It was quick 'n' dirty and it has some warts > but would give an idea of what backporting was done (see patches/ and > the associated quilt series; quilt push -a to apply them all) > Thanks a lot Eric. I'll go through it .I am actually trying another option of regularly defragmenting the file system under stress. I wanted to understand couple of things for using xfs_fsr utility: 1. What should be the state of filesystem when I am running xfs_fsr. Ideally we should stop all io before running defragmentation. 2. How effective is the utility when ran on highly fragmented file system? I saw that if filesystem is 99.89% fragmented, the recovery is very slow. It took around 25 min to clean up 100GB JBOD volume and after that system was fragmented to 82%. So I was confused on how exactly the fragmentation works. Any pointers on probable optimum use of xfs_fsr? 3. Any precautions I need to take when working with that from data consistency, robustness point of view? Any disadvantages? 4. Any threshold for starting the defragmentation on xfs? Thanks Sagar > -Eric > From owner-xfs@oss.sgi.com Wed Jul 2 22:44:19 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 02 Jul 2008 22:44:22 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-0.5 required=5.0 tests=AWL,BAYES_05,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m635iIfc009310 for ; Wed, 2 Jul 2008 22:44:19 -0700 X-ASG-Debug-ID: 1215063920-01ee031a0001-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wanadoo.es (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 16A6418676DE for ; Wed, 2 Jul 2008 22:45:20 -0700 (PDT) Received: from wanadoo.es (host-200-62-193-18.telmex.com.pe [200.62.193.18]) by cuda.sgi.com with SMTP id eRk0iqDT9YPLPJ8T for ; Wed, 02 Jul 2008 22:45:20 -0700 (PDT) From: "Jehn Sanders" To: "Linux-xfs" X-ASG-Orig-Subj: web site noticed Subject: web site noticed Date: Thu, 3 Jul 2008 00:45:15 -0500 Reply-To: "Jehn Sanders" Message-ID: <62354217.20080703004515@gmail.com> X-Priority: 5 (Low) MIME-Version: 1.0 Organization: K-Media Solutions Content-Type: text/plain; charset="ISO-8859-1" X-Barracuda-Connect: host-200-62-193-18.telmex.com.pe[200.62.193.18] X-Barracuda-Start-Time: 1215063922 X-Barracuda-Bayes: INNOCENT GLOBAL 0.5693 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.85 X-Barracuda-Spam-Status: No, SCORE=0.85 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.1, rules version 3.1.55014 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 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id m635iJfc009312 X-archive-position: 16705 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jehnsanders@gmail.com Precedence: bulk X-list: xfs Dear Linux-xfs, Its time to get your web site noticed. We can increase your monthly web traffic and get you the best position on every major search engines (Eg: Google, Yahoo!, AOL, AltaVista, etc). We would like to show you how with a free site review. Email us today and we will do a no cost site assessment so that you can see for yourself what your online business could produce. Sincerely Jehn Sanders jehnsanders@gmail.com ________________________________________ K-Media Solutions Yahoo!, Google, MSN, AltaVista, AOL This promotion is only valid for USA websites If you wish to be removed from this list, please reply the word "REMOVE" in your subject line From owner-xfs@oss.sgi.com Wed Jul 2 23:45:58 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 02 Jul 2008 23:46:01 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m636jtJP013215 for ; Wed, 2 Jul 2008 23:45:57 -0700 Received: from cxfsmac10.melbourne.sgi.com (cxfsmac10.melbourne.sgi.com [134.14.55.100]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA20116; Thu, 3 Jul 2008 16:46:53 +1000 Message-ID: <486C75DD.2040109@sgi.com> Date: Thu, 03 Jul 2008 16:46:53 +1000 From: Donald Douwsma User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Eric Sandeen CC: xfs-oss Subject: Re: [PATCH] re-remove xfs custom bitops References: <480EB397.1040304@sandeen.net> <4829C360.5060500@sandeen.net> <482BF841.8050704@sgi.com> <48669A45.1050104@sandeen.net> <4868A114.9080106@sgi.com> <486C322D.7080203@sandeen.net> In-Reply-To: <486C322D.7080203@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16706 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: donaldd@sgi.com Precedence: bulk X-list: xfs Eric Sandeen wrote: > Donald Douwsma wrote: > >> First time round I hit an Oops on xfstests/177 while running the auto group >> on ppc32. I dont seem to hit it running the single test, its intermittent. > > Funky. Do you ever hit it w/ the patch reverted? That's the question. So far no, the QA guys said they hit it a while ago, but the time frame still matches last time. I dont think this is related but I need to get some more ppc32 runs without. I'm probably being over cautious but I'd like to avoid the inagain/outagain/inagain/outagain approach we keep using with some of these cleanups. Don From owner-xfs@oss.sgi.com Thu Jul 3 05:10:53 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 03 Jul 2008 05:11:23 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,STOX_REPLY_TYPE autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m63CArhW018280 for ; Thu, 3 Jul 2008 05:10:53 -0700 X-ASG-Debug-ID: 1215087115-18ee03b70000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from tyo202.gate.nec.co.jp (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AEA722B0496 for ; Thu, 3 Jul 2008 05:11:55 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by cuda.sgi.com with ESMTP id l3BDMOBw7YDqnJyg for ; Thu, 03 Jul 2008 05:11:55 -0700 (PDT) Received: from mailgate3.nec.co.jp (mailgate54.nec.co.jp [10.7.69.197]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id m63CB6ou027688; Thu, 3 Jul 2008 21:11:06 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id m63CB6Z11313; Thu, 3 Jul 2008 21:11:06 +0900 (JST) Received: from shoin.jp.nec.com (shoin.jp.nec.com [10.26.220.3]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id m63CB5XW011656; Thu, 3 Jul 2008 21:11:05 +0900 (JST) Received: from TNESB07336 ([10.64.168.65] [10.64.168.65]) by mail.jp.nec.com with ESMTP; Thu, 3 Jul 2008 21:11:05 +0900 Message-Id: <9942A69CB65D4A41B39F36AF8EEF6F22@nsl.ad.nec.co.jp> From: "Takashi Sato" To: "Christoph Hellwig" , "Alasdair G Kergon" Cc: , "Andrew Morton" , , , , , , , References: <20080630212450t-sato@mail.jp.nec.com> <20080701081026.GB16691@infradead.org> <20080701105251.GC22522@agk.fab.redhat.com> In-Reply-To: <20080701105251.GC22522@agk.fab.redhat.com> X-ASG-Orig-Subj: Re: [dm-devel] Re: [PATCH 3/3] Add timeout feature Subject: Re: [dm-devel] Re: [PATCH 3/3] Add timeout feature Date: Thu, 3 Jul 2008 21:11:05 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-Barracuda-Connect: TYO202.gate.nec.co.jp[202.32.8.206] X-Barracuda-Start-Time: 1215087116 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.1, rules version 3.1.55039 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16707 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: t-sato@yk.jp.nec.com Precedence: bulk X-list: xfs Hi Christoph and Alasdair, > On Tue, Jul 01, 2008 at 04:10:26AM -0400, Christoph Hellwig wrote: >> I still disagree with this whole patch. > > Same here - if you want a timeout, what stops you from implementing it in a > userspace process? If your concern is that the process might die without > thawing the filesystem, take a look at the userspace LVM/multipath code for > ideas - lock into memory, disable OOM killer, run from ramdisk etc. > In practice, those techniques seem to be good enough. If the freezer accesses the frozen filesystem and causes a deadlock, the above ideas can't solve it. The timeout is useful to solve such a deadlock. If you don't need the timeout, you can disable it by specifying "0" as the timeout period. > Similarly if a device-mapper device is involved, how should the following > sequence behave - A, B or C? > > 1. dmsetup suspend (freezes) > 2. FIFREEZE > 3. FITHAW > 4. dmsetup resume (thaws) [...] > C: > 1 succeeds, freezes > 2 fails, remains frozen > 3 fails (because device-mapper owns the freeze/thaw), remains frozen > 4 succeeds, thaws I think C is appropriate and the following change makes it possible. How do you think? 1. Add the new bit flag(BD_FREEZE_DM) in block_device.bd_state. It means that the volume is frozen by the device-mapper. 2. Operate and check this bit flag as followings. - Bit operations in the device-mapper's freeze/thaw FREEZE: dm_suspend(): set BD_FREEZE_DM freeze_bdev():set BD_FREEZE_OP THAW: thaw_bdev(): clear BD_FREEZE_OP dm_resume(): clear BD_FREEZE_DM - Checks in FIFREEZE/FITHAW FREEZE: ioctl_freeze(): Not need to check BD_FREEZE_DM freeze_bdev():set BD_FREEZE_OP THAW: ioctl_thaw(): If BD_FREEZE_DM is set, fail, otherwise, call thaw_bdev() thaw_bdev(): clear BD_FREEZE_OP Cheers, Takashi From owner-xfs@oss.sgi.com Thu Jul 3 05:47:22 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 03 Jul 2008 05:47:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m63ClMK4022226 for ; Thu, 3 Jul 2008 05:47:22 -0700 X-ASG-Debug-ID: 1215089304-77ac02960000-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 6690E12D8F10 for ; Thu, 3 Jul 2008 05:48:24 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com with ESMTP id fUVCY0DofqBBSrFL for ; Thu, 03 Jul 2008 05:48:24 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m63ClBAo001234; Thu, 3 Jul 2008 08:47:11 -0400 Received: from pobox.fab.redhat.com (pobox.fab.redhat.com [10.33.63.12]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m63ClAji005840; Thu, 3 Jul 2008 08:47:11 -0400 Received: from agk.fab.redhat.com (agk.fab.redhat.com [10.33.0.19]) by pobox.fab.redhat.com (8.13.1/8.13.1) with ESMTP id m63ClAug004756; Thu, 3 Jul 2008 08:47:10 -0400 Received: from agk by agk.fab.redhat.com with local (Exim 4.34) id 1KEODO-00008L-37; Thu, 03 Jul 2008 13:47:10 +0100 Date: Thu, 3 Jul 2008 13:47:10 +0100 From: Alasdair G Kergon To: Takashi Sato Cc: Christoph Hellwig , linux-ext4@vger.kernel.org, Andrew Morton , linux-fsdevel@vger.kernel.org, viro@ZenIV.linux.org.uk, dm-devel@redhat.com, xfs@oss.sgi.com, linux-kernel@vger.kernel.org, mtk.manpages@googlemail.com, axboe@kernel.dk X-ASG-Orig-Subj: Re: [dm-devel] Re: [PATCH 3/3] Add timeout feature Subject: Re: [dm-devel] Re: [PATCH 3/3] Add timeout feature Message-ID: <20080703124709.GI22522@agk.fab.redhat.com> Mail-Followup-To: Takashi Sato , Christoph Hellwig , linux-ext4@vger.kernel.org, Andrew Morton , linux-fsdevel@vger.kernel.org, viro@ZenIV.linux.org.uk, dm-devel@redhat.com, xfs@oss.sgi.com, linux-kernel@vger.kernel.org, mtk.manpages@googlemail.com, axboe@kernel.dk References: <20080630212450t-sato@mail.jp.nec.com> <20080701081026.GB16691@infradead.org> <20080701105251.GC22522@agk.fab.redhat.com> <9942A69CB65D4A41B39F36AF8EEF6F22@nsl.ad.nec.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9942A69CB65D4A41B39F36AF8EEF6F22@nsl.ad.nec.co.jp> User-Agent: Mutt/1.4.1i Organization: Red Hat UK Ltd. Registered in England and Wales, number 03798903. Registered Office: Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE. X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-Barracuda-Connect: mx1.redhat.com[66.187.233.31] X-Barracuda-Start-Time: 1215089306 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16708 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: agk@redhat.com Precedence: bulk X-list: xfs On Thu, Jul 03, 2008 at 09:11:05PM +0900, Takashi Sato wrote: > If the freezer accesses the frozen filesystem and causes a deadlock, > the above ideas can't solve it But you could also say that if the 'freezer' process accesses the frozen filesystem and deadlocks then that's just a bug and that userspace code should be fixed and there's no need to introduce the complexity of a timeout parameter. > >Similarly if a device-mapper device is involved, how should the following > >sequence behave - A, B or C? > > > >1. dmsetup suspend (freezes) > >2. FIFREEZE > >3. FITHAW > >4. dmsetup resume (thaws) > [...] > >C: > > 1 succeeds, freezes > > 2 fails, remains frozen > > 3 fails (because device-mapper owns the freeze/thaw), remains frozen > > 4 succeeds, thaws > > I think C is appropriate and the following change makes it possible. > How do you think? The point I'm trying to make here is: Under what real-world circumstances might multiple concurrent freezing attempts occur, and which of A, B or C (or other variations) would be the most appropriate way of handling such situations? A common example is people running xfs_freeze followed by an lvm command which also attempts to freeze the filesystem. I can see a case for B or C, but personally I prefer A: > > 1 succeeds, freezes > > 2 succeeds, remains frozen > > 3 succeeds, remains frozen > > 4 succeeds, thaws Alasdair -- agk@redhat.com From owner-xfs@oss.sgi.com Thu Jul 3 07:45:38 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 03 Jul 2008 07:45:46 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-3.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m63Ejcff031660 for ; Thu, 3 Jul 2008 07:45:38 -0700 X-ASG-Debug-ID: 1215096401-400e003f0000-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 0044F12D95E5 for ; Thu, 3 Jul 2008 07:46:41 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by cuda.sgi.com with ESMTP id oG1qPdTLOm7RH1xg for ; Thu, 03 Jul 2008 07:46:41 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m63EjpL3015262; Thu, 3 Jul 2008 10:45:51 -0400 Received: from pobox-2.corp.redhat.com (pobox-2.corp.redhat.com [10.11.255.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m63Ejosh000446; Thu, 3 Jul 2008 10:45:50 -0400 Received: from liberator.sandeen.net (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox-2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m63EjmqB019280; Thu, 3 Jul 2008 10:45:48 -0400 Message-ID: <486CE61C.50706@redhat.com> Date: Thu, 03 Jul 2008 09:45:48 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Takashi Sato CC: Christoph Hellwig , Alasdair G Kergon , linux-ext4@vger.kernel.org, Andrew Morton , linux-fsdevel@vger.kernel.org, viro@ZenIV.linux.org.uk, dm-devel@redhat.com, xfs@oss.sgi.com, linux-kernel@vger.kernel.org, mtk.manpages@googlemail.com, axboe@kernel.dk X-ASG-Orig-Subj: Re: [dm-devel] Re: [PATCH 3/3] Add timeout feature Subject: Re: [dm-devel] Re: [PATCH 3/3] Add timeout feature References: <20080630212450t-sato@mail.jp.nec.com> <20080701081026.GB16691@infradead.org> <20080701105251.GC22522@agk.fab.redhat.com> <9942A69CB65D4A41B39F36AF8EEF6F22@nsl.ad.nec.co.jp> In-Reply-To: <9942A69CB65D4A41B39F36AF8EEF6F22@nsl.ad.nec.co.jp> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.58 on 172.16.52.254 X-Barracuda-Connect: mx1.redhat.com[66.187.233.31] X-Barracuda-Start-Time: 1215096402 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16709 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@redhat.com Precedence: bulk X-list: xfs Takashi Sato wrote: > Hi Christoph and Alasdair, > >> On Tue, Jul 01, 2008 at 04:10:26AM -0400, Christoph Hellwig wrote: >>> I still disagree with this whole patch. >> Same here - if you want a timeout, what stops you from implementing it in a >> userspace process? If your concern is that the process might die without >> thawing the filesystem, take a look at the userspace LVM/multipath code for >> ideas - lock into memory, disable OOM killer, run from ramdisk etc. >> In practice, those techniques seem to be good enough. > > If the freezer accesses the frozen filesystem and causes a deadlock, > the above ideas can't solve it. The timeout is useful to solve such a deadlock. > If you don't need the timeout, you can disable it by specifying "0" as the > timeout period. > >> Similarly if a device-mapper device is involved, how should the following >> sequence behave - A, B or C? >> >> 1. dmsetup suspend (freezes) >> 2. FIFREEZE >> 3. FITHAW >> 4. dmsetup resume (thaws) > [...] >> C: >> 1 succeeds, freezes >> 2 fails, remains frozen >> 3 fails (because device-mapper owns the freeze/thaw), remains frozen >> 4 succeeds, thaws > > I think C is appropriate and the following change makes it possible. > How do you think? > > 1. Add the new bit flag(BD_FREEZE_DM) in block_device.bd_state. > It means that the volume is frozen by the device-mapper. Will we add a new bit/flag for every possible subysstem that may call freeze/thaw? This seems odd to me. They are different paths to the same underlying mechanism; it should not matter if it is an existing freeze from DM or via FIFREEZE or via the xfs ioctl, or any other mechanism should it? I don't think this generic interface should use any flag named *_DM, personally. It seems that nested freeze requests must be handled in a generic way regardless of what initiates any of the requests? Refcounting freezes as Alasdair suggests seems to make sense to me, i.e. freeze, freeze, thaw, thaw leads to: >> > > 1 (freeze) succeeds, freezes (frozen++) >> > > 2 (freeze) succeeds, remains frozen (frozen++) >> > > 3 (thaw) succeeds, remains frozen (frozen--) >> > > 4 (thaw) succeeds, thaws (frozen--) that way each caller of freeze is guaranteed that the fs is frozen at least until they call thaw? Thanks, -Eric From owner-xfs@oss.sgi.com Thu Jul 3 07:48:31 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 03 Jul 2008 07:48:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m63EmUBW032112 for ; Thu, 3 Jul 2008 07:48:30 -0700 X-ASG-Debug-ID: 1215096569-2cd202c90000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A2AC31869440 for ; Thu, 3 Jul 2008 07:49:29 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id 6vnMJCyQeHkO7ZG3 for ; Thu, 03 Jul 2008 07:49:29 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 60AC7AC626C for ; Thu, 3 Jul 2008 09:49:29 -0500 (CDT) Message-ID: <486CE6F9.7000003@sandeen.net> Date: Thu, 03 Jul 2008 09:49:29 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: grub fails boot after update Subject: Re: grub fails boot after update References: <20080701155522.GA29722@infradead.org> <486C4D7E.8060608@sandeen.net> <20080703044755.GA13630@jdc.jasonjgw.net> In-Reply-To: <20080703044755.GA13630@jdc.jasonjgw.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1215096570 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: -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.1, rules version 3.1.55051 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16710 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Jason White wrote: > On Wed, Jul 02, 2008 at 10:54:38PM -0500, Eric Sandeen wrote: > >> This really is grub that is busted, but I'd still just suggest using >> ext3 to (mostly) work around the breakage for the foreseeable future. >> >> The other option is to teach grub to always do its io via the filesystem >> not the block device while the fs is mounted (IIRC there are various & >> sundry non-intuitive commands which actually nudge grub towards or away >> from this desired behavior... --with-stage2=/path is one I think, >> skipping the "verification" phase (i.e. trying to read the block dev >> while mounted) is another) > > Does grub 2 (still in development when last I checked) improve on this > situation? No idea. Does anyone use grub2? My impression is that each distro is currently just maintaining a fork of grub(1). If grub2 is using more than "sync and hope" I'd be pleasantly surprised. :) > I managed to get Grub 1 installed on machines with XFS root file systems by > running the install from within the grub "shell" environment rather than using > grub-install. Maybe this skips the checks that attempt to read the block > device directly. I also recall that grub-install failed. Yep, this might be some of the "magic" I talked about w.r.t. behavior of different grub incantations. -Eric From owner-xfs@oss.sgi.com Thu Jul 3 08:01:00 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 03 Jul 2008 08:01:02 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m63F10kq000760 for ; Thu, 3 Jul 2008 08:01:00 -0700 X-ASG-Debug-ID: 1215097322-43e8012c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 86EC812D9798 for ; Thu, 3 Jul 2008 08:02:03 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id wAh3CEXjxhLwBsXm for ; Thu, 03 Jul 2008 08:02:03 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 8C73EAC626C; Thu, 3 Jul 2008 10:02:02 -0500 (CDT) Message-ID: <486CE9EA.90502@sandeen.net> Date: Thu, 03 Jul 2008 10:02:02 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Sagar Borikar CC: Nathan Scott , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Xfs Access to block zero exception and system crash Subject: Re: Xfs Access to block zero exception and system crash References: <20080628000516.GD29319@disturbed> <340C71CD25A7EB49BFA81AE8C8392667028A1CA7@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080629215647.GJ29319@disturbed> <20080630034112.055CF18904C4@bby1mta01.pmc-sierra.bc.ca> <4868B46C.9000200@pmc-sierra.com> <20080701064437.GR29319@disturbed> <486B01A6.4030104@pmc-sierra.com> <20080702051337.GX29319@disturbed> <486B13AD.2010500@pmc-sierra.com> <1214979191.6025.22.camel@verge.scott.net.au> <20080702065652.GS14251@build-svl-1.agami.com> <486B6062.6040201@pmc-sierra.com> <486C4F89.9030009@sandeen.net> <486C6053.7010503@pmc-sierra.com> In-Reply-To: <486C6053.7010503@pmc-sierra.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1215097323 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.1, rules version 3.1.55050 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16711 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Sagar Borikar wrote: > > Eric Sandeen wrote: >>> Eric, Could you please let me know about bits and pieces that we need to >>> remember while back porting xfs to 2.6.18? >>> If you share patches which takes care of it, that would be great. >>> >> http://sandeen.net/rhel5_xfs/xfs-2.6.25-for-rhel5-testing.tar.bz2 >> >> should be pretty close. It was quick 'n' dirty and it has some warts >> but would give an idea of what backporting was done (see patches/ and >> the associated quilt series; quilt push -a to apply them all) >> > Thanks a lot Eric. I'll go through it .I am actually trying another > option of regularly defragmenting the file system under stress. Ok, but that won't get to the bottom of the problem. It might alleviate it at best, but if I were shipping a product using xfs I'd want to know that it was properly solved. :) The tarball above should give you almost everything you need to run your testcase with current xfs code on your older kernel to see if the bug persists or if it's been fixed upstream, in which case you have a relatively easy path to an actual solution that your customers can depend on. > I wanted to understand couple of things for using xfs_fsr utility: > > 1. What should be the state of filesystem when I am running xfs_fsr. > Ideally we should stop all io before running defragmentation. you can run in any state. Some files will not get defragmented due to busy-ness or other conditions; look at the xfs_swap_extents() function in the kernel which is very well documented; some cases return EBUSY. > 2. How effective is the utility when ran on highly fragmented file > system? I saw that if filesystem is 99.89% fragmented, the recovery is > very slow. It took around 25 min to clean up 100GB JBOD volume and after > that system was fragmented to 82%. So I was confused on how exactly the > fragmentation works. Again read the code, but basically it tries to preallocate as much space as the file is currently using, then checks that it is more contiguous space than the file currently has and if so, it copies the data from old to new and swaps the new allocation for the old. Note, this involves a fair amount of IO. Also don't get hung up on that fragmentation factor, at least not until you've read xfs_db code to see how it's reported, and you've thought about what that means. For example: a 100G filesystem with 10 10G files each with 5x2G extents will report 80% fragmentation. Now, ask yourself, is a 10G file in 5x2G extents "bad" fragmentation? > Any pointers on probable optimum use of xfs_fsr? > 3. Any precautions I need to take when working with that from data > consistency, robustness point of view? Any disadvantages? Anything which corrupts data is a bug, and I'm not aware of any such bugs in the defragmentation process. > 4. Any threshold for starting the defragmentation on xfs? Pretty well determined by your individual use case and requirements, I think. -Eric From owner-xfs@oss.sgi.com Thu Jul 3 08:01:51 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 03 Jul 2008 08:01:54 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m63F1pVX001143 for ; Thu, 3 Jul 2008 08:01:51 -0700 X-ASG-Debug-ID: 1215097374-43e9011b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7C18A12D97C8 for ; Thu, 3 Jul 2008 08:02:54 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id bQy9oFoRFOqIz93V for ; Thu, 03 Jul 2008 08:02:54 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id C3FB5AC626C; Thu, 3 Jul 2008 10:02:53 -0500 (CDT) Message-ID: <486CEA1D.5010106@sandeen.net> Date: Thu, 03 Jul 2008 10:02:53 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Donald Douwsma CC: xfs-oss X-ASG-Orig-Subj: Re: [PATCH] re-remove xfs custom bitops Subject: Re: [PATCH] re-remove xfs custom bitops References: <480EB397.1040304@sandeen.net> <4829C360.5060500@sandeen.net> <482BF841.8050704@sgi.com> <48669A45.1050104@sandeen.net> <4868A114.9080106@sgi.com> <486C322D.7080203@sandeen.net> <486C75DD.2040109@sgi.com> In-Reply-To: <486C75DD.2040109@sgi.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1215097374 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0001 1.0000 -2.0207 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.1, rules version 3.1.55050 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16712 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Donald Douwsma wrote: > Eric Sandeen wrote: >> Donald Douwsma wrote: >> >>> First time round I hit an Oops on xfstests/177 while running the auto group >>> on ppc32. I dont seem to hit it running the single test, its intermittent. >> Funky. Do you ever hit it w/ the patch reverted? > > That's the question. So far no, the QA guys said they hit it a while > ago, but the time frame still matches last time. I dont think this > is related but I need to get some more ppc32 runs without. > > I'm probably being over cautious but I'd like to avoid the > inagain/outagain/inagain/outagain approach we keep using with > some of these cleanups. Yep, I totally understand, I'd do just the same. :) -Eric From owner-xfs@oss.sgi.com Thu Jul 3 15:10:36 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 03 Jul 2008 15:10:42 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m63MAYWu013646 for ; Thu, 3 Jul 2008 15:10:36 -0700 X-ASG-Debug-ID: 1215123097-0ce102d70000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail04.adl2.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3811ED9F322 for ; Thu, 3 Jul 2008 15:11:37 -0700 (PDT) Received: from ipmail04.adl2.internode.on.net (ipmail04.adl2.internode.on.net [203.16.214.57]) by cuda.sgi.com with ESMTP id AndQk6ab3zobVQte for ; Thu, 03 Jul 2008 15:11:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANexXkh5LBzp/2dsb2JhbACuPg X-IronPort-AV: E=Sophos;i="4.27,744,1204464600"; d="scan'208";a="149412958" Received: from ppp121-44-28-233.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.28.233]) by ipmail04.adl2.internode.on.net with ESMTP; 04 Jul 2008 07:41:35 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KEX1a-0001JX-0F; Fri, 04 Jul 2008 08:11:34 +1000 Date: Fri, 4 Jul 2008 08:11:33 +1000 From: Dave Chinner To: Takashi Sato , Christoph Hellwig , linux-ext4@vger.kernel.org, Andrew Morton , linux-fsdevel@vger.kernel.org, viro@ZenIV.linux.org.uk, dm-devel@redhat.com, xfs@oss.sgi.com, linux-kernel@vger.kernel.org, mtk.manpages@googlemail.com, axboe@kernel.dk X-ASG-Orig-Subj: Re: [dm-devel] Re: [PATCH 3/3] Add timeout feature Subject: Re: [dm-devel] Re: [PATCH 3/3] Add timeout feature Message-ID: <20080703221133.GA29319@disturbed> Mail-Followup-To: Takashi Sato , Christoph Hellwig , linux-ext4@vger.kernel.org, Andrew Morton , linux-fsdevel@vger.kernel.org, viro@ZenIV.linux.org.uk, dm-devel@redhat.com, xfs@oss.sgi.com, linux-kernel@vger.kernel.org, mtk.manpages@googlemail.com, axboe@kernel.dk References: <20080630212450t-sato@mail.jp.nec.com> <20080701081026.GB16691@infradead.org> <20080701105251.GC22522@agk.fab.redhat.com> <9942A69CB65D4A41B39F36AF8EEF6F22@nsl.ad.nec.co.jp> <20080703124709.GI22522@agk.fab.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080703124709.GI22522@agk.fab.redhat.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail04.adl2.internode.on.net[203.16.214.57] X-Barracuda-Start-Time: 1215123098 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.1, rules version 3.1.55080 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16713 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Thu, Jul 03, 2008 at 01:47:10PM +0100, Alasdair G Kergon wrote: > On Thu, Jul 03, 2008 at 09:11:05PM +0900, Takashi Sato wrote: > > If the freezer accesses the frozen filesystem and causes a deadlock, > > the above ideas can't solve it > > But you could also say that if the 'freezer' process accesses the frozen > filesystem and deadlocks then that's just a bug and that userspace code > should be fixed and there's no need to introduce the complexity of a > timeout parameter. Seconded - that was also my primary objection to the timeout code. > The point I'm trying to make here is: > Under what real-world circumstances might multiple concurrent freezing > attempts occur, and which of A, B or C (or other variations) would be > the most appropriate way of handling such situations? > > A common example is people running xfs_freeze followed by an lvm command > which also attempts to freeze the filesystem. Yes, I've seen that reported a number of times. > I can see a case for B or C, but personally I prefer A: > > > > 1 succeeds, freezes > > > 2 succeeds, remains frozen > > > 3 succeeds, remains frozen > > > 4 succeeds, thaws Agreed, though I'd modify the definition of that case to be "remain frozen until the last thaw occurs". That has the advantage that it's relatively simple to implement with just a counter... Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Thu Jul 3 19:39:04 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 03 Jul 2008 19:39:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m642d4Ro004263 for ; Thu, 3 Jul 2008 19:39:04 -0700 X-ASG-Debug-ID: 1215139206-529201a10000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mx200i.civica.com.au (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 107C6DA21C9 for ; Thu, 3 Jul 2008 19:40:06 -0700 (PDT) Received: from mx200i.civica.com.au (mx200i.civica.com.au [203.56.2.222]) by cuda.sgi.com with ESMTP id n9jQRFspkQlo8uq9 for ; Thu, 03 Jul 2008 19:40:06 -0700 (PDT) Received: from gateway.civica.com.au (gateway.civica.com.au [10.61.100.12]) by mx200i.civica.com.au (BorderWare MXtreme Mail Firewall) with ESMTP id CECE625897 for ; Fri, 4 Jul 2008 12:40:05 +1000 (EST) Received: from newmail.civica.com.au ([10.61.106.3]) by gateway.civica.com.au with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jul 2008 12:40:05 +1000 Received: from 10.61.106.153 ([10.61.106.153]) by newmail.civica.com.au ([10.61.106.3]) with Microsoft Exchange Server HTTP-DAV ; Fri, 4 Jul 2008 02:40:04 +0000 Received: from quadski by newmail.civica.com.au; 04 Jul 2008 12:40:05 +1000 X-ASG-Orig-Subj: user defined cache Subject: user defined cache From: Warwick Boote To: xfs@oss.sgi.com Content-Type: text/plain; charset=UTF-8 Date: Fri, 04 Jul 2008 12:40:05 +1000 Message-Id: <1215139205.7187.33.camel@quadski> Mime-Version: 1.0 X-Mailer: Evolution 2.22.2 X-OriginalArrivalTime: 04 Jul 2008 02:40:06.0140 (UTC) FILETIME=[449723C0:01C8DD7F] X-Barracuda-Connect: mx200i.civica.com.au[203.56.2.222] X-Barracuda-Start-Time: 1215139208 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4995 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=UNPARSEABLE_RELAY X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.55097 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 UNPARSEABLE_RELAY Informational: message has unparseable relay lines X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id m642d4Ro004265 X-archive-position: 16714 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: wboote@civica.com.au Precedence: bulk X-list: xfs Hi all, Do you know of setting or layered file system that enables me to define a large buffer in main memory and cache writes to this buffer? Obviously i'd need the file system to also read from this buffer if the data hasn't been flushed to the disk yet. Waz. =) (apologies for inappropriate disclaimer) -- This email is from Civica Pty Limited and it, together with any attachments, is confidential to the intended recipient(s) and the contents may be legally privileged or contain proprietary and private information. It is intended solely for the person to whom it is addressed. If you are not an intended recipient, you may not review, copy or distribute this email. If received in error, please notify the sender and delete the message from your system immediately. Any views or opinions expressed in this email and any files transmitted with it are those of the author only and may not necessarily reflect the views of Civica and do not create any legally binding rights or obligations whatsoever. Unless otherwise pre-agreed by exchange of hard copy documents signed by duly authorised representatives, contracts may not be concluded on behalf of Civica by email. Please note that neither Civica nor the sender accepts any responsibility for any viruses and it is your responsibility to scan the email and the attachments (if any). All email received and sent by Civica may be monitored to protect the business interests of Civica. From owner-xfs@oss.sgi.com Thu Jul 3 20:50:21 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 03 Jul 2008 20:50:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_81, RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m643oKkV012452 for ; Thu, 3 Jul 2008 20:50:21 -0700 X-ASG-Debug-ID: 1215143483-352500cf0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from web34507.mail.mud.yahoo.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 226321877C48 for ; Thu, 3 Jul 2008 20:51:23 -0700 (PDT) Received: from web34507.mail.mud.yahoo.com (web34507.mail.mud.yahoo.com [66.163.178.173]) by cuda.sgi.com with SMTP id wzh0PhFdVmhGNAHW for ; Thu, 03 Jul 2008 20:51:23 -0700 (PDT) Received: (qmail 36251 invoked by uid 60001); 4 Jul 2008 03:51:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type:Message-ID; b=MRLwc9RNPoS1Q6s7hrKJ5FM/mkdOUQ2JB8Nb2f9N+OfUbb3uCGLh4JZ3NVzHwOSdWY/27ijNiLsZjmEK2WDWo00dDFKnIH0uk59j17gczs3RIAJ19MB3UOUTJR1102t81jbR3ZtTz8mLo9qIh5aS1bUTz4SUXZCHP0ZBw3LGU6o=; Received: from [96.14.189.102] by web34507.mail.mud.yahoo.com via HTTP; Thu, 03 Jul 2008 20:51:23 PDT X-Mailer: YahooMailWebService/0.7.199 Date: Thu, 3 Jul 2008 20:51:23 -0700 (PDT) From: Mark Reply-To: MusicMan529@yahoo.com X-ASG-Orig-Subj: Re: user defined cache Subject: Re: user defined cache To: xfs@oss.sgi.com, Warwick Boote In-Reply-To: <1215139205.7187.33.camel@quadski> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <328802.35603.qm@web34507.mail.mud.yahoo.com> X-Barracuda-Connect: web34507.mail.mud.yahoo.com[66.163.178.173] X-Barracuda-Start-Time: 1215143484 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4938 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 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.1, rules version 3.1.55101 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16715 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: musicman529@yahoo.com Precedence: bulk X-list: xfs --- On Thu, 7/3/08, Warwick Boote wrote: > Hi all, > > Do you know of setting or layered file system that enables > me to define > a large buffer in main memory and cache writes to this > buffer? > > Obviously i'd need the file system to also read from > this buffer if the > data hasn't been flushed to the disk yet. XFS supports the following mount options, and they do increase throughput somewhat on my system: logbufs=N (helps concurrency) logbsize=N (helps log buffering) If you are using an internal XFS log, you may also try "nobarrier" to reduce force-to-disk write frequency. NB: I have seen this option discussed on this mailing list, but I do not see it in the mount(8) man page. Bear in mind that the XFS log is for metadata, rather than actual file data. This may be what you're looking for, or at least sufficient; if not, my apologies. -- Mark "What better place to find oneself than on the streets of one's home village?" --Capt. Jean-Luc Picard, "Family" From owner-xfs@oss.sgi.com Thu Jul 3 21:02:28 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 03 Jul 2008 21:02:33 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m6442SEe013458 for ; Thu, 3 Jul 2008 21:02:28 -0700 X-ASG-Debug-ID: 1215144210-144e01df0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B4387DA25BA for ; Thu, 3 Jul 2008 21:03:30 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id O75QAt5Cj2EK0LMP for ; Thu, 03 Jul 2008 21:03:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAA8+bUh5LBzp/2dsb2JhbACxVA X-IronPort-AV: E=Sophos;i="4.30,300,1212330600"; d="scan'208";a="141604450" Received: from ppp121-44-28-233.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.28.233]) by ipmail01.adl6.internode.on.net with ESMTP; 04 Jul 2008 13:33:16 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KEcVv-0000bO-Gk; Fri, 04 Jul 2008 14:03:15 +1000 Date: Fri, 4 Jul 2008 14:03:15 +1000 From: Dave Chinner To: Warwick Boote Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: user defined cache Subject: Re: user defined cache Message-ID: <20080704040315.GD29319@disturbed> Mail-Followup-To: Warwick Boote , xfs@oss.sgi.com References: <1215139205.7187.33.camel@quadski> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1215139205.7187.33.camel@quadski> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1215144211 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4597 1.0000 0.0000 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 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.1, rules version 3.1.55101 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16716 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Fri, Jul 04, 2008 at 12:40:05PM +1000, Warwick Boote wrote: > Hi all, > > Do you know of setting or layered file system that enables me to define > a large buffer in main memory and cache writes to this buffer? I know there's wrapper libraries that do this - like FFIO - but I don't think there's a free one. However, why doesn't the page cache do what you want already? Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Thu Jul 3 22:14:15 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 03 Jul 2008 22:15:02 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m645EBqu018246 for ; Thu, 3 Jul 2008 22:14:14 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id PAA15768; Fri, 4 Jul 2008 15:15:05 +1000 Message-ID: <486DB1D9.20207@sgi.com> Date: Fri, 04 Jul 2008 15:15:05 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH] kill XFS_PURGE_INODE References: <20080616062634.GA5971@lst.de> <20080702192224.GB18817@lst.de> In-Reply-To: <20080702192224.GB18817@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16717 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs Christoph Hellwig wrote: > Ping? Already got a review from Dave. > Yeah, this is basically a substitute and replace. Okay, looks like there is also a s/VN_HOLD(XFS_ITOV())/IHOLD()/ thrown in too (which is what IHOLD is defined as). I'll check it in. --Tim > On Mon, Jun 16, 2008 at 08:26:34AM +0200, Christoph Hellwig wrote: >> Just a useless alias for IRELE. >> >> >> Signed-off-by: Christoph Hellwig >> >> Index: linux-2.6-xfs/fs/xfs/quota/xfs_qm.c >> =================================================================== >> --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_qm.c 2008-06-05 20:21:04.000000000 +0200 >> +++ linux-2.6-xfs/fs/xfs/quota/xfs_qm.c 2008-06-05 20:22:37.000000000 +0200 >> @@ -444,11 +444,11 @@ xfs_qm_unmount_quotas( >> } >> } >> if (uqp) { >> - XFS_PURGE_INODE(uqp); >> + IRELE(uqp); >> mp->m_quotainfo->qi_uquotaip = NULL; >> } >> if (gqp) { >> - XFS_PURGE_INODE(gqp); >> + IRELE(gqp); >> mp->m_quotainfo->qi_gquotaip = NULL; >> } >> out: >> @@ -1239,11 +1239,11 @@ xfs_qm_destroy_quotainfo( >> xfs_qm_list_destroy(&qi->qi_dqlist); >> >> if (qi->qi_uquotaip) { >> - XFS_PURGE_INODE(qi->qi_uquotaip); >> + IRELE(qi->qi_uquotaip); >> qi->qi_uquotaip = NULL; /* paranoia */ >> } >> if (qi->qi_gquotaip) { >> - XFS_PURGE_INODE(qi->qi_gquotaip); >> + IRELE(qi->qi_gquotaip); >> qi->qi_gquotaip = NULL; >> } >> mutex_destroy(&qi->qi_quotaofflock); >> @@ -1393,7 +1393,7 @@ xfs_qm_qino_alloc( >> * locked exclusively and joined to the transaction already. >> */ >> ASSERT(xfs_isilocked(*ip, XFS_ILOCK_EXCL)); >> - VN_HOLD(XFS_ITOV((*ip))); >> + IHOLD(*ip); >> >> /* >> * Make the changes in the superblock, and log those too. >> Index: linux-2.6-xfs/fs/xfs/quota/xfs_qm_syscalls.c >> =================================================================== >> --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_qm_syscalls.c 2008-05-23 09:31:39.000000000 +0200 >> +++ linux-2.6-xfs/fs/xfs/quota/xfs_qm_syscalls.c 2008-06-05 20:21:09.000000000 +0200 >> @@ -362,11 +362,11 @@ xfs_qm_scall_quotaoff( >> * if we don't need them anymore. >> */ >> if ((dqtype & XFS_QMOPT_UQUOTA) && XFS_QI_UQIP(mp)) { >> - XFS_PURGE_INODE(XFS_QI_UQIP(mp)); >> + IRELE(XFS_QI_UQIP(mp)); >> XFS_QI_UQIP(mp) = NULL; >> } >> if ((dqtype & (XFS_QMOPT_GQUOTA|XFS_QMOPT_PQUOTA)) && XFS_QI_GQIP(mp)) { >> - XFS_PURGE_INODE(XFS_QI_GQIP(mp)); >> + IRELE(XFS_QI_GQIP(mp)); >> XFS_QI_GQIP(mp) = NULL; >> } >> out_error: >> Index: linux-2.6-xfs/fs/xfs/quota/xfs_quota_priv.h >> =================================================================== >> --- linux-2.6-xfs.orig/fs/xfs/quota/xfs_quota_priv.h 2008-05-23 09:31:39.000000000 +0200 >> +++ linux-2.6-xfs/fs/xfs/quota/xfs_quota_priv.h 2008-06-05 20:21:09.000000000 +0200 >> @@ -158,9 +158,6 @@ for ((dqp) = (qlist)->qh_next; (dqp) != >> #define XFS_IS_SUSER_DQUOT(dqp) \ >> (!((dqp)->q_core.d_id)) >> >> -#define XFS_PURGE_INODE(ip) \ >> - IRELE(ip); >> - >> #define DQFLAGTO_TYPESTR(d) (((d)->dq_flags & XFS_DQ_USER) ? "USR" : \ >> (((d)->dq_flags & XFS_DQ_GROUP) ? "GRP" : \ >> (((d)->dq_flags & XFS_DQ_PROJ) ? "PRJ":"???"))) > ---end quoted text--- > From owner-xfs@oss.sgi.com Thu Jul 3 23:40:23 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 03 Jul 2008 23:40:26 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m646eM2m025979 for ; Thu, 3 Jul 2008 23:40:23 -0700 X-ASG-Debug-ID: 1215153685-1a70001c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mailgate01.web.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 10AB52B6700 for ; Thu, 3 Jul 2008 23:41:25 -0700 (PDT) Received: from mailgate01.web.de (mailgate01.web.de [217.72.192.251]) by cuda.sgi.com with ESMTP id niGYqJEbPdcJabmX for ; Thu, 03 Jul 2008 23:41:25 -0700 (PDT) Received: by lxjbe.webde.local (Postfix, from userid 1000) id DC94A41241; Fri, 4 Jul 2008 08:41:26 +0200 (CEST) (R201) Date: Fri, 4 Jul 2008 08:41:26 +0200 From: Jens Beyer To: xfs@oss.sgi.com X-ASG-Orig-Subj: XFS perfomance degradation on growing filesystem size Subject: XFS perfomance degradation on growing filesystem size Message-ID: <20080704064126.GA14847@webde.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: mailgate01.web.de[217.72.192.251] X-Barracuda-Start-Time: 1215153686 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0071 1.0000 -1.9747 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.97 X-Barracuda-Spam-Status: No, SCORE=-1.97 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.1, rules version 3.1.55111 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16718 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jens.beyer@1und1.de Precedence: bulk X-list: xfs Hi, I have encountered a strange performance problem during some hardware evaluation tests: I am running a benchmark to measure especially random read/write I/O on an raid device and found that (under some circumstances) the performance of Random Read I/O is inverse proportional to the size of the tested XFS filesystem. In numbers this means that on a 100GB partition I get a throughput of ~25 MB/s and on the same hardware at 1TB FS size only 18 MB/s (and at 2+ TB like 14 MB/s) (absolute values depend on options, kernel version and are for random read i/o at 8k test block size). Surprisingly this degradation does not affect random write or seq read/write (at least not by this factor). Even more surprising using an ext3 filesystem I always get ~25 MB/s. My test setups included: - kernel vanilla 2.6.24, 2.6.25.8, 2.6.24-ubuntu_8.04, 2.6.20, 32/64bit - xfsprogs v2.9.8/7 - benchmarks: - iozone: iozone -i 0 -i 2 -r 8k -s 1g -t 32 -+p 100 - tiobench: tiobench.pl --size 32000 --random 100000 --block 8192 \ --dir /mnt --threads 32 --numruns 1 (Bench is for 8k blocksize, 32 Threads with enough data to be beyond simple ram cache). - The hardware itself where recent HP dual/quadcores with 4GB RAM with external SAS Raids (MSA60, MSA70) and 15k SAS disks (different types). I tried most options like but not limited to: agcount, logbufs, nobarrier, blockdev --setra, (...), but none had an significant impact. All benchmarks where run using deadline i/o scheduler Does anyone has a clue on what is going on - or even can reproduce this? Or, is this the default behavior? Could this be an hardware problem ? Thanks for any comment, Jens From owner-xfs@oss.sgi.com Thu Jul 3 23:44:55 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 03 Jul 2008 23:44:58 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m646iquR026566 for ; Thu, 3 Jul 2008 23:44:53 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id QAA17395; Fri, 4 Jul 2008 16:45:51 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1116) id 8798E58C4C29; Fri, 4 Jul 2008 16:45:51 +1000 (EST) To: sgi.bugs.xfs@engr.sgi.com, xfs@oss.sgi.com Subject: TAKE 981498 - kill XFS_PURGE_INODE Message-Id: <20080704064551.8798E58C4C29@chook.melbourne.sgi.com> Date: Fri, 4 Jul 2008 16:45:51 +1000 (EST) From: tes@sgi.com (Tim Shimmin) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16719 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs s/XFS_PURGE_INODE/IRELE/g s/VN_HOLD(XFS_ITOV())/IHOLD()/ Signed-off-by: Christoph Hellwig Date: Fri Jul 4 16:44:37 AEST 2008 Workarea: chook.melbourne.sgi.com:/build/tes/2.6.x-xfs-quilt Inspected by: hch@lst.de,dchinner@agami.com The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:31405a fs/xfs/quota/xfs_quota_priv.h - 1.12 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_quota_priv.h.diff?r1=text&tr1=1.12&r2=text&tr2=1.11&f=h - s/XFS_PURGE_INODE/IRELE/g fs/xfs/quota/xfs_qm_syscalls.c - 1.44 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm_syscalls.c.diff?r1=text&tr1=1.44&r2=text&tr2=1.43&f=h - s/XFS_PURGE_INODE/IRELE/g fs/xfs/quota/xfs_qm.c - 1.71 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/quota/xfs_qm.c.diff?r1=text&tr1=1.71&r2=text&tr2=1.70&f=h - s/XFS_PURGE_INODE/IRELE/g From owner-xfs@oss.sgi.com Fri Jul 4 00:10:00 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 04 Jul 2008 00:10:04 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m6479vK1030505 for ; Fri, 4 Jul 2008 00:09:58 -0700 Received: from boing.melbourne.sgi.com (boing.melbourne.sgi.com [134.14.55.141]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA17871; Fri, 4 Jul 2008 17:10:53 +1000 Message-ID: <486DCCFD.1070007@sgi.com> Date: Fri, 04 Jul 2008 17:10:53 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: xfs@oss.sgi.com Subject: Re: [PATCH] fix compilation without CONFIG_PROC_FS References: <20080702193630.GA19715@lst.de> In-Reply-To: <20080702193630.GA19715@lst.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16720 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs I'll check it in. --Tim Christoph Hellwig wrote: > Signed-off-by: Christoph Hellwig > > Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_stats.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_stats.h 2008-06-27 15:16:21.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_stats.h 2008-06-27 15:19:18.000000000 +0200 > @@ -146,11 +146,12 @@ extern void xfs_cleanup_procfs(void); > > static inline int xfs_init_procfs(void) > { > - return 0 > -}; > + return 0; > +} > + > static inline void xfs_cleanup_procfs(void) > { > -}; > +} > > #endif /* !CONFIG_PROC_FS */ > > From owner-xfs@oss.sgi.com Fri Jul 4 00:52:36 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 04 Jul 2008 00:52:43 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with SMTP id m647qXg7005370 for ; Fri, 4 Jul 2008 00:52:35 -0700 Received: from chook.melbourne.sgi.com (chook.melbourne.sgi.com [134.14.54.237]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA18618; Fri, 4 Jul 2008 17:53:31 +1000 Received: by chook.melbourne.sgi.com (Postfix, from userid 1116) id EF20858C4C29; Fri, 4 Jul 2008 17:53:30 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: TAKE 984019 - fix compilation without CONFIG_PROC_FS Message-Id: <20080704075330.EF20858C4C29@chook.melbourne.sgi.com> Date: Fri, 4 Jul 2008 17:53:30 +1000 (EST) From: tes@sgi.com (Tim Shimmin) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16721 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tes@sgi.com Precedence: bulk X-list: xfs fix compilation without CONFIG_PROC_FS Signed-off-by: Christoph Hellwig Date: Fri Jul 4 17:52:09 AEST 2008 Workarea: chook.melbourne.sgi.com:/build/tes/2.6.x-xfs-quilt Inspected by: hch@lst.de The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:31408a fs/xfs/linux-2.6/xfs_stats.h - 1.19 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/linux-2.6/xfs_stats.h.diff?r1=text&tr1=1.19&r2=text&tr2=1.18&f=h - fix compilation without CONFIG_PROC_FS very obvious problem :) From owner-xfs@oss.sgi.com Fri Jul 4 00:59:25 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 04 Jul 2008 00:59:28 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m647xNPK006061 for ; Fri, 4 Jul 2008 00:59:25 -0700 X-ASG-Debug-ID: 1215158425-29cf019a0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from build-svl-1.agami.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 03A3F187862B for ; Fri, 4 Jul 2008 01:00:26 -0700 (PDT) Received: from build-svl-1.agami.com (colo-nat-pool.agami.com [216.218.227.40]) by cuda.sgi.com with ESMTP id MzlpqpIUkyrhGccQ for ; Fri, 04 Jul 2008 01:00:26 -0700 (PDT) Received: from build-svl-1.agami.com (localhost.localdomain [127.0.0.1]) by build-svl-1.agami.com (8.13.7/8.13.7) with ESMTP id m647xgPR032635; Fri, 4 Jul 2008 00:59:42 -0700 Received: (from dchinner@localhost) by build-svl-1.agami.com (8.13.7/8.13.7/Submit) id m647xfMR032634; Fri, 4 Jul 2008 00:59:41 -0700 X-Authentication-Warning: build-svl-1.agami.com: dchinner set sender to dchinner@agami.com using -f Date: Fri, 4 Jul 2008 00:59:41 -0700 From: Dave Chinner To: Jens Beyer Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS perfomance degradation on growing filesystem size Subject: Re: XFS perfomance degradation on growing filesystem size Message-ID: <20080704075941.GP16257@build-svl-1.agami.com> Mail-Followup-To: Jens Beyer , xfs@oss.sgi.com References: <20080704064126.GA14847@webde.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080704064126.GA14847@webde.de> User-Agent: Mutt/1.4.2.3i X-Barracuda-Connect: colo-nat-pool.agami.com[216.218.227.40] X-Barracuda-Start-Time: 1215158427 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0391 1.0000 -1.7685 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.77 X-Barracuda-Spam-Status: No, SCORE=-1.77 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.1, rules version 3.1.55117 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16722 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: dchinner@agami.com Precedence: bulk X-list: xfs On Fri, Jul 04, 2008 at 08:41:26AM +0200, Jens Beyer wrote: > > Hi, > > I have encountered a strange performance problem during some > hardware evaluation tests: > > I am running a benchmark to measure especially random read/write > I/O on an raid device and found that (under some circumstances) > the performance of Random Read I/O is inverse proportional to the > size of the tested XFS filesystem. > > In numbers this means that on a 100GB partition I get a throughput > of ~25 MB/s and on the same hardware at 1TB FS size only 18 MB/s > (and at 2+ TB like 14 MB/s) (absolute values depend on options, > kernel version and are for random read i/o at 8k test block size). Of course - as the filesystem size grows, so does the amount of each disk in use so the average seek distance increases and hence read I/Os take longer. Cheers, Dave. -- Dave Chinner dchinner@agami.com From owner-xfs@oss.sgi.com Fri Jul 4 03:17:34 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 04 Jul 2008 03:17:37 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m64AHWXd015038 for ; Fri, 4 Jul 2008 03:17:34 -0700 X-ASG-Debug-ID: 1215166711-258102100000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bby1mta02.pmc-sierra.bc.ca (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 051072B6EA1 for ; Fri, 4 Jul 2008 03:18:34 -0700 (PDT) Received: from bby1mta02.pmc-sierra.bc.ca (bby1mta02.pmc-sierra.com [216.241.235.117]) by cuda.sgi.com with ESMTP id esAysl4yWohFJAJn for ; Fri, 04 Jul 2008 03:18:34 -0700 (PDT) Received: from bby1mta02.pmc-sierra.bc.ca (localhost.pmc-sierra.bc.ca [127.0.0.1]) by localhost (Postfix) with SMTP id 205818E00AB; Fri, 4 Jul 2008 03:21:07 -0700 (PDT) Received: from bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca (BBY1EXG02.pmc-sierra.bc.ca [216.241.231.167]) by bby1mta02.pmc-sierra.bc.ca (Postfix) with SMTP id 074348E00A6; Fri, 4 Jul 2008 03:21:07 -0700 (PDT) Received: from BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca ([216.241.231.156]) by bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jul 2008 03:19:04 -0700 Received: from [209.68.166.73] ([209.68.166.73]) by BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca with Microsoft SMTPSVC(6.0.3790.2825); Fri, 4 Jul 2008 03:19:03 -0700 Message-ID: <486DF8F0.5010700@pmc-sierra.com> Date: Fri, 04 Jul 2008 15:48:24 +0530 From: Sagar Borikar Organization: PMC Sierra Inc User-Agent: Thunderbird 2.0.0.14 (X11/20080421) MIME-Version: 1.0 To: Eric Sandeen CC: Nathan Scott , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Xfs Access to block zero exception and system crash Subject: Re: Xfs Access to block zero exception and system crash References: <20080628000516.GD29319@disturbed> <340C71CD25A7EB49BFA81AE8C8392667028A1CA7@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080629215647.GJ29319@disturbed> <20080630034112.055CF18904C4@bby1mta01.pmc-sierra.bc.ca> <4868B46C.9000200@pmc-sierra.com> <20080701064437.GR29319@disturbed> <486B01A6.4030104@pmc-sierra.com> <20080702051337.GX29319@disturbed> <486B13AD.2010500@pmc-sierra.com> <1214979191.6025.22.camel@verge.scott.net.au> <20080702065652.GS14251@build-svl-1.agami.com> <486B6062.6040201@pmc-sierra.com> <486C4F89.9030009@sandeen.net> <486C6053.7010503@pmc-sierra.com> <486CE9EA.90502@sandeen.net> In-Reply-To: <486CE9EA.90502@sandeen.net> Content-Type: multipart/mixed; boundary="------------000503030107080700050305" X-OriginalArrivalTime: 04 Jul 2008 10:19:04.0320 (UTC) FILETIME=[629FF000:01C8DDBF] X-Barracuda-Connect: bby1mta02.pmc-sierra.com[216.241.235.117] X-Barracuda-Start-Time: 1215166715 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.1, rules version 3.1.55127 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16723 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sagar_borikar@pmc-sierra.com Precedence: bulk X-list: xfs This is a multi-part message in MIME format. --------------000503030107080700050305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eric Sandeen wrote: > Sagar Borikar wrote: > >> Eric Sandeen wrote: >> > > > >>>> Eric, Could you please let me know about bits and pieces that we need to >>>> remember while back porting xfs to 2.6.18? >>>> If you share patches which takes care of it, that would be great. >>>> >>>> >>> http://sandeen.net/rhel5_xfs/xfs-2.6.25-for-rhel5-testing.tar.bz2 >>> >>> should be pretty close. It was quick 'n' dirty and it has some warts >>> but would give an idea of what backporting was done (see patches/ and >>> the associated quilt series; quilt push -a to apply them all) >>> >>> >> Thanks a lot Eric. I'll go through it .I am actually trying another >> option of regularly defragmenting the file system under stress. >> > > Ok, but that won't get to the bottom of the problem. It might alleviate > it at best, but if I were shipping a product using xfs I'd want to know > that it was properly solved. :) > > Even we too don't want to leave it as it is. I still am working on back porting the latest xfs code. Your patches are helping a lot . Just to check whether that issue lies with 2.6.18 or MIPS port, I tested it on 2.6.24 x86 platform. Here we created a loop back device of 10 GB and mounted xfs on that. What I observe that xfs_repair reports quite a few bad blocks and bad extents here as well. So is developing bad blocks and extents normal behavior in xfs which would be recovered in background or is it a bug? I still didn't see the exception but the bad blocks and extents are generated within 10 minutes or running the tests. Attaching the log . > The tarball above should give you almost everything you need to run your > testcase with current xfs code on your older kernel to see if the bug > persists or if it's been fixed upstream, in which case you have a > relatively easy path to an actual solution that your customers can > depend on. > > >> I wanted to understand couple of things for using xfs_fsr utility: >> >> 1. What should be the state of filesystem when I am running xfs_fsr. >> Ideally we should stop all io before running defragmentation. >> > > you can run in any state. Some files will not get defragmented due to > busy-ness or other conditions; look at the xfs_swap_extents() function > in the kernel which is very well documented; some cases return EBUSY. > > >> 2. How effective is the utility when ran on highly fragmented file >> system? I saw that if filesystem is 99.89% fragmented, the recovery is >> very slow. It took around 25 min to clean up 100GB JBOD volume and after >> that system was fragmented to 82%. So I was confused on how exactly the >> fragmentation works. >> > > Again read the code, but basically it tries to preallocate as much space > as the file is currently using, then checks that it is more contiguous > space than the file currently has and if so, it copies the data from old > to new and swaps the new allocation for the old. Note, this involves a > fair amount of IO. > > Also don't get hung up on that fragmentation factor, at least not until > you've read xfs_db code to see how it's reported, and you've thought > about what that means. For example: a 100G filesystem with 10 10G files > each with 5x2G extents will report 80% fragmentation. Now, ask > yourself, is a 10G file in 5x2G extents "bad" fragmentation? > > Agreed as in x86 too I see 99.12% fragmentation when I run above mentioned test. and xfs_fsr doesn't help much even after freezing the file system. >> Any pointers on probable optimum use of xfs_fsr? >> 3. Any precautions I need to take when working with that from data >> consistency, robustness point of view? Any disadvantages? >> > > Anything which corrupts data is a bug, and I'm not aware of any such > bugs in the defragmentation process. > > Assuming that we get some improvement by running xfs_fsr, is it safe to run regularly in some periodic interval the defragmentation utility? >> 4. Any threshold for starting the defragmentation on xfs? >> > > Pretty well determined by your individual use case and requirements, I > think. > > -Eric > Thanks for the detailed response Eric. Sagar --------------000503030107080700050305 Content-Type: text/plain; name="xfs_repair_log" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xfs_repair_log" bad nblocks 13345 for inode 50331785, would reset to 19431 bad nextents 156 for inode 50331785, would reset to 251 - process newly discovered inodes... Phase 4 - check for duplicate blocks... - setting up duplicate extent list... - check for inodes claiming duplicate blocks... - agno = 1 - agno = 0 entry "testfile" in shortform directory 132 references free inode 142 would have junked entry "testfile" in directory inode 132 entry "testfile" in shortform directory 138 references free inode 143 would have junked entry "testfile" in directory inode 138 entry "testfile" in shortform directory 140 references free inode 144 would have junked entry "testfile" in directory inode 140 bad nblocks 15848 for inode 141, would reset to 18634 bad nextents 269 for inode 141, would reset to 306 bad nblocks 18888 for inode 16777350, would reset to 19144 bad nextents 303 for inode 16777350, would reset to 309 bad nblocks 18704 for inode 16777351, would reset to 19144 bad nextents 291 for inode 16777351, would reset to 299 bad fwd (right) sibling pointer (saw 107678 should be NULLDFSBNO) in inode 142 ((null) fork) bmap btree block 236077307437232 would have cleared inode 142 bad fwd (right) sibling pointer (saw 1139882 should be NULLDFSBNO) in inode 143 ((null) fork) bmap btree block 4556402090352816 would have cleared inode 143 bad fwd (right) sibling pointer (saw 1138473 should be NULLDFSBNO) in inode 144 ((null) fork) bmap btree block 4564279060373680 would have cleared inode 144 bad nblocks 13825 for inode 145, would reset to 18503 bad nextents 221 for inode 145, would reset to 222 - agno = 2 entry "testfile" in shortform directory 33595588 references free inode 33595593 would have junked entry "testfile" in directory inode 33595588 bad nblocks 18704 for inode 33595589, would reset to 19121 bad nextents 306 for inode 33595589, would reset to 314 bad nblocks 18704 for inode 33595590, would reset to 19432 bad nextents 302 for inode 33595590, would reset to 313 bad nblocks 18640 for inode 33595591, would reset to 19432 bad nextents 311 for inode 33595591, would reset to 317 bad nblocks 18888 for inode 33595592, would reset to 19432 bad nextents 312 for inode 33595592, would reset to 322 bad fwd (right) sibling pointer (saw 104113 should be NULLDFSBNO) in inode 33595593 ((null) fork) bmap btree block 9041060911947952 would have cleared inode 33595593 - agno = 3 bad nblocks 18888 for inode 50331781, would reset to 19432 bad nextents 315 for inode 50331781, would reset to 324 bad nblocks 18888 for inode 50331782, would reset to 19432 bad nextents 326 for inode 50331782, would reset to 333 bad nblocks 18888 for inode 50331783, would reset to 19432 bad nblocks 18428 for inode 50331784, would reset to 19784 bad nextents 285 for inode 50331784, would reset to 306 bad nblocks 18704 for inode 16777352, would reset to 19144 bad nextents 311 for inode 16777352, would reset to 315 bad nblocks 13345 for inode 50331785, would reset to 19431 bad nextents 156 for inode 50331785, would reset to 251 bad nblocks 18888 for inode 16777353, would reset to 19144 bad nextents 318 for inode 16777353, would reset to 321 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - agno = 0 entry "testfile" in shortform directory inode 132 points to free inode 142would junk entry entry "testfile" in shortform directory inode 138 points to free inode 143would junk entry entry "testfile" in shortform directory inode 140 points to free inode 144would junk entry - agno = 1 - agno = 2 entry "testfile" in shortform directory inode 33595588 points to free inode 33595593would junk entry - agno = 3 - traversal finished ... - moving disconnected inodes to lost+found ... Phase 7 - verify link counts... No modify flag set, skipping filesystem flush and exiting. XFS_REPAIR Summary Fri Jul 4 15:34:47 2008 Phase Start End Duration Phase 1: 07/04 15:34:00 07/04 15:34:04 4 seconds Phase 2: 07/04 15:34:04 07/04 15:34:31 27 seconds Phase 3: 07/04 15:34:31 07/04 15:34:47 16 seconds Phase 4: 07/04 15:34:47 07/04 15:34:47 Phase 5: Skipped Phase 6: 07/04 15:34:47 07/04 15:34:47 Phase 7: 07/04 15:34:47 07/04 15:34:47 Total run time: 47 seconds --------------000503030107080700050305-- From owner-xfs@oss.sgi.com Fri Jul 4 05:07:44 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 04 Jul 2008 05:07:54 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,STOX_REPLY_TYPE autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m64C7iKP026200 for ; Fri, 4 Jul 2008 05:07:44 -0700 X-ASG-Debug-ID: 1215173326-697300550000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from tyo202.gate.nec.co.jp (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id CAC0BDA407E for ; Fri, 4 Jul 2008 05:08:47 -0700 (PDT) Received: from tyo202.gate.nec.co.jp (TYO202.gate.nec.co.jp [202.32.8.206]) by cuda.sgi.com with ESMTP id SeAPJYjmHsfYpsN7 for ; Fri, 04 Jul 2008 05:08:47 -0700 (PDT) Received: from mailgate3.nec.co.jp (mailgate54.nec.co.jp [10.7.69.195]) by tyo202.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id m64C8BUD015874; Fri, 4 Jul 2008 21:08:11 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id m64C8B318276; Fri, 4 Jul 2008 21:08:11 +0900 (JST) Received: from yonosuke.jp.nec.com (yonosuke.jp.nec.com [10.26.220.15]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id m64C8AGk027786; Fri, 4 Jul 2008 21:08:10 +0900 (JST) Received: from TNESB07336 ([10.64.168.65] [10.64.168.65]) by mail.jp.nec.com with ESMTP; Fri, 4 Jul 2008 21:08:10 +0900 Message-Id: From: "Takashi Sato" To: "Eric Sandeen" , "Alasdair G Kergon" , "Dave Chinner" Cc: , , "Andrew Morton" , , , , "Christoph Hellwig" , , , References: <20080630212450t-sato@mail.jp.nec.com> <20080701081026.GB16691@infradead.org> <20080701105251.GC22522@agk.fab.redhat.com> <9942A69CB65D4A41B39F36AF8EEF6F22@nsl.ad.nec.co.jp> <20080703124709.GI22522@agk.fab.redhat.com> <20080703221133.GA29319@disturbed> In-Reply-To: <20080703221133.GA29319@disturbed> X-ASG-Orig-Subj: Re: [dm-devel] Re: [PATCH 3/3] Add timeout feature Subject: Re: [dm-devel] Re: [PATCH 3/3] Add timeout feature Date: Fri, 4 Jul 2008 21:08:09 +0900 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6000.16480 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16545 X-Barracuda-Connect: TYO202.gate.nec.co.jp[202.32.8.206] X-Barracuda-Start-Time: 1215173327 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.1, rules version 3.1.55133 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16724 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: t-sato@yk.jp.nec.com Precedence: bulk X-list: xfs Hi Alasdair, Eric and Dave, > On Thu, Jul 03, 2008 at 01:47:10PM +0100, Alasdair G Kergon wrote: >> On Thu, Jul 03, 2008 at 09:11:05PM +0900, Takashi Sato wrote: >> > If the freezer accesses the frozen filesystem and causes a deadlock, >> > the above ideas can't solve it >> >> But you could also say that if the 'freezer' process accesses the frozen >> filesystem and deadlocks then that's just a bug and that userspace code >> should be fixed and there's no need to introduce the complexity of a >> timeout parameter. > > Seconded - that was also my primary objection to the timeout code. I will consider removing the timeout. >> The point I'm trying to make here is: >> Under what real-world circumstances might multiple concurrent freezing >> attempts occur, and which of A, B or C (or other variations) would be >> the most appropriate way of handling such situations? >> >> A common example is people running xfs_freeze followed by an lvm command >> which also attempts to freeze the filesystem. > > Yes, I've seen that reported a number of times. > >> I can see a case for B or C, but personally I prefer A: >> >> > > 1 succeeds, freezes >> > > 2 succeeds, remains frozen >> > > 3 succeeds, remains frozen >> > > 4 succeeds, thaws > > Agreed, though I'd modify the definition of that case to be "remain > frozen until the last thaw occurs". That has the advantage that > it's relatively simple to implement with just a counter... I agree this idea. But I have one concern. When device-mapper's freeze follows FIFREEZE, can device-mapper freeze only device-mapper's part correctly? And when device-mapper's thaw follows FITHAW, can device-mapper thaw only device-mapper's part? Cheers, Takashi From owner-xfs@oss.sgi.com Fri Jul 4 05:26:40 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 04 Jul 2008 05:26:42 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m64CQeKH027761 for ; Fri, 4 Jul 2008 05:26:40 -0700 X-ASG-Debug-ID: 1215174462-6e5200320000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D2A201878EEC for ; Fri, 4 Jul 2008 05:27:42 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id 8cv2Ffabi6dDN0sJ for ; Fri, 04 Jul 2008 05:27:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFCybUh5LBzp/2dsb2JhbACwYQ X-IronPort-AV: E=Sophos;i="4.30,302,1212330600"; d="scan'208";a="141906783" Received: from ppp121-44-28-233.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.28.233]) by ipmail01.adl6.internode.on.net with ESMTP; 04 Jul 2008 21:57:33 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KEkNr-0004Z7-F8; Fri, 04 Jul 2008 22:27:27 +1000 Date: Fri, 4 Jul 2008 22:27:26 +1000 From: Dave Chinner To: Sagar Borikar Cc: Eric Sandeen , Nathan Scott , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Xfs Access to block zero exception and system crash Subject: Re: Xfs Access to block zero exception and system crash Message-ID: <20080704122726.GG29319@disturbed> Mail-Followup-To: Sagar Borikar , Eric Sandeen , Nathan Scott , xfs@oss.sgi.com References: <486B01A6.4030104@pmc-sierra.com> <20080702051337.GX29319@disturbed> <486B13AD.2010500@pmc-sierra.com> <1214979191.6025.22.camel@verge.scott.net.au> <20080702065652.GS14251@build-svl-1.agami.com> <486B6062.6040201@pmc-sierra.com> <486C4F89.9030009@sandeen.net> <486C6053.7010503@pmc-sierra.com> <486CE9EA.90502@sandeen.net> <486DF8F0.5010700@pmc-sierra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <486DF8F0.5010700@pmc-sierra.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1215174463 X-Barracuda-Bayes: INNOCENT GLOBAL 0.1737 1.0000 -0.9694 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.97 X-Barracuda-Spam-Status: No, SCORE=-0.97 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.1, rules version 3.1.55134 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16725 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Fri, Jul 04, 2008 at 03:48:24PM +0530, Sagar Borikar wrote: > Even we too don't want to leave it as it is. I still am working on back > porting the latest xfs code. > Your patches are helping a lot . > Just to check whether that issue lies with 2.6.18 or MIPS port, I tested > it on 2.6.24 x86 platform. > Here we created a loop back device of 10 GB and mounted xfs on that. And the script that generates the workload can be found where? Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Fri Jul 4 08:32:18 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 04 Jul 2008 08:32:42 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m64FWILs010600 for ; Fri, 4 Jul 2008 08:32:18 -0700 X-ASG-Debug-ID: 1215185601-6f1f03660000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id BBA21DA4502 for ; Fri, 4 Jul 2008 08:33:21 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id uO6rbXTRI59yw1tF for ; Fri, 04 Jul 2008 08:33:21 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id A600BAC626C; Fri, 4 Jul 2008 10:33:20 -0500 (CDT) Message-ID: <486E42C0.4090108@sandeen.net> Date: Fri, 04 Jul 2008 10:33:20 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Sagar Borikar CC: Nathan Scott , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Xfs Access to block zero exception and system crash Subject: Re: Xfs Access to block zero exception and system crash References: <20080628000516.GD29319@disturbed> <340C71CD25A7EB49BFA81AE8C8392667028A1CA7@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <20080629215647.GJ29319@disturbed> <20080630034112.055CF18904C4@bby1mta01.pmc-sierra.bc.ca> <4868B46C.9000200@pmc-sierra.com> <20080701064437.GR29319@disturbed> <486B01A6.4030104@pmc-sierra.com> <20080702051337.GX29319@disturbed> <486B13AD.2010500@pmc-sierra.com> <1214979191.6025.22.camel@verge.scott.net.au> <20080702065652.GS14251@build-svl-1.agami.com> <486B6062.6040201@pmc-sierra.com> <486C4F89.9030009@sandeen.net> <486C6053.7010503@pmc-sierra.com> <486CE9EA.90502@sandeen.net> <486DF8F0.5010700@pmc-sierra.com> In-Reply-To: <486DF8F0.5010700@pmc-sierra.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1215185601 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.1, rules version 3.1.55145 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16726 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Sagar Borikar wrote: >> > Even we too don't want to leave it as it is. I still am working on back > porting the latest xfs code. > Your patches are helping a lot . > Just to check whether that issue lies with 2.6.18 or MIPS port, I tested > it on 2.6.24 x86 platform. > Here we created a loop back device of 10 GB and mounted xfs on that. > What I observe that xfs_repair reports quite a few bad blocks and bad > extents here as well. > So is developing bad blocks and extents normal behavior in xfs which > would be recovered > in background or is it a bug? I still didn't see the exception but the > bad blocks and extents are > generated within 10 minutes or running the tests. > Attaching the log . Repair finding corruption indicates a bug (or hardware problem) somewhere. As a long shot you might re-test with this patch in place: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff_plain;h=6ab455eeaff6893cd06da33843e840d888cdc04a But, as Dave said, please also provide the testcase. -Eric From owner-xfs@oss.sgi.com Fri Jul 4 10:29:13 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 04 Jul 2008 10:29:15 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m64HTDCi017373 for ; Fri, 4 Jul 2008 10:29:13 -0700 X-ASG-Debug-ID: 1215192616-401802440000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bby1mta03.pmc-sierra.bc.ca (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id DAA4E2B9B44 for ; Fri, 4 Jul 2008 10:30:16 -0700 (PDT) Received: from bby1mta03.pmc-sierra.bc.ca (bby1mta03.pmc-sierra.com [216.241.235.118]) by cuda.sgi.com with ESMTP id YbYGtgpMB9d3OeXn for ; Fri, 04 Jul 2008 10:30:16 -0700 (PDT) Received: from bby1mta03.pmc-sierra.bc.ca (localhost.pmc-sierra.bc.ca [127.0.0.1]) by localhost (Postfix) with SMTP id A42B81070055; Fri, 4 Jul 2008 10:32:54 -0700 (PDT) Received: from bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca (BBY1EXG02.pmc-sierra.bc.ca [216.241.231.167]) by bby1mta03.pmc-sierra.bc.ca (Postfix) with SMTP id 57A991070078; Fri, 4 Jul 2008 10:32:52 -0700 (PDT) Received: from BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca ([216.241.231.156]) by bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jul 2008 10:30:50 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-ASG-Orig-Subj: RE: Xfs Access to block zero exception and system crash Subject: RE: Xfs Access to block zero exception and system crash Date: Fri, 4 Jul 2008 10:30:47 -0700 Message-ID: <340C71CD25A7EB49BFA81AE8C839266702997641@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> In-Reply-To: <20080704122726.GG29319@disturbed> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Xfs Access to block zero exception and system crash Thread-Index: Acjd0XqTpmYpOyWKRFqgEcr8p0zAnAAKfNgg References: <486B01A6.4030104@pmc-sierra.com> <20080702051337.GX29319@disturbed> <486B13AD.2010500@pmc-sierra.com> <1214979191.6025.22.camel@verge.scott.net.au> <20080702065652.GS14251@build-svl-1.agami.com> <486B6062.6040201@pmc-sierra.com> <486C4F89.9030009@sandeen.net> <486C6053.7010503@pmc-sierra.com> <486CE9EA.90502@sandeen.net> <486DF8F0.5010700@pmc-sierra.com> <20080704122726.GG29319@disturbed> From: "Sagar Borikar" To: "Dave Chinner" Cc: "Eric Sandeen" , "Nathan Scott" , X-OriginalArrivalTime: 04 Jul 2008 17:30:50.0943 (UTC) FILETIME=[B42CE4F0:01C8DDFB] X-PMX-Version: 5.4.2.338381, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.7.4.171340 X-PMC-SpamCheck: Gauge=IIIIIII, Probability=7%, Report='BODY_SIZE_1000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_700_799 0, __BOUNCE_CHALLENGE_SUBJ 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __STOCK_PHRASE_7 0' X-Barracuda-Connect: bby1mta03.pmc-sierra.com[216.241.235.118] X-Barracuda-Start-Time: 1215192616 X-Barracuda-Bayes: INNOCENT GLOBAL 0.2293 1.0000 -0.6770 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= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.55151 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id m64HTDCi017375 X-archive-position: 16727 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Sagar_Borikar@pmc-sierra.com Precedence: bulk X-list: xfs The script is pretty straight forward: While [ 1 ] Do Cp -f $1 $2 Done Where I pass the first parameter as the 300+ MB file in one directory and $2 are is other directory. I run 30 instances of the script in parallel. Thanks Sagar On Fri, Jul 04, 2008 at 03:48:24PM +0530, Sagar Borikar wrote: > Even we too don't want to leave it as it is. I still am working on back > porting the latest xfs code. > Your patches are helping a lot . > Just to check whether that issue lies with 2.6.18 or MIPS port, I tested > it on 2.6.24 x86 platform. > Here we created a loop back device of 10 GB and mounted xfs on that. And the script that generates the workload can be found where? Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Fri Jul 4 10:34:07 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 04 Jul 2008 10:34:09 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m64HY7x0017997 for ; Fri, 4 Jul 2008 10:34:07 -0700 X-ASG-Debug-ID: 1215192910-0e8200f90000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 29A2C12DB36A for ; Fri, 4 Jul 2008 10:35:10 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id ZXpsJwPZE96jDeNf for ; Fri, 04 Jul 2008 10:35:10 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 7CCCBAC626C; Fri, 4 Jul 2008 12:35:09 -0500 (CDT) Message-ID: <486E5F4D.1010009@sandeen.net> Date: Fri, 04 Jul 2008 12:35:09 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Sagar Borikar CC: Dave Chinner , Nathan Scott , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Xfs Access to block zero exception and system crash Subject: Re: Xfs Access to block zero exception and system crash References: <486B01A6.4030104@pmc-sierra.com> <20080702051337.GX29319@disturbed> <486B13AD.2010500@pmc-sierra.com> <1214979191.6025.22.camel@verge.scott.net.au> <20080702065652.GS14251@build-svl-1.agami.com> <486B6062.6040201@pmc-sierra.com> <486C4F89.9030009@sandeen.net> <486C6053.7010503@pmc-sierra.com> <486CE9EA.90502@sandeen.net> <486DF8F0.5010700@pmc-sierra.com> <20080704122726.GG29319@disturbed> <340C71CD25A7EB49BFA81AE8C839266702997641@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> In-Reply-To: <340C71CD25A7EB49BFA81AE8C839266702997641@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1215192911 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.1, rules version 3.1.55151 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16728 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Sagar Borikar wrote: > The script is pretty straight forward: > > While [ 1 ] > Do > Cp -f $1 $2 > Done > > Where I pass the first parameter as the 300+ MB file in one directory > and $2 are is other directory. I run 30 instances of the script in > parallel. Copying the same file to the same directory, or 30 different files to 30 different directories? Or the ame file to 30 different directories? If different directories what is the layout of the target directories? Etc... -Eric From owner-xfs@oss.sgi.com Fri Jul 4 10:50:09 2008 Received: with ECARTIS (v1.0.0; list xfs); Fri, 04 Jul 2008 10:50:11 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m64Ho9Tk021003 for ; Fri, 4 Jul 2008 10:50:09 -0700 X-ASG-Debug-ID: 1215193872-581201ad0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bby1mta01.pmc-sierra.bc.ca (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 115D12B8A17 for ; Fri, 4 Jul 2008 10:51:12 -0700 (PDT) Received: from bby1mta01.pmc-sierra.bc.ca (bby1mta01.pmc-sierra.com [216.241.235.116]) by cuda.sgi.com with ESMTP id NcJj7Sk7q68QF8Ar for ; Fri, 04 Jul 2008 10:51:12 -0700 (PDT) Received: from bby1mta01.pmc-sierra.bc.ca (localhost.pmc-sierra.bc.ca [127.0.0.1]) by localhost (Postfix) with SMTP id 6B3F818900CE; Fri, 4 Jul 2008 10:54:22 -0700 (PDT) Received: from bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca (BBY1EXG02.pmc-sierra.bc.ca [216.241.231.167]) by bby1mta01.pmc-sierra.bc.ca (Postfix) with SMTP id 5861718900CC; Fri, 4 Jul 2008 10:54:22 -0700 (PDT) Received: from BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca ([216.241.231.156]) by bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Jul 2008 10:51:49 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-ASG-Orig-Subj: RE: Xfs Access to block zero exception and system crash Subject: RE: Xfs Access to block zero exception and system crash Date: Fri, 4 Jul 2008 10:51:47 -0700 Message-ID: <340C71CD25A7EB49BFA81AE8C839266702997658@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> In-Reply-To: <486E5F4D.1010009@sandeen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Xfs Access to block zero exception and system crash Thread-Index: Acjd/GZGEkjrCO1FRleVG+92X5o3mgAATRaw References: <486B01A6.4030104@pmc-sierra.com> <20080702051337.GX29319@disturbed> <486B13AD.2010500@pmc-sierra.com> <1214979191.6025.22.camel@verge.scott.net.au> <20080702065652.GS14251@build-svl-1.agami.com> <486B6062.6040201@pmc-sierra.com> <486C4F89.9030009@sandeen.net> <486C6053.7010503@pmc-sierra.com> <486CE9EA.90502@sandeen.net> <486DF8F0.5010700@pmc-sierra.com> <20080704122726.GG29319@disturbed> <340C71CD25A7EB49BFA81AE8C839266702997641@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <486E5F4D.1010009@sandeen.net> From: "Sagar Borikar" To: "Eric Sandeen" Cc: "Dave Chinner" , "Nathan Scott" , X-OriginalArrivalTime: 04 Jul 2008 17:51:49.0545 (UTC) FILETIME=[A25C5190:01C8DDFE] X-Barracuda-Connect: bby1mta01.pmc-sierra.com[216.241.235.116] X-Barracuda-Start-Time: 1215193873 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0025 1.0000 -2.0050 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.1, rules version 3.1.55153 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by oss.sgi.com id m64Ho9Tk021007 X-archive-position: 16729 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Sagar_Borikar@pmc-sierra.com Precedence: bulk X-list: xfs Copy is of the same file to 30 different directories and it is basically overwrite. Here is the setup: It's a JBOD with Volume size 20 GB. The directories are empty and this is basically continuous copy of the file on all thirty directories. But surprisingly none of the copy succeeds. All the copy processes are in Uninterruptible sleep state and xfs_repair log I have already attached With the prep. As mentioned it is with 2.6.24 Fedora kernel. Thanks Sagar -----Original Message----- From: Eric Sandeen [mailto:sandeen@sandeen.net] Sent: Friday, July 04, 2008 11:05 PM To: Sagar Borikar Cc: Dave Chinner; Nathan Scott; xfs@oss.sgi.com Subject: Re: Xfs Access to block zero exception and system crash Sagar Borikar wrote: > The script is pretty straight forward: > > While [ 1 ] > Do > Cp -f $1 $2 > Done > > Where I pass the first parameter as the 300+ MB file in one directory > and $2 are is other directory. I run 30 instances of the script in > parallel. Copying the same file to the same directory, or 30 different files to 30 different directories? Or the ame file to 30 different directories? If different directories what is the layout of the target directories? Etc... -Eric From owner-xfs@oss.sgi.com Sat Jul 5 09:24:56 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 05 Jul 2008 09:25:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_31 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m65GOu1V013339 for ; Sat, 5 Jul 2008 09:24:56 -0700 X-ASG-Debug-ID: 1215275159-725300b50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from sandeen.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C2D3DDA7644 for ; Sat, 5 Jul 2008 09:25:59 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id YQt8TxzrH9rj1mHL for ; Sat, 05 Jul 2008 09:25:59 -0700 (PDT) Received: from liberator.sandeen.net (liberator.sandeen.net [10.0.0.4]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by sandeen.net (Postfix) with ESMTP id 25354AC626C; Sat, 5 Jul 2008 11:25:58 -0500 (CDT) Message-ID: <486FA095.1050106@sandeen.net> Date: Sat, 05 Jul 2008 11:25:57 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Sagar Borikar CC: Dave Chinner , Nathan Scott , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Xfs Access to block zero exception and system crash Subject: Re: Xfs Access to block zero exception and system crash References: <486B01A6.4030104@pmc-sierra.com> <20080702051337.GX29319@disturbed> <486B13AD.2010500@pmc-sierra.com> <1214979191.6025.22.camel@verge.scott.net.au> <20080702065652.GS14251@build-svl-1.agami.com> <486B6062.6040201@pmc-sierra.com> <486C4F89.9030009@sandeen.net> <486C6053.7010503@pmc-sierra.com> <486CE9EA.90502@sandeen.net> <486DF8F0.5010700@pmc-sierra.com> <20080704122726.GG29319@disturbed> <340C71CD25A7EB49BFA81AE8C839266702997641@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <486E5F4D.1010009@sandeen.net> <340C71CD25A7EB49BFA81AE8C839266702997658@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> In-Reply-To: <340C71CD25A7EB49BFA81AE8C839266702997658@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: sandeen.net[209.173.210.139] X-Barracuda-Start-Time: 1215275160 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.1, rules version 3.1.55236 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16730 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: sandeen@sandeen.net Precedence: bulk X-list: xfs Sagar Borikar wrote: > Copy is of the same file to 30 different directories and it is basically > overwrite. > > Here is the setup: > > It's a JBOD with Volume size 20 GB. The directories are empty and this > is basically continuous copy of the file on all thirty directories. But > surprisingly none of the copy succeeds. All the copy processes are in > Uninterruptible sleep state and xfs_repair log I have already attached > With the prep. As mentioned it is with 2.6.24 Fedora kernel. It would probably be best to try a 2.6.26 kernel from rawhide to be sure you're closest to the bleeding edge. I tested on 2.6.24.7-92.fc8 on x86_64, and I did this, specifically, in the root of a 30G xfs fs: # for I in `seq 1 30`; do mkdir dir$I; done # vi copyit.sh (your script) # chmod +x copyit.sh # dd if=/dev/zero of=300mbfile bs=1M count=300 # for I in `seq 1 30`; do ./copyit.sh 300mbfile dir$I & done I got no errors or corruption after several iterations. Might also be worth checking dmesg for any errors when you run. -Eric From owner-xfs@oss.sgi.com Sat Jul 5 09:56:02 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 05 Jul 2008 09:56:06 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m65Gu2gC015084 for ; Sat, 5 Jul 2008 09:56:02 -0700 X-ASG-Debug-ID: 1215277025-726101950000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 58FD2DA79E1 for ; Sat, 5 Jul 2008 09:57:05 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id x5kFSFQTByDXjZDp for ; Sat, 05 Jul 2008 09:57:05 -0700 (PDT) Received: by lucidpixels.com (Postfix, from userid 1001) id 24D815A562; Sat, 5 Jul 2008 12:57:04 -0400 (EDT) Date: Sat, 5 Jul 2008 12:57:04 -0400 (EDT) From: Justin Piszcz To: linux-kernel@vger.kernel.org cc: linux-raid@vger.kernel.org, linux-ide@vger.kernel.org, xfs@oss.sgi.com, Alan Piszcz X-ASG-Orig-Subj: Lots of con-current I/O = resets SATA link? (2.6.25.10) Subject: Lots of con-current I/O = resets SATA link? (2.6.25.10) Message-ID: User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1215277026 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.1, rules version 3.1.55238 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16731 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs I've read the best way to 'deal' with this issue is to turn off apic/acpi etc, is there any downside to turning them off? Particularly APIC for IRQ routing? This happens on drives on both the Intel 965 chipset motherboard ports and PCI-e x1 cards, and the cables are not the issue (the cables with 12 other 150 raptors have no issues) (same cables I used with them)). With NCQ on or OFF it occurs. $ ls 0/ 10/ 12/ 14/ 16/ 18/ 2/ 3/ 5/ 7/ 9/ runtest.sh* 1/ 11/ 13/ 15/ 17/ 19/ 20/ 4/ 6/ 8/ linux-2.6.25.10.tar $ cat runtest.sh #!/bin/bash for i in `seq 0 20` do cd $i tar xf ../linux-2.6.25.10.tar & cd .. done With NCQ off (earlier) (from just heavy I/O on the raid5): Jul 5 11:50:06 p34 kernel: [112161.433913] ata6.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen Jul 5 11:50:06 p34 kernel: [112161.433923] ata6.00: cmd b0/d8:00:00:4f:c2/00:00:00:00:00/00 tag 0 Jul 5 11:50:06 p34 kernel: [112161.433924] res 40/00:ff:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Jul 5 11:50:06 p34 kernel: [112161.433927] ata6.00: status: { DRDY } Jul 5 11:50:06 p34 kernel: [112161.736858] ata6: soft resetting link Jul 5 11:50:07 p34 kernel: [112161.889840] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300) Jul 5 11:50:07 p34 kernel: [112161.911418] ata6.00: configured for UDMA/133 Jul 5 11:50:07 p34 kernel: [112161.656792] sd 5:0:0:0: [sdf] Write Protect is off Jul 5 11:50:07 p34 kernel: [112161.656797] sd 5:0:0:0: [sdf] Mode Sense: 00 3a 00 00 Jul 5 11:50:07 p34 kernel: [112161.659296] sd 5:0:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA With NCQ on (with the test shown above): [115786.990237] ata6.00: exception Emask 0x0 SAct 0x3ffff SErr 0x0 action 0x2 frozen [115786.990247] ata6.00: cmd 60/80:00:bf:07:94/00:00:10:00:00/40 tag 0 ncq 65536 in [115786.990249] res 40/00:00:00:00:00/00:00:00:00:00/a0 Emask 0x4 (timeout) [115786.990254] ata6.00: status: { DRDY } [115786.990259] ata6.00: cmd 60/88:08:b7:ee:c1/01:00:1d:00:00/40 tag 1 ncq 200704 in [115786.990261] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [115786.990265] ata6.00: status: { DRDY } [115786.990270] ata6.00: cmd 60/f8:10:bf:eb:c1/02:00:1d:00:00/40 tag 2 ncq 389120 in [115786.990271] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [115786.990275] ata6.00: status: { DRDY } [115786.990280] ata6.00: cmd 60/c0:18:3f:e8:c1/01:00:1d:00:00/40 tag 3 ncq 229376 in [115786.990282] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [115786.990286] ata6.00: status: { DRDY } [115786.990291] ata6.00: cmd 60/c0:20:ff:e9:c1/01:00:1d:00:00/40 tag 4 ncq 229376 in [115786.990293] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [115786.990297] ata6.00: status: { DRDY } [115786.990302] ata6.00: cmd 61/08:28:0f:c6:b6/00:00:1f:00:00/40 tag 5 ncq 4096 out [115786.990303] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [115786.990307] ata6.00: status: { DRDY } [115786.990312] ata6.00: cmd 61/10:30:df:b0:17/00:00:01:00:00/40 tag 6 ncq 8192 out [115786.990313] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [115786.990318] ata6.00: status: { DRDY } [115786.990323] ata6.00: cmd 61/10:38:4f:88:79/00:00:03:00:00/40 tag 7 ncq 8192 out [115786.990324] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [115786.990328] ata6.00: status: { DRDY } [115786.990333] ata6.00: cmd 61/10:40:3f:18:95/00:00:05:00:00/40 tag 8 ncq 8192 out [115786.990335] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [115786.990339] ata6.00: status: { DRDY } [115786.990344] ata6.00: cmd 61/08:48:d7:f6:a9/00:00:06:00:00/40 tag 9 ncq 4096 out [115786.990345] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [115786.990350] ata6.00: status: { DRDY } [115786.990355] ata6.00: cmd 61/08:50:9f:37:b7/00:00:07:00:00/40 tag 10 ncq 4096 out [115786.990356] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [115786.990360] ata6.00: status: { DRDY } [115786.990365] ata6.00: cmd 61/08:58:27:7c:d1/00:00:08:00:00/40 tag 11 ncq 4096 out [115786.990367] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [115786.990371] ata6.00: status: { DRDY } [115786.990376] ata6.00: cmd 61/08:60:97:48:46/00:00:0d:00:00/40 tag 12 ncq 4096 out [115786.990377] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [115786.990381] ata6.00: status: { DRDY } [115786.990386] ata6.00: cmd 61/08:68:cf:b4:68/00:00:0e:00:00/40 tag 13 ncq 4096 out [115786.990388] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [115786.990392] ata6.00: status: { DRDY } [115786.990397] ata6.00: cmd 61/80:70:3f:06:94/01:00:10:00:00/40 tag 14 ncq 196608 out [115786.990398] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [115786.990402] ata6.00: status: { DRDY } [115786.990408] ata6.00: cmd 61/08:78:7f:a4:88/00:00:11:00:00/40 tag 15 ncq 4096 out [115786.990409] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [115786.990413] ata6.00: status: { DRDY } [115786.990418] ata6.00: cmd 61/08:80:37:b8:d5/00:00:13:00:00/40 tag 16 ncq 4096 out [115786.990419] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [115786.990423] ata6.00: status: { DRDY } [115786.990428] ata6.00: cmd 61/08:88:c7:a4:8b/00:00:1d:00:00/40 tag 17 ncq 4096 out [115786.990430] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [115786.990454] ata6.00: status: { DRDY } [115787.293177] ata6: soft resetting link [115787.446158] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [115788.133592] ata6.00: configured for UDMA/133 [115788.133628] ata6: EH complete [115787.877547] sd 5:0:0:0: [sdf] 586072368 512-byte hardware sectors (300069 MB) [115787.877689] sd 5:0:0:0: [sdf] Write Protect is off [115787.877692] sd 5:0:0:0: [sdf] Mode Sense: 00 3a 00 00 [115787.878746] sd 5:0:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA What is the true cause of this, is there anyway to get more information? I will test soon with apic/acpi=off. Justin. From owner-xfs@oss.sgi.com Sat Jul 5 10:19:32 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 05 Jul 2008 10:19:34 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_62, J_CHICKENPOX_64 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m65HJVBI016955 for ; Sat, 5 Jul 2008 10:19:31 -0700 X-ASG-Debug-ID: 1215278431-724f023d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id EF986DAC2AB for ; Sat, 5 Jul 2008 10:20:32 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id nBFcK0dWgfMAMY5T for ; Sat, 05 Jul 2008 10:20:32 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m65HKLNW007284 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 5 Jul 2008 19:20:21 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m65HKLXU007282 for xfs@oss.sgi.com; Sat, 5 Jul 2008 19:20:21 +0200 Date: Sat, 5 Jul 2008 19:20:21 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 2/3] simplify xfs_setattr Subject: Re: [PATCH 2/3] simplify xfs_setattr Message-ID: <20080705172021.GA7177@lst.de> References: <20080627154557.GB31476@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080627154557.GB31476@lst.de> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1215278433 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.1, rules version 3.1.55240 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16732 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Fri, Jun 27, 2008 at 05:45:57PM +0200, Christoph Hellwig wrote: > Now that xfs_setattr is only used for attributes set from ->setattr it > can be switched to take struct iattr directly and thus simplify the > implementation greatly. Also rename the ATTR_ flags to XFS_ATTR_ to > not conflict with the ATTR_ flags used by the VFS. As per discussion with Tim here's a version that doesn't require the generic ACL patch applied before: Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm.c 2008-07-04 14:59:13.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c 2008-07-04 14:59:21.000000000 +0200 @@ -2460,7 +2460,8 @@ xfs_dm_punch_hole( #endif error = xfs_change_file_space(ip, XFS_IOC_UNRESVSP, &bf, - (xfs_off_t)off, sys_cred, ATTR_DMI|ATTR_NOLOCK); + (xfs_off_t)off, sys_cred, + XFS_ATTR_DMI|XFS_ATTR_NOLOCK); /* * if punching to end of file, kill any blocks past EOF that @@ -2663,7 +2664,7 @@ xfs_dm_set_fileattr( dm_fileattr_t __user *statp) { dm_fileattr_t stat; - bhv_vattr_t vat; + struct iattr iattr; int error; /* Returns negative errors to DMAPI */ @@ -2674,52 +2675,52 @@ xfs_dm_set_fileattr( if (copy_from_user( &stat, statp, sizeof(stat))) return(-EFAULT); - vat.va_mask = 0; + iattr.ia_valid = 0; if (mask & DM_AT_MODE) { - vat.va_mask |= XFS_AT_MODE; - vat.va_mode = stat.fa_mode; + iattr.ia_valid |= ATTR_MODE; + iattr.ia_mode = stat.fa_mode; } if (mask & DM_AT_UID) { - vat.va_mask |= XFS_AT_UID; - vat.va_uid = stat.fa_uid; + iattr.ia_valid |= ATTR_UID; + iattr.ia_uid = stat.fa_uid; } if (mask & DM_AT_GID) { - vat.va_mask |= XFS_AT_GID; - vat.va_gid = stat.fa_gid; + iattr.ia_valid |= ATTR_GID; + iattr.ia_gid = stat.fa_gid; } if (mask & DM_AT_ATIME) { - vat.va_mask |= XFS_AT_ATIME; - vat.va_atime.tv_sec = stat.fa_atime; - vat.va_atime.tv_nsec = 0; + iattr.ia_valid |= ATTR_ATIME; + iattr.ia_atime.tv_sec = stat.fa_atime; + iattr.ia_atime.tv_nsec = 0; inode->i_atime.tv_sec = stat.fa_atime; } if (mask & DM_AT_MTIME) { - vat.va_mask |= XFS_AT_MTIME; - vat.va_mtime.tv_sec = stat.fa_mtime; - vat.va_mtime.tv_nsec = 0; + iattr.ia_valid |= ATTR_MTIME; + iattr.ia_mtime.tv_sec = stat.fa_mtime; + iattr.ia_mtime.tv_nsec = 0; } if (mask & DM_AT_CTIME) { - vat.va_mask |= XFS_AT_CTIME; - vat.va_ctime.tv_sec = stat.fa_ctime; - vat.va_ctime.tv_nsec = 0; + iattr.ia_valid |= ATTR_CTIME; + iattr.ia_ctime.tv_sec = stat.fa_ctime; + iattr.ia_ctime.tv_nsec = 0; } - /* DM_AT_DTIME only takes effect if DM_AT_CTIME is not specified. We - overload ctime to also act as dtime, i.e. DM_CONFIG_DTIME_OVERLOAD. - */ - + /* + * DM_AT_DTIME only takes effect if DM_AT_CTIME is not specified. We + * overload ctime to also act as dtime, i.e. DM_CONFIG_DTIME_OVERLOAD. + */ if ((mask & DM_AT_DTIME) && !(mask & DM_AT_CTIME)) { - vat.va_mask |= XFS_AT_CTIME; - vat.va_ctime.tv_sec = stat.fa_dtime; - vat.va_ctime.tv_nsec = 0; + iattr.ia_valid |= ATTR_CTIME; + iattr.ia_ctime.tv_sec = stat.fa_dtime; + iattr.ia_ctime.tv_nsec = 0; } if (mask & DM_AT_SIZE) { - vat.va_mask |= XFS_AT_SIZE; - vat.va_size = stat.fa_size; + iattr.ia_valid |= ATTR_SIZE; + iattr.ia_size = stat.fa_size; } - error = xfs_setattr(XFS_I(inode), &vat, ATTR_DMI, NULL); + error = xfs_setattr(XFS_I(inode), &iattr, XFS_ATTR_DMI, NULL); if (!error) vn_revalidate(vn_from_inode(inode)); /* update Linux inode flags */ return(-error); /* Return negative error to DMAPI */ Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2008-07-04 14:59:11.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2008-07-04 15:03:53.000000000 +0200 @@ -656,54 +656,20 @@ xfs_vn_getattr( STATIC int xfs_vn_setattr( struct dentry *dentry, - struct iattr *attr) + struct iattr *iattr) { struct inode *inode = dentry->d_inode; - unsigned int ia_valid = attr->ia_valid; - bhv_vattr_t vattr = { 0 }; - int flags = 0; int error; - if (ia_valid & ATTR_UID) { - vattr.va_mask |= XFS_AT_UID; - vattr.va_uid = attr->ia_uid; - } - if (ia_valid & ATTR_GID) { - vattr.va_mask |= XFS_AT_GID; - vattr.va_gid = attr->ia_gid; - } - if (ia_valid & ATTR_SIZE) { - vattr.va_mask |= XFS_AT_SIZE; - vattr.va_size = attr->ia_size; - } - if (ia_valid & ATTR_ATIME) { - vattr.va_mask |= XFS_AT_ATIME; - vattr.va_atime = attr->ia_atime; - inode->i_atime = attr->ia_atime; - } - if (ia_valid & ATTR_MTIME) { - vattr.va_mask |= XFS_AT_MTIME; - vattr.va_mtime = attr->ia_mtime; - } - if (ia_valid & ATTR_CTIME) { - vattr.va_mask |= XFS_AT_CTIME; - vattr.va_ctime = attr->ia_ctime; - } - if (ia_valid & ATTR_MODE) { - vattr.va_mask |= XFS_AT_MODE; - vattr.va_mode = attr->ia_mode; + if (iattr->ia_valid & ATTR_ATIME) + inode->i_atime = iattr->ia_atime; + + if (iattr->ia_valid & ATTR_MODE) { if (!in_group_p(inode->i_gid) && !capable(CAP_FSETID)) inode->i_mode &= ~S_ISGID; } - if (ia_valid & (ATTR_MTIME_SET | ATTR_ATIME_SET)) - flags |= ATTR_UTIME; -#ifdef ATTR_NO_BLOCK - if ((ia_valid & ATTR_NO_BLOCK)) - flags |= ATTR_NONBLOCK; -#endif - - error = xfs_setattr(XFS_I(inode), &vattr, flags, NULL); + error = xfs_setattr(XFS_I(inode), iattr, 0, NULL); if (likely(!error)) vn_revalidate(vn_from_inode(inode)); return -error; @@ -747,18 +713,18 @@ xfs_vn_fallocate( xfs_ilock(ip, XFS_IOLOCK_EXCL); error = xfs_change_file_space(ip, XFS_IOC_RESVSP, &bf, - 0, NULL, ATTR_NOLOCK); + 0, NULL, XFS_ATTR_NOLOCK); if (!error && !(mode & FALLOC_FL_KEEP_SIZE) && offset + len > i_size_read(inode)) new_size = offset + len; /* Change file size if needed */ if (new_size) { - bhv_vattr_t va; + struct iattr iattr; - va.va_mask = XFS_AT_SIZE; - va.va_size = new_size; - error = xfs_setattr(ip, &va, ATTR_NOLOCK, NULL); + iattr.ia_valid = ATTR_SIZE; + iattr.ia_size = new_size; + error = xfs_setattr(ip, &iattr, XFS_ATTR_NOLOCK, NULL); } xfs_iunlock(ip, XFS_IOLOCK_EXCL); Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_vnode.h 2008-07-04 14:59:14.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.h 2008-07-04 14:59:21.000000000 +0200 @@ -19,7 +19,6 @@ #define __XFS_VNODE_H__ struct file; -struct bhv_vattr; struct xfs_iomap; struct attrlist_cursor_kern; @@ -66,69 +65,6 @@ static inline struct inode *vn_to_inode( Prevent VM access to the pages until the operation completes. */ -/* - * Vnode attributes. va_mask indicates those attributes the caller - * wants to set or extract. - */ -typedef struct bhv_vattr { - int va_mask; /* bit-mask of attributes present */ - mode_t va_mode; /* file access mode and type */ - xfs_nlink_t va_nlink; /* number of references to file */ - uid_t va_uid; /* owner user id */ - gid_t va_gid; /* owner group id */ - xfs_ino_t va_nodeid; /* file id */ - xfs_off_t va_size; /* file size in bytes */ - u_long va_blocksize; /* blocksize preferred for i/o */ - struct timespec va_atime; /* time of last access */ - struct timespec va_mtime; /* time of last modification */ - struct timespec va_ctime; /* time file changed */ - u_int va_gen; /* generation number of file */ - xfs_dev_t va_rdev; /* device the special file represents */ - __int64_t va_nblocks; /* number of blocks allocated */ - u_long va_xflags; /* random extended file flags */ - u_long va_extsize; /* file extent size */ - u_long va_nextents; /* number of extents in file */ - u_long va_anextents; /* number of attr extents in file */ - prid_t va_projid; /* project id */ -} bhv_vattr_t; - -/* - * setattr or getattr attributes - */ -#define XFS_AT_TYPE 0x00000001 -#define XFS_AT_MODE 0x00000002 -#define XFS_AT_UID 0x00000004 -#define XFS_AT_GID 0x00000008 -#define XFS_AT_FSID 0x00000010 -#define XFS_AT_NODEID 0x00000020 -#define XFS_AT_NLINK 0x00000040 -#define XFS_AT_SIZE 0x00000080 -#define XFS_AT_ATIME 0x00000100 -#define XFS_AT_MTIME 0x00000200 -#define XFS_AT_CTIME 0x00000400 -#define XFS_AT_RDEV 0x00000800 -#define XFS_AT_BLKSIZE 0x00001000 -#define XFS_AT_NBLOCKS 0x00002000 -#define XFS_AT_VCODE 0x00004000 -#define XFS_AT_MAC 0x00008000 -#define XFS_AT_UPDATIME 0x00010000 -#define XFS_AT_UPDMTIME 0x00020000 -#define XFS_AT_UPDCTIME 0x00040000 -#define XFS_AT_ACL 0x00080000 -#define XFS_AT_CAP 0x00100000 -#define XFS_AT_INF 0x00200000 -#define XFS_AT_NEXTENTS 0x01000000 -#define XFS_AT_ANEXTENTS 0x02000000 -#define XFS_AT_SIZE_NOPERM 0x08000000 -#define XFS_AT_GENCOUNT 0x10000000 - -#define XFS_AT_TIMES (XFS_AT_ATIME|XFS_AT_MTIME|XFS_AT_CTIME) - -#define XFS_AT_UPDTIMES (XFS_AT_UPDATIME|XFS_AT_UPDMTIME|XFS_AT_UPDCTIME) - -#define XFS_AT_NOSET (XFS_AT_NLINK|XFS_AT_RDEV|XFS_AT_FSID|XFS_AT_NODEID|\ - XFS_AT_TYPE|XFS_AT_BLKSIZE|XFS_AT_NBLOCKS|XFS_AT_VCODE|\ - XFS_AT_NEXTENTS|XFS_AT_ANEXTENTS|XFS_AT_GENCOUNT) extern void vn_init(void); extern int vn_revalidate(bhv_vnode_t *); @@ -204,15 +140,6 @@ static inline void vn_atime_to_time_t(bh #define VN_DIRTY(vp) mapping_tagged(vn_to_inode(vp)->i_mapping, \ PAGECACHE_TAG_DIRTY) -/* - * Flags to vop_setattr/getattr. - */ -#define ATTR_UTIME 0x01 /* non-default utime(2) request */ -#define ATTR_DMI 0x08 /* invocation from a DMI function */ -#define ATTR_LAZY 0x80 /* set/get attributes lazily */ -#define ATTR_NONBLOCK 0x100 /* return EAGAIN if operation would block */ -#define ATTR_NOLOCK 0x200 /* Don't grab any conflicting locks */ -#define ATTR_NOSIZETOK 0x400 /* Don't get the SIZE token */ /* * Tracking vnode activity. Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.c 2008-07-04 14:59:14.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.c 2008-07-04 14:59:21.000000000 +0200 @@ -75,19 +75,16 @@ xfs_open( return 0; } -/* - * xfs_setattr - */ int xfs_setattr( - xfs_inode_t *ip, - bhv_vattr_t *vap, + struct xfs_inode *ip, + struct iattr *iattr, int flags, cred_t *credp) { xfs_mount_t *mp = ip->i_mount; + int mask = iattr->ia_valid; xfs_trans_t *tp; - int mask; int code; uint lock_flags; uint commit_flags=0; @@ -103,30 +100,9 @@ xfs_setattr( if (mp->m_flags & XFS_MOUNT_RDONLY) return XFS_ERROR(EROFS); - /* - * Cannot set certain attributes. - */ - mask = vap->va_mask; - if (mask & XFS_AT_NOSET) { - return XFS_ERROR(EINVAL); - } - if (XFS_FORCED_SHUTDOWN(mp)) return XFS_ERROR(EIO); - /* - * Timestamps do not need to be logged and hence do not - * need to be done within a transaction. - */ - if (mask & XFS_AT_UPDTIMES) { - ASSERT((mask & ~XFS_AT_UPDTIMES) == 0); - timeflags = ((mask & XFS_AT_UPDATIME) ? XFS_ICHGTIME_ACC : 0) | - ((mask & XFS_AT_UPDCTIME) ? XFS_ICHGTIME_CHG : 0) | - ((mask & XFS_AT_UPDMTIME) ? XFS_ICHGTIME_MOD : 0); - xfs_ichgtime(ip, timeflags); - return 0; - } - olddquot1 = olddquot2 = NULL; udqp = gdqp = NULL; @@ -138,17 +114,17 @@ xfs_setattr( * If the IDs do change before we take the ilock, we're covered * because the i_*dquot fields will get updated anyway. */ - if (XFS_IS_QUOTA_ON(mp) && (mask & (XFS_AT_UID|XFS_AT_GID))) { + if (XFS_IS_QUOTA_ON(mp) && (mask & (ATTR_UID|ATTR_GID))) { uint qflags = 0; - if ((mask & XFS_AT_UID) && XFS_IS_UQUOTA_ON(mp)) { - uid = vap->va_uid; + if ((mask & ATTR_UID) && XFS_IS_UQUOTA_ON(mp)) { + uid = iattr->ia_uid; qflags |= XFS_QMOPT_UQUOTA; } else { uid = ip->i_d.di_uid; } - if ((mask & XFS_AT_GID) && XFS_IS_GQUOTA_ON(mp)) { - gid = vap->va_gid; + if ((mask & ATTR_GID) && XFS_IS_GQUOTA_ON(mp)) { + gid = iattr->ia_gid; qflags |= XFS_QMOPT_GQUOTA; } else { gid = ip->i_d.di_gid; @@ -173,10 +149,10 @@ xfs_setattr( */ tp = NULL; lock_flags = XFS_ILOCK_EXCL; - if (flags & ATTR_NOLOCK) + if (flags & XFS_ATTR_NOLOCK) need_iolock = 0; - if (!(mask & XFS_AT_SIZE)) { - if ((mask != (XFS_AT_CTIME|XFS_AT_ATIME|XFS_AT_MTIME)) || + if (!(mask & ATTR_SIZE)) { + if ((mask != (ATTR_CTIME|ATTR_ATIME|ATTR_MTIME)) || (mp->m_flags & XFS_MOUNT_WSYNC)) { tp = xfs_trans_alloc(mp, XFS_TRANS_SETATTR_NOT_SIZE); commit_flags = 0; @@ -189,10 +165,10 @@ xfs_setattr( } } else { if (DM_EVENT_ENABLED(ip, DM_EVENT_TRUNCATE) && - !(flags & ATTR_DMI)) { + !(flags & XFS_ATTR_DMI)) { int dmflags = AT_DELAY_FLAG(flags) | DM_SEM_FLAG_WR; code = XFS_SEND_DATA(mp, DM_EVENT_TRUNCATE, ip, - vap->va_size, 0, dmflags, NULL); + iattr->ia_size, 0, dmflags, NULL); if (code) { lock_flags = 0; goto error_return; @@ -212,7 +188,7 @@ xfs_setattr( * Only the owner or users with CAP_FOWNER * capability may do these things. */ - if (mask & (XFS_AT_MODE|XFS_AT_UID|XFS_AT_GID)) { + if (mask & (ATTR_MODE|ATTR_UID|ATTR_GID)) { /* * CAP_FOWNER overrides the following restrictions: * @@ -236,21 +212,21 @@ xfs_setattr( * IDs of the calling process shall match the group owner of * the file when setting the set-group-ID bit on that file */ - if (mask & XFS_AT_MODE) { + if (mask & ATTR_MODE) { mode_t m = 0; - if ((vap->va_mode & S_ISUID) && !file_owner) + if ((iattr->ia_mode & S_ISUID) && !file_owner) m |= S_ISUID; - if ((vap->va_mode & S_ISGID) && + if ((iattr->ia_mode & S_ISGID) && !in_group_p((gid_t)ip->i_d.di_gid)) m |= S_ISGID; #if 0 /* Linux allows this, Irix doesn't. */ - if ((vap->va_mode & S_ISVTX) && !S_ISDIR(ip->i_d.di_mode)) + if ((iattr->ia_mode & S_ISVTX) && !S_ISDIR(ip->i_d.di_mode)) m |= S_ISVTX; #endif if (m && !capable(CAP_FSETID)) - vap->va_mode &= ~m; + iattr->ia_mode &= ~m; } } @@ -261,7 +237,7 @@ xfs_setattr( * and can change the group id only to a group of which he * or she is a member. */ - if (mask & (XFS_AT_UID|XFS_AT_GID)) { + if (mask & (ATTR_UID|ATTR_GID)) { /* * These IDs could have changed since we last looked at them. * But, we're assured that if the ownership did change @@ -270,8 +246,8 @@ xfs_setattr( */ iuid = ip->i_d.di_uid; igid = ip->i_d.di_gid; - gid = (mask & XFS_AT_GID) ? vap->va_gid : igid; - uid = (mask & XFS_AT_UID) ? vap->va_uid : iuid; + gid = (mask & ATTR_GID) ? iattr->ia_gid : igid; + uid = (mask & ATTR_UID) ? iattr->ia_uid : iuid; /* * CAP_CHOWN overrides the following restrictions: @@ -308,13 +284,13 @@ xfs_setattr( /* * Truncate file. Must have write permission and not be a directory. */ - if (mask & XFS_AT_SIZE) { + if (mask & ATTR_SIZE) { /* Short circuit the truncate case for zero length files */ - if ((vap->va_size == 0) && - (ip->i_size == 0) && (ip->i_d.di_nextents == 0)) { + if (iattr->ia_size == 0 && + ip->i_size == 0 && ip->i_d.di_nextents == 0) { xfs_iunlock(ip, XFS_ILOCK_EXCL); lock_flags &= ~XFS_ILOCK_EXCL; - if (mask & XFS_AT_CTIME) + if (mask & ATTR_CTIME) xfs_ichgtime(ip, XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG); code = 0; goto error_return; @@ -337,9 +313,9 @@ xfs_setattr( /* * Change file access or modified times. */ - if (mask & (XFS_AT_ATIME|XFS_AT_MTIME)) { + if (mask & (ATTR_ATIME|ATTR_MTIME)) { if (!file_owner) { - if ((flags & ATTR_UTIME) && + if ((mask & (ATTR_MTIME_SET|ATTR_ATIME_SET)) && !capable(CAP_FOWNER)) { code = XFS_ERROR(EPERM); goto error_return; @@ -349,23 +325,22 @@ xfs_setattr( /* * Now we can make the changes. Before we join the inode - * to the transaction, if XFS_AT_SIZE is set then take care of + * to the transaction, if ATTR_SIZE is set then take care of * the part of the truncation that must be done without the * inode lock. This needs to be done before joining the inode * to the transaction, because the inode cannot be unlocked * once it is a part of the transaction. */ - if (mask & XFS_AT_SIZE) { + if (mask & ATTR_SIZE) { code = 0; - if ((vap->va_size > ip->i_size) && - (flags & ATTR_NOSIZETOK) == 0) { + if (iattr->ia_size > ip->i_size) { /* * Do the first part of growing a file: zero any data * in the last block that is beyond the old EOF. We * need to do this before the inode is joined to the * transaction to modify the i_size. */ - code = xfs_zero_eof(ip, vap->va_size, ip->i_size); + code = xfs_zero_eof(ip, iattr->ia_size, ip->i_size); } xfs_iunlock(ip, XFS_ILOCK_EXCL); @@ -382,10 +357,10 @@ xfs_setattr( * not within the range we care about here. */ if (!code && - (ip->i_size != ip->i_d.di_size) && - (vap->va_size > ip->i_d.di_size)) { + ip->i_size != ip->i_d.di_size && + iattr->ia_size > ip->i_d.di_size) { code = xfs_flush_pages(ip, - ip->i_d.di_size, vap->va_size, + ip->i_d.di_size, iattr->ia_size, XFS_B_ASYNC, FI_NONE); } @@ -393,7 +368,7 @@ xfs_setattr( vn_iowait(ip); if (!code) - code = xfs_itruncate_data(ip, vap->va_size); + code = xfs_itruncate_data(ip, iattr->ia_size); if (code) { ASSERT(tp == NULL); lock_flags &= ~XFS_ILOCK_EXCL; @@ -422,31 +397,30 @@ xfs_setattr( /* * Truncate file. Must have write permission and not be a directory. */ - if (mask & XFS_AT_SIZE) { + if (mask & ATTR_SIZE) { /* * Only change the c/mtime if we are changing the size * or we are explicitly asked to change it. This handles * the semantic difference between truncate() and ftruncate() * as implemented in the VFS. */ - if (vap->va_size != ip->i_size || (mask & XFS_AT_CTIME)) + if (iattr->ia_size != ip->i_size || (mask & ATTR_CTIME)) timeflags |= XFS_ICHGTIME_MOD | XFS_ICHGTIME_CHG; - if (vap->va_size > ip->i_size) { - ip->i_d.di_size = vap->va_size; - ip->i_size = vap->va_size; - if (!(flags & ATTR_DMI)) + if (iattr->ia_size > ip->i_size) { + ip->i_d.di_size = iattr->ia_size; + ip->i_size = iattr->ia_size; + if (!(flags & XFS_ATTR_DMI)) xfs_ichgtime(ip, XFS_ICHGTIME_CHG); xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); - } else if ((vap->va_size <= ip->i_size) || - ((vap->va_size == 0) && ip->i_d.di_nextents)) { + } else if (iattr->ia_size <= ip->i_size || + (iattr->ia_size == 0 && ip->i_d.di_nextents)) { /* * signal a sync transaction unless * we're truncating an already unlinked * file on a wsync filesystem */ - code = xfs_itruncate_finish(&tp, ip, - (xfs_fsize_t)vap->va_size, + code = xfs_itruncate_finish(&tp, ip, iattr->ia_size, XFS_DATA_FORK, ((ip->i_d.di_nlink != 0 || !(mp->m_flags & XFS_MOUNT_WSYNC)) @@ -468,9 +442,9 @@ xfs_setattr( /* * Change file access modes. */ - if (mask & XFS_AT_MODE) { + if (mask & ATTR_MODE) { ip->i_d.di_mode &= S_IFMT; - ip->i_d.di_mode |= vap->va_mode & ~S_IFMT; + ip->i_d.di_mode |= iattr->ia_mode & ~S_IFMT; xfs_trans_log_inode (tp, ip, XFS_ILOG_CORE); timeflags |= XFS_ICHGTIME_CHG; @@ -483,7 +457,7 @@ xfs_setattr( * and can change the group id only to a group of which he * or she is a member. */ - if (mask & (XFS_AT_UID|XFS_AT_GID)) { + if (mask & (ATTR_UID|ATTR_GID)) { /* * CAP_FSETID overrides the following restrictions: * @@ -501,7 +475,7 @@ xfs_setattr( */ if (iuid != uid) { if (XFS_IS_UQUOTA_ON(mp)) { - ASSERT(mask & XFS_AT_UID); + ASSERT(mask & ATTR_UID); ASSERT(udqp); olddquot1 = XFS_QM_DQVOPCHOWN(mp, tp, ip, &ip->i_udquot, udqp); @@ -511,7 +485,7 @@ xfs_setattr( if (igid != gid) { if (XFS_IS_GQUOTA_ON(mp)) { ASSERT(!XFS_IS_PQUOTA_ON(mp)); - ASSERT(mask & XFS_AT_GID); + ASSERT(mask & ATTR_GID); ASSERT(gdqp); olddquot2 = XFS_QM_DQVOPCHOWN(mp, tp, ip, &ip->i_gdquot, gdqp); @@ -527,31 +501,31 @@ xfs_setattr( /* * Change file access or modified times. */ - if (mask & (XFS_AT_ATIME|XFS_AT_MTIME)) { - if (mask & XFS_AT_ATIME) { - ip->i_d.di_atime.t_sec = vap->va_atime.tv_sec; - ip->i_d.di_atime.t_nsec = vap->va_atime.tv_nsec; + if (mask & (ATTR_ATIME|ATTR_MTIME)) { + if (mask & ATTR_ATIME) { + ip->i_d.di_atime.t_sec = iattr->ia_atime.tv_sec; + ip->i_d.di_atime.t_nsec = iattr->ia_atime.tv_nsec; ip->i_update_core = 1; timeflags &= ~XFS_ICHGTIME_ACC; } - if (mask & XFS_AT_MTIME) { - ip->i_d.di_mtime.t_sec = vap->va_mtime.tv_sec; - ip->i_d.di_mtime.t_nsec = vap->va_mtime.tv_nsec; + if (mask & ATTR_MTIME) { + ip->i_d.di_mtime.t_sec = iattr->ia_mtime.tv_sec; + ip->i_d.di_mtime.t_nsec = iattr->ia_mtime.tv_nsec; timeflags &= ~XFS_ICHGTIME_MOD; timeflags |= XFS_ICHGTIME_CHG; } - if (tp && (flags & ATTR_UTIME)) + if (tp && (mask & (ATTR_MTIME_SET|ATTR_ATIME_SET))) xfs_trans_log_inode (tp, ip, XFS_ILOG_CORE); } /* - * Change file inode change time only if XFS_AT_CTIME set + * Change file inode change time only if ATTR_CTIME set * AND we have been called by a DMI function. */ - if ( (flags & ATTR_DMI) && (mask & XFS_AT_CTIME) ) { - ip->i_d.di_ctime.t_sec = vap->va_ctime.tv_sec; - ip->i_d.di_ctime.t_nsec = vap->va_ctime.tv_nsec; + if ((flags & XFS_ATTR_DMI) && (mask & ATTR_CTIME)) { + ip->i_d.di_ctime.t_sec = iattr->ia_ctime.tv_sec; + ip->i_d.di_ctime.t_nsec = iattr->ia_ctime.tv_nsec; ip->i_update_core = 1; timeflags &= ~XFS_ICHGTIME_CHG; } @@ -560,7 +534,7 @@ xfs_setattr( * Send out timestamp changes that need to be set to the * current time. Not done when called by a DMI function. */ - if (timeflags && !(flags & ATTR_DMI)) + if (timeflags && !(flags & XFS_ATTR_DMI)) xfs_ichgtime(ip, timeflags); XFS_STATS_INC(xs_ig_attrchg); @@ -598,7 +572,7 @@ xfs_setattr( } if (DM_EVENT_ENABLED(ip, DM_EVENT_ATTRIBUTE) && - !(flags & ATTR_DMI)) { + !(flags & XFS_ATTR_DMI)) { (void) XFS_SEND_NAMESP(mp, DM_EVENT_ATTRIBUTE, ip, DM_RIGHT_NULL, NULL, DM_RIGHT_NULL, NULL, NULL, 0, 0, AT_DELAY_FLAG(flags)); @@ -3033,7 +3007,7 @@ xfs_alloc_file_space( /* Generate a DMAPI event if needed. */ if (alloc_type != 0 && offset < ip->i_size && - (attr_flags&ATTR_DMI) == 0 && + (attr_flags & XFS_ATTR_DMI) == 0 && DM_EVENT_ENABLED(ip, DM_EVENT_WRITE)) { xfs_off_t end_dmi_offset; @@ -3147,7 +3121,7 @@ retry: allocatesize_fsb -= allocated_fsb; } dmapi_enospc_check: - if (error == ENOSPC && (attr_flags & ATTR_DMI) == 0 && + if (error == ENOSPC && (attr_flags & XFS_ATTR_DMI) == 0 && DM_EVENT_ENABLED(ip, DM_EVENT_NOSPACE)) { error = XFS_SEND_NAMESP(mp, DM_EVENT_NOSPACE, ip, DM_RIGHT_NULL, @@ -3294,7 +3268,7 @@ xfs_free_file_space( end_dmi_offset = offset + len; endoffset_fsb = XFS_B_TO_FSBT(mp, end_dmi_offset); - if (offset < ip->i_size && (attr_flags & ATTR_DMI) == 0 && + if (offset < ip->i_size && (attr_flags & XFS_ATTR_DMI) == 0 && DM_EVENT_ENABLED(ip, DM_EVENT_WRITE)) { if (end_dmi_offset > ip->i_size) end_dmi_offset = ip->i_size; @@ -3305,7 +3279,7 @@ xfs_free_file_space( return error; } - if (attr_flags & ATTR_NOLOCK) + if (attr_flags & XFS_ATTR_NOLOCK) need_iolock = 0; if (need_iolock) { xfs_ilock(ip, XFS_IOLOCK_EXCL); @@ -3482,7 +3456,7 @@ xfs_change_file_space( xfs_off_t startoffset; xfs_off_t llen; xfs_trans_t *tp; - bhv_vattr_t va; + struct iattr iattr; xfs_itrace_entry(ip); @@ -3556,10 +3530,10 @@ xfs_change_file_space( break; } - va.va_mask = XFS_AT_SIZE; - va.va_size = startoffset; + iattr.ia_valid = ATTR_SIZE; + iattr.ia_size = startoffset; - error = xfs_setattr(ip, &va, attr_flags, credp); + error = xfs_setattr(ip, &iattr, attr_flags, credp); if (error) return error; @@ -3589,7 +3563,7 @@ xfs_change_file_space( xfs_trans_ijoin(tp, ip, XFS_ILOCK_EXCL); xfs_trans_ihold(tp, ip); - if ((attr_flags & ATTR_DMI) == 0) { + if ((attr_flags & XFS_ATTR_DMI) == 0) { ip->i_d.di_mode &= ~S_ISUID; /* Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.h 2008-07-04 14:58:36.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.h 2008-07-04 14:59:21.000000000 +0200 @@ -2,9 +2,9 @@ #define _XFS_VNODEOPS_H 1 struct attrlist_cursor_kern; -struct bhv_vattr; struct cred; struct file; +struct iattr; struct inode; struct iovec; struct kiocb; @@ -15,8 +15,12 @@ struct xfs_iomap; int xfs_open(struct xfs_inode *ip); -int xfs_setattr(struct xfs_inode *ip, struct bhv_vattr *vap, int flags, +int xfs_setattr(struct xfs_inode *ip, struct iattr *vap, int flags, struct cred *credp); +#define XFS_ATTR_DMI 0x01 /* invocation from a DMI function */ +#define XFS_ATTR_NONBLOCK 0x02 /* return EAGAIN if operation would block */ +#define XFS_ATTR_NOLOCK 0x04 /* Don't grab any conflicting locks */ + int xfs_readlink(struct xfs_inode *ip, char *link); int xfs_fsync(struct xfs_inode *ip); int xfs_release(struct xfs_inode *ip); Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ioctl.c 2008-07-04 14:59:14.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c 2008-07-04 14:59:21.000000000 +0200 @@ -685,9 +685,9 @@ xfs_ioc_space( return -XFS_ERROR(EFAULT); if (filp->f_flags & (O_NDELAY|O_NONBLOCK)) - attr_flags |= ATTR_NONBLOCK; + attr_flags |= XFS_ATTR_NONBLOCK; if (ioflags & IO_INVIS) - attr_flags |= ATTR_DMI; + attr_flags |= XFS_ATTR_DMI; error = xfs_change_file_space(ip, cmd, &bf, filp->f_pos, NULL, attr_flags); Index: linux-2.6-xfs/fs/xfs/xfs_dmapi.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_dmapi.h 2008-07-04 14:58:36.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_dmapi.h 2008-07-04 14:59:21.000000000 +0200 @@ -166,6 +166,6 @@ typedef enum { #define FILP_DELAY_FLAG(filp) ((filp->f_flags&(O_NDELAY|O_NONBLOCK)) ? \ DM_FLAGS_NDELAY : 0) -#define AT_DELAY_FLAG(f) ((f&ATTR_NONBLOCK) ? DM_FLAGS_NDELAY : 0) +#define AT_DELAY_FLAG(f) ((f & XFS_ATTR_NONBLOCK) ? DM_FLAGS_NDELAY : 0) #endif /* __XFS_DMAPI_H__ */ Index: linux-2.6-xfs/fs/xfs/xfs_acl.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_acl.c 2008-07-04 15:01:44.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_acl.c 2008-07-04 15:02:47.000000000 +0200 @@ -720,7 +720,7 @@ xfs_acl_setmode( xfs_acl_t *acl, int *basicperms) { - bhv_vattr_t va; + struct iattr iattr; xfs_acl_entry_t *ap; xfs_acl_entry_t *gap = NULL; int i, nomask = 1; @@ -734,25 +734,25 @@ xfs_acl_setmode( * Copy the u::, g::, o::, and m:: bits from the ACL into the * mode. The m:: bits take precedence over the g:: bits. */ - va.va_mask = XFS_AT_MODE; - va.va_mode = xfs_vtoi(vp)->i_d.di_mode; - va.va_mode &= ~(S_IRWXU|S_IRWXG|S_IRWXO); + iattr.ia_mask = XFS_AT_MODE; + iattr.ia_mode = xfs_vtoi(vp)->i_d.di_mode; + iattr.ia_mode &= ~(S_IRWXU|S_IRWXG|S_IRWXO); ap = acl->acl_entry; for (i = 0; i < acl->acl_cnt; ++i) { switch (ap->ae_tag) { case ACL_USER_OBJ: - va.va_mode |= ap->ae_perm << 6; + iattr.ia_mode |= ap->ae_perm << 6; break; case ACL_GROUP_OBJ: gap = ap; break; case ACL_MASK: /* more than just standard modes */ nomask = 0; - va.va_mode |= ap->ae_perm << 3; + iattr.ia_mode |= ap->ae_perm << 3; *basicperms = 0; break; case ACL_OTHER: - va.va_mode |= ap->ae_perm; + iattr.ia_mode |= ap->ae_perm; break; default: /* more than just standard modes */ *basicperms = 0; @@ -763,9 +763,9 @@ xfs_acl_setmode( /* Set the group bits from ACL_GROUP_OBJ if there's no ACL_MASK */ if (gap && nomask) - va.va_mode |= gap->ae_perm << 3; + iattr.ia_mode |= gap->ae_perm << 3; - return xfs_setattr(xfs_vtoi(vp), &va, 0, sys_cred); + return xfs_setattr(xfs_vtoi(vp), &iattr, 0, sys_cred); } /* From owner-xfs@oss.sgi.com Sat Jul 5 10:20:17 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 05 Jul 2008 10:20:20 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m65HKHuR017276 for ; Sat, 5 Jul 2008 10:20:17 -0700 X-ASG-Debug-ID: 1215278479-726902310000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from verein.lst.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 1713CDAC2B3 for ; Sat, 5 Jul 2008 10:21:19 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id VcEeXkIFL2WqAEYS for ; Sat, 05 Jul 2008 10:21:19 -0700 (PDT) Received: from verein.lst.de (localhost [127.0.0.1]) by verein.lst.de (8.12.3/8.12.3/Debian-7.1) with ESMTP id m65HLANW007316 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Sat, 5 Jul 2008 19:21:10 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m65HLAg0007314 for xfs@oss.sgi.com; Sat, 5 Jul 2008 19:21:10 +0200 Date: Sat, 5 Jul 2008 19:21:10 +0200 From: Christoph Hellwig To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 3/3] kill vn_revalidate Subject: Re: [PATCH 3/3] kill vn_revalidate Message-ID: <20080705172110.GB7177@lst.de> References: <20080627154602.GC31476@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080627154602.GC31476@lst.de> User-Agent: Mutt/1.3.28i X-Scanned-By: MIMEDefang 2.39 X-Barracuda-Connect: verein.lst.de[213.95.11.210] X-Barracuda-Start-Time: 1215278481 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_MJ615 X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.55240 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.20 BSF_SC0_MJ615 Custom Rule MJ615 X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16733 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hch@lst.de Precedence: bulk X-list: xfs On Fri, Jun 27, 2008 at 05:46:02PM +0200, Christoph Hellwig wrote: > These days most of the attributes in struct inode are properly kept in > sync by XFS. This patch removes the need for vn_revalidate completely > by: > > - keeping inode.i_flags uptodate after any flags are updated in > xfs_ioctl_setattr > - keeping i_mode, i_uid and i_gid uptodate in xfs_setattr Version that doesn't require the generic ACL patch below: Signed-off-by: Christoph Hellwig Index: linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/dmapi/xfs_dm.c 2008-07-05 10:04:56.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/dmapi/xfs_dm.c 2008-07-05 12:02:24.000000000 +0200 @@ -2665,7 +2665,6 @@ xfs_dm_set_fileattr( { dm_fileattr_t stat; struct iattr iattr; - int error; /* Returns negative errors to DMAPI */ @@ -2720,10 +2719,7 @@ xfs_dm_set_fileattr( iattr.ia_size = stat.fa_size; } - error = xfs_setattr(XFS_I(inode), &iattr, XFS_ATTR_DMI, NULL); - if (!error) - vn_revalidate(vn_from_inode(inode)); /* update Linux inode flags */ - return(-error); /* Return negative error to DMAPI */ + return -xfs_setattr(XFS_I(inode), &iattr, XFS_ATTR_DMI, NULL); } Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ioctl.c 2008-07-05 10:04:56.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c 2008-07-05 12:02:24.000000000 +0200 @@ -920,6 +920,30 @@ xfs_set_diflags( ip->i_d.di_flags = di_flags; } +STATIC void +xfs_diflags_to_linux( + struct xfs_inode *ip) +{ + struct inode *inode = XFS_ITOV(ip); + unsigned int xflags = xfs_ip2xflags(ip); + + if (xflags & XFS_XFLAG_IMMUTABLE) + inode->i_flags |= S_IMMUTABLE; + else + inode->i_flags &= ~S_IMMUTABLE; + if (xflags & XFS_XFLAG_APPEND) + inode->i_flags |= S_APPEND; + else + inode->i_flags &= ~S_APPEND; + if (xflags & XFS_XFLAG_SYNC) + inode->i_flags |= S_SYNC; + else + inode->i_flags &= ~S_SYNC; + if (xflags & XFS_XFLAG_NOATIME) + inode->i_flags |= S_NOATIME; + else + inode->i_flags &= ~S_NOATIME; +} #define FSX_PROJID 1 #define FSX_EXTSIZE 2 @@ -1118,8 +1142,10 @@ xfs_ioctl_setattr( if (mask & FSX_EXTSIZE) ip->i_d.di_extsize = fa->fsx_extsize >> mp->m_sb.sb_blocklog; - if (mask & FSX_XFLAGS) + if (mask & FSX_XFLAGS) { xfs_set_diflags(ip, fa->fsx_xflags); + xfs_diflags_to_linux(ip); + } xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); xfs_ichgtime(ip, XFS_ICHGTIME_CHG); @@ -1157,7 +1183,6 @@ xfs_ioctl_setattr( (mask & FSX_NONBLOCK) ? DM_FLAGS_NDELAY : 0); } - vn_revalidate(XFS_ITOV(ip)); /* update flags */ return 0; error_return: Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_iops.c 2008-07-05 10:04:56.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_iops.c 2008-07-05 12:02:24.000000000 +0200 @@ -658,21 +658,7 @@ xfs_vn_setattr( struct dentry *dentry, struct iattr *iattr) { - struct inode *inode = dentry->d_inode; - int error; - - if (iattr->ia_valid & ATTR_ATIME) - inode->i_atime = iattr->ia_atime; - - if (iattr->ia_valid & ATTR_MODE) { - if (!in_group_p(inode->i_gid) && !capable(CAP_FSETID)) - inode->i_mode &= ~S_ISGID; - } - - error = xfs_setattr(XFS_I(inode), iattr, 0, NULL); - if (likely(!error)) - vn_revalidate(vn_from_inode(inode)); - return -error; + return -xfs_setattr(XFS_I(dentry->d_inode), iattr, 0, NULL); } /* Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_ksyms.c 2008-07-05 10:04:17.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ksyms.c 2008-07-05 12:02:24.000000000 +0200 @@ -177,7 +177,6 @@ EXPORT_SYMBOL(uuid_hash64); EXPORT_SYMBOL(uuid_is_nil); EXPORT_SYMBOL(uuid_table_remove); EXPORT_SYMBOL(vn_hold); -EXPORT_SYMBOL(vn_revalidate); #if defined(CONFIG_XFS_POSIX_ACL) EXPORT_SYMBOL(xfs_acl_vtoacl); Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_vnode.c 2008-07-05 10:02:09.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.c 2008-07-05 10:04:57.000000000 +0200 @@ -82,56 +82,6 @@ vn_ioerror( xfs_do_force_shutdown(ip->i_mount, SHUTDOWN_DEVICE_REQ, f, l); } -/* - * Revalidate the Linux inode from the XFS inode. - * Note: i_size _not_ updated; we must hold the inode - * semaphore when doing that - callers responsibility. - */ -int -vn_revalidate( - bhv_vnode_t *vp) -{ - struct inode *inode = vn_to_inode(vp); - struct xfs_inode *ip = XFS_I(inode); - struct xfs_mount *mp = ip->i_mount; - unsigned long xflags; - - xfs_itrace_entry(ip); - - if (XFS_FORCED_SHUTDOWN(mp)) - return -EIO; - - xfs_ilock(ip, XFS_ILOCK_SHARED); - inode->i_mode = ip->i_d.di_mode; - inode->i_uid = ip->i_d.di_uid; - inode->i_gid = ip->i_d.di_gid; - inode->i_mtime.tv_sec = ip->i_d.di_mtime.t_sec; - inode->i_mtime.tv_nsec = ip->i_d.di_mtime.t_nsec; - inode->i_ctime.tv_sec = ip->i_d.di_ctime.t_sec; - inode->i_ctime.tv_nsec = ip->i_d.di_ctime.t_nsec; - - xflags = xfs_ip2xflags(ip); - if (xflags & XFS_XFLAG_IMMUTABLE) - inode->i_flags |= S_IMMUTABLE; - else - inode->i_flags &= ~S_IMMUTABLE; - if (xflags & XFS_XFLAG_APPEND) - inode->i_flags |= S_APPEND; - else - inode->i_flags &= ~S_APPEND; - if (xflags & XFS_XFLAG_SYNC) - inode->i_flags |= S_SYNC; - else - inode->i_flags &= ~S_SYNC; - if (xflags & XFS_XFLAG_NOATIME) - inode->i_flags |= S_NOATIME; - else - inode->i_flags &= ~S_NOATIME; - xfs_iunlock(ip, XFS_ILOCK_SHARED); - - xfs_iflags_clear(ip, XFS_IMODIFIED); - return 0; -} /* * Add a reference to a referenced vnode. Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_vnode.h 2008-07-05 10:04:56.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.h 2008-07-05 10:04:57.000000000 +0200 @@ -67,7 +67,6 @@ static inline struct inode *vn_to_inode( extern void vn_init(void); -extern int vn_revalidate(bhv_vnode_t *); /* * Yeah, these don't take vnode anymore at all, all this should be Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.c 2008-07-05 10:04:56.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.c 2008-07-05 10:04:57.000000000 +0200 @@ -83,6 +83,7 @@ xfs_setattr( cred_t *credp) { xfs_mount_t *mp = ip->i_mount; + struct inode *inode = XFS_ITOV(ip); int mask = iattr->ia_valid; xfs_trans_t *tp; int code; @@ -446,6 +447,9 @@ xfs_setattr( ip->i_d.di_mode &= S_IFMT; ip->i_d.di_mode |= iattr->ia_mode & ~S_IFMT; + inode->i_mode &= S_IFMT; + inode->i_mode |= iattr->ia_mode & ~S_IFMT; + xfs_trans_log_inode (tp, ip, XFS_ILOG_CORE); timeflags |= XFS_ICHGTIME_CHG; } @@ -481,6 +485,7 @@ xfs_setattr( &ip->i_udquot, udqp); } ip->i_d.di_uid = uid; + inode->i_uid = uid; } if (igid != gid) { if (XFS_IS_GQUOTA_ON(mp)) { @@ -491,6 +496,7 @@ xfs_setattr( &ip->i_gdquot, gdqp); } ip->i_d.di_gid = gid; + inode->i_gid = gid; } xfs_trans_log_inode (tp, ip, XFS_ILOG_CORE); @@ -503,12 +509,14 @@ xfs_setattr( */ if (mask & (ATTR_ATIME|ATTR_MTIME)) { if (mask & ATTR_ATIME) { + inode->i_atime = iattr->ia_atime; ip->i_d.di_atime.t_sec = iattr->ia_atime.tv_sec; ip->i_d.di_atime.t_nsec = iattr->ia_atime.tv_nsec; ip->i_update_core = 1; timeflags &= ~XFS_ICHGTIME_ACC; } if (mask & ATTR_MTIME) { + inode->i_mtime = iattr->ia_mtime; ip->i_d.di_mtime.t_sec = iattr->ia_mtime.tv_sec; ip->i_d.di_mtime.t_nsec = iattr->ia_mtime.tv_nsec; timeflags &= ~XFS_ICHGTIME_MOD; @@ -524,6 +532,7 @@ xfs_setattr( */ if ((flags & XFS_ATTR_DMI) && (mask & ATTR_CTIME)) { + inode->i_ctime = iattr->ia_ctime; ip->i_d.di_ctime.t_sec = iattr->ia_ctime.tv_sec; ip->i_d.di_ctime.t_nsec = iattr->ia_ctime.tv_nsec; ip->i_update_core = 1; Index: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_xattr.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_xattr.c 2008-07-05 10:02:09.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_xattr.c 2008-07-05 12:02:24.000000000 +0200 @@ -64,7 +64,7 @@ static int xfs_xattr_system_set(struct inode *inode, const char *name, const void *value, size_t size, int flags) { - int error, acl; + int acl; acl = xfs_decode_acl(name); if (acl < 0) @@ -75,10 +75,7 @@ xfs_xattr_system_set(struct inode *inode if (!value) return xfs_acl_vremove(inode, acl); - error = xfs_acl_vset(inode, (void *)value, size, acl); - if (!error) - vn_revalidate(inode); - return error; + return xfs_acl_vset(inode, (void *)value, size, acl); } static struct xattr_handler xfs_xattr_system_handler = { Index: linux-2.6-xfs/fs/xfs/xfs_acl.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_acl.c 2008-07-05 12:26:45.000000000 +0200 +++ linux-2.6-xfs/fs/xfs/xfs_acl.c 2008-07-05 12:26:53.000000000 +0200 @@ -734,7 +734,7 @@ xfs_acl_setmode( * Copy the u::, g::, o::, and m:: bits from the ACL into the * mode. The m:: bits take precedence over the g:: bits. */ - iattr.ia_mask = XFS_AT_MODE; + iattr.ia_valid = ATTR_MODE; iattr.ia_mode = xfs_vtoi(vp)->i_d.di_mode; iattr.ia_mode &= ~(S_IRWXU|S_IRWXG|S_IRWXO); ap = acl->acl_entry; From owner-xfs@oss.sgi.com Sat Jul 5 10:34:22 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 05 Jul 2008 10:34:25 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m65HYLX5018716 for ; Sat, 5 Jul 2008 10:34:22 -0700 X-ASG-Debug-ID: 1215279324-724d02750000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wr-out-0506.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3BF3ADAC575 for ; Sat, 5 Jul 2008 10:35:24 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.227]) by cuda.sgi.com with ESMTP id P6Y6Zvep63oPt4FL for ; Sat, 05 Jul 2008 10:35:24 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id 57so1130389wri.12 for ; Sat, 05 Jul 2008 10:35:24 -0700 (PDT) Received: by 10.90.96.1 with SMTP id t1mr2888993agb.105.1215279324170; Sat, 05 Jul 2008 10:35:24 -0700 (PDT) Received: by 10.90.102.9 with HTTP; Sat, 5 Jul 2008 10:35:24 -0700 (PDT) Message-ID: Date: Sat, 5 Jul 2008 12:35:24 -0500 From: "Jon Nelson" To: "Justin Piszcz" X-ASG-Orig-Subj: Re: Lots of con-current I/O = resets SATA link? (2.6.25.10) Subject: Re: Lots of con-current I/O = resets SATA link? (2.6.25.10) Cc: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, linux-ide@vger.kernel.org, xfs@oss.sgi.com, "Alan Piszcz" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Barracuda-Connect: wr-out-0506.google.com[64.233.184.227] X-Barracuda-Start-Time: 1215279325 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.1, rules version 3.1.55240 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16734 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jnelson@jamponi.net Precedence: bulk X-list: xfs Try booting with: nolapic That largely fixed my problems on my motherboard (2.6.18+, EPoX MF-570SLI). I hope to try 2.6.25+ soon. -- Jon From owner-xfs@oss.sgi.com Sat Jul 5 10:34:37 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 05 Jul 2008 10:34:39 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m65HYbi2018770 for ; Sat, 5 Jul 2008 10:34:37 -0700 X-ASG-Debug-ID: 1215279324-724d02750001-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from wr-out-0506.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D575F12DCA02 for ; Sat, 5 Jul 2008 10:35:41 -0700 (PDT) Received: from wr-out-0506.google.com (wr-out-0506.google.com [64.233.184.227]) by cuda.sgi.com with ESMTP id jUp8tCEPaaxI5R37 for ; Sat, 05 Jul 2008 10:35:41 -0700 (PDT) Received: by wr-out-0506.google.com with SMTP id 57so1130389wri.12 for ; Sat, 05 Jul 2008 10:35:41 -0700 (PDT) Received: by 10.90.119.20 with SMTP id r20mr2931010agc.10.1215279341343; Sat, 05 Jul 2008 10:35:41 -0700 (PDT) Received: by 10.90.102.9 with HTTP; Sat, 5 Jul 2008 10:35:41 -0700 (PDT) Message-ID: Date: Sat, 5 Jul 2008 12:35:41 -0500 From: "Jon Nelson" To: "Justin Piszcz" X-ASG-Orig-Subj: Re: Lots of con-current I/O = resets SATA link? (2.6.25.10) Subject: Re: Lots of con-current I/O = resets SATA link? (2.6.25.10) Cc: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, linux-ide@vger.kernel.org, xfs@oss.sgi.com, "Alan Piszcz" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: X-Google-Sender-Auth: 90cacceae9125cc1 X-Barracuda-Connect: wr-out-0506.google.com[64.233.184.227] X-Barracuda-Start-Time: 1215279341 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.1, rules version 3.1.55240 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16735 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jnelson-linux-raid@jamponi.net Precedence: bulk X-list: xfs Try booting with: nolapic That largely fixed my problems on my motherboard (2.6.18+, EPoX MF-570SLI). I hope to try 2.6.25+ soon. -- Jon From owner-xfs@oss.sgi.com Sat Jul 5 11:37:42 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 05 Jul 2008 11:37:47 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m65IbgEH023424 for ; Sat, 5 Jul 2008 11:37:42 -0700 X-ASG-Debug-ID: 1215283123-6368011c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pd2mo3so.prod.shaw.ca (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 677DADACA10 for ; Sat, 5 Jul 2008 11:38:43 -0700 (PDT) Received: from pd2mo3so.prod.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by cuda.sgi.com with ESMTP id qSQy0ZrLE25xCIcy for ; Sat, 05 Jul 2008 11:38:43 -0700 (PDT) Received: from pd3mr2so.prod.shaw.ca (pd3mr2so-qfe3.prod.shaw.ca [10.0.141.178]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0K3J00JW8QGJGW10@l-daemon> for xfs@oss.sgi.com; Sat, 05 Jul 2008 12:38:43 -0600 (MDT) Received: from pn2ml7so.prod.shaw.ca ([10.0.121.151]) by pd3mr2so.prod.shaw.ca (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0K3J00BIFQGHVL60@pd3mr2so.prod.shaw.ca> for xfs@oss.sgi.com; Sat, 05 Jul 2008 12:38:43 -0600 (MDT) Received: from [192.168.1.113] ([70.64.130.4]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0K3J00BM5QGG4630@l-daemon> for xfs@oss.sgi.com; Sat, 05 Jul 2008 12:38:41 -0600 (MDT) Date: Sat, 05 Jul 2008 12:38:35 -0600 From: Robert Hancock X-ASG-Orig-Subj: Re: Lots of con-current I/O = resets SATA link? (2.6.25.10) Subject: Re: Lots of con-current I/O = resets SATA link? (2.6.25.10) In-reply-to: To: Justin Piszcz Cc: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, linux-ide@vger.kernel.org, xfs@oss.sgi.com, Alan Piszcz Message-id: <486FBFAB.5050303@shaw.ca> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7bit References: User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) X-Barracuda-Connect: idcmail-mo1so.shaw.ca[24.71.223.10] X-Barracuda-Start-Time: 1215283125 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.1, rules version 3.1.55240 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16736 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hancockr@shaw.ca Precedence: bulk X-list: xfs Justin Piszcz wrote: > I've read the best way to 'deal' with this issue is to turn off > apic/acpi etc, is there any downside to turning them off? Particularly > APIC for IRQ routing? It's not the best way to deal with it, more just a workaround, and if it does help it should be reported because it indicates something else is wrong. The main downsides to disabling APIC is that all interrupts will be handled by one core and you'll end up with much more IRQ sharing. Disabling ACPI on modern systems tends to be a bad idea, you'll get no multi-core support, for one. > > This happens on drives on both the Intel 965 chipset motherboard ports > and PCI-e x1 cards, and the cables are not the issue (the cables with 12 > other 150 raptors have no issues) (same cables I used with them)). > > With NCQ on or OFF it occurs. > > $ ls > 0/ 10/ 12/ 14/ 16/ 18/ 2/ 3/ 5/ 7/ 9/ runtest.sh* > 1/ 11/ 13/ 15/ 17/ 19/ 20/ 4/ 6/ 8/ linux-2.6.25.10.tar > > $ cat runtest.sh > #!/bin/bash > > for i in `seq 0 20` > do > cd $i > tar xf ../linux-2.6.25.10.tar & > cd .. > done > > With NCQ off (earlier) (from just heavy I/O on the raid5): > Jul 5 11:50:06 p34 kernel: [112161.433913] ata6.00: exception Emask 0x0 > SAct > 0x0 SErr 0x0 action 0x2 frozen > Jul 5 11:50:06 p34 kernel: [112161.433923] ata6.00: cmd > b0/d8:00:00:4f:c2/00:00:00:00:00/00 tag 0 > Jul 5 11:50:06 p34 kernel: [112161.433924] res > 40/00:ff:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) > Jul 5 11:50:06 p34 kernel: [112161.433927] ata6.00: status: { DRDY } > Jul 5 11:50:06 p34 kernel: [112161.736858] ata6: soft resetting link > Jul 5 11:50:07 p34 kernel: [112161.889840] ata6: SATA link up 3.0 Gbps > (SStatus > 123 SControl 300) > Jul 5 11:50:07 p34 kernel: [112161.911418] ata6.00: configured for > UDMA/133 > Jul 5 11:50:07 p34 kernel: [112161.656792] sd 5:0:0:0: [sdf] Write > Protect is > off > Jul 5 11:50:07 p34 kernel: [112161.656797] sd 5:0:0:0: [sdf] Mode > Sense: 00 3a > 00 00 > Jul 5 11:50:07 p34 kernel: [112161.659296] sd 5:0:0:0: [sdf] Write cache: > enabled, read cache: enabled, doesn't support DPO or FUA > > With NCQ on (with the test shown above): > [115786.990237] ata6.00: exception Emask 0x0 SAct 0x3ffff SErr 0x0 > action 0x2 frozen > [115786.990247] ata6.00: cmd 60/80:00:bf:07:94/00:00:10:00:00/40 tag 0 > ncq 65536 in > [115786.990249] res 40/00:00:00:00:00/00:00:00:00:00/a0 Emask > 0x4 (timeout) > [115786.990254] ata6.00: status: { DRDY } > [115786.990259] ata6.00: cmd 60/88:08:b7:ee:c1/01:00:1d:00:00/40 tag 1 > ncq 200704 in > [115786.990261] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask > 0x4 (timeout) > [115786.990265] ata6.00: status: { DRDY } > [115786.990270] ata6.00: cmd 60/f8:10:bf:eb:c1/02:00:1d:00:00/40 tag 2 > ncq 389120 in > [115786.990271] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask > 0x4 (timeout) > [115786.990275] ata6.00: status: { DRDY } > [115786.990280] ata6.00: cmd 60/c0:18:3f:e8:c1/01:00:1d:00:00/40 tag 3 > ncq 229376 in > [115786.990282] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask > 0x4 (timeout) > [115786.990286] ata6.00: status: { DRDY } > [115786.990291] ata6.00: cmd 60/c0:20:ff:e9:c1/01:00:1d:00:00/40 tag 4 > ncq 229376 in > [115786.990293] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask > 0x4 (timeout) > [115786.990297] ata6.00: status: { DRDY } > [115786.990302] ata6.00: cmd 61/08:28:0f:c6:b6/00:00:1f:00:00/40 tag 5 > ncq 4096 out > [115786.990303] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask > 0x4 (timeout) > [115786.990307] ata6.00: status: { DRDY } > [115786.990312] ata6.00: cmd 61/10:30:df:b0:17/00:00:01:00:00/40 tag 6 > ncq 8192 out > [115786.990313] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask > 0x4 (timeout) > [115786.990318] ata6.00: status: { DRDY } > [115786.990323] ata6.00: cmd 61/10:38:4f:88:79/00:00:03:00:00/40 tag 7 > ncq 8192 out > [115786.990324] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask > 0x4 (timeout) > [115786.990328] ata6.00: status: { DRDY } > [115786.990333] ata6.00: cmd 61/10:40:3f:18:95/00:00:05:00:00/40 tag 8 > ncq 8192 out > [115786.990335] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask > 0x4 (timeout) > [115786.990339] ata6.00: status: { DRDY } > [115786.990344] ata6.00: cmd 61/08:48:d7:f6:a9/00:00:06:00:00/40 tag 9 > ncq 4096 out > [115786.990345] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask > 0x4 (timeout) > [115786.990350] ata6.00: status: { DRDY } > [115786.990355] ata6.00: cmd 61/08:50:9f:37:b7/00:00:07:00:00/40 tag 10 > ncq 4096 out > [115786.990356] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask > 0x4 (timeout) > [115786.990360] ata6.00: status: { DRDY } > [115786.990365] ata6.00: cmd 61/08:58:27:7c:d1/00:00:08:00:00/40 tag 11 > ncq 4096 out > [115786.990367] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask > 0x4 (timeout) > [115786.990371] ata6.00: status: { DRDY } > [115786.990376] ata6.00: cmd 61/08:60:97:48:46/00:00:0d:00:00/40 tag 12 > ncq 4096 out > [115786.990377] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask > 0x4 (timeout) > [115786.990381] ata6.00: status: { DRDY } > [115786.990386] ata6.00: cmd 61/08:68:cf:b4:68/00:00:0e:00:00/40 tag 13 > ncq 4096 out > [115786.990388] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask > 0x4 (timeout) > [115786.990392] ata6.00: status: { DRDY } > [115786.990397] ata6.00: cmd 61/80:70:3f:06:94/01:00:10:00:00/40 tag 14 > ncq 196608 out > [115786.990398] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask > 0x4 (timeout) > [115786.990402] ata6.00: status: { DRDY } > [115786.990408] ata6.00: cmd 61/08:78:7f:a4:88/00:00:11:00:00/40 tag 15 > ncq 4096 out > [115786.990409] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask > 0x4 (timeout) > [115786.990413] ata6.00: status: { DRDY } > [115786.990418] ata6.00: cmd 61/08:80:37:b8:d5/00:00:13:00:00/40 tag 16 > ncq 4096 out > [115786.990419] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask > 0x4 (timeout) > [115786.990423] ata6.00: status: { DRDY } > [115786.990428] ata6.00: cmd 61/08:88:c7:a4:8b/00:00:1d:00:00/40 tag 17 > ncq 4096 out > [115786.990430] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask > 0x4 (timeout) > [115786.990454] ata6.00: status: { DRDY } > [115787.293177] ata6: soft resetting link > [115787.446158] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > [115788.133592] ata6.00: configured for UDMA/133 > [115788.133628] ata6: EH complete > [115787.877547] sd 5:0:0:0: [sdf] 586072368 512-byte hardware sectors > (300069 MB) > [115787.877689] sd 5:0:0:0: [sdf] Write Protect is off > [115787.877692] sd 5:0:0:0: [sdf] Mode Sense: 00 3a 00 00 > [115787.878746] sd 5:0:0:0: [sdf] Write cache: enabled, read cache: > enabled, doesn't support DPO or FUA > > What is the true cause of this, is there anyway to get more information? > > I will test soon with apic/acpi=off. Can you post your dmesg from bootup with the controller/drive detection? From owner-xfs@oss.sgi.com Sat Jul 5 12:27:35 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 05 Jul 2008 12:27:44 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_16, J_CHICKENPOX_33,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m65JRYuE031188 for ; Sat, 5 Jul 2008 12:27:34 -0700 X-ASG-Debug-ID: 1215286114-029a027e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 236161878321 for ; Sat, 5 Jul 2008 12:28:34 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id JHKEBWJ8ZodB5L63 for ; Sat, 05 Jul 2008 12:28:34 -0700 (PDT) Received: by lucidpixels.com (Postfix, from userid 1001) id 1A0225A563; Sat, 5 Jul 2008 15:28:34 -0400 (EDT) Date: Sat, 5 Jul 2008 15:28:34 -0400 (EDT) From: Justin Piszcz To: Robert Hancock cc: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, linux-ide@vger.kernel.org, xfs@oss.sgi.com, Alan Piszcz X-ASG-Orig-Subj: Re: Lots of con-current I/O = resets SATA link? (2.6.25.10) Subject: Re: Lots of con-current I/O = resets SATA link? (2.6.25.10) In-Reply-To: <486FBFAB.5050303@shaw.ca> Message-ID: References: <486FBFAB.5050303@shaw.ca> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1215286115 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.1, rules version 3.1.55238 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.50 BSF_RULE7568M Custom Rule 7568M X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16737 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Sat, 5 Jul 2008, Robert Hancock wrote: > Justin Piszcz wrote: >> I've read the best way to 'deal' with this issue is to turn off apic/acpi >> etc, is there any downside to turning them off? Particularly APIC for IRQ >> routing? > > It's not the best way to deal with it, more just a workaround, and if it does > help it should be reported because it indicates something else is wrong. The > main downsides to disabling APIC is that all interrupts will be handled by > one core and you'll end up with much more IRQ sharing. Disabling ACPI on > modern systems tends to be a bad idea, you'll get no multi-core support, for > one. > >> [115787.446158] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300) >> [115788.133592] ata6.00: configured for UDMA/133 >> [115788.133628] ata6: EH complete >> [115787.877547] sd 5:0:0:0: [sdf] 586072368 512-byte hardware sectors >> (300069 MB) >> [115787.877689] sd 5:0:0:0: [sdf] Write Protect is off >> [115787.877692] sd 5:0:0:0: [sdf] Mode Sense: 00 3a 00 00 >> [115787.878746] sd 5:0:0:0: [sdf] Write cache: enabled, read cache: >> enabled, doesn't support DPO or FUA >> >> What is the true cause of this, is there anyway to get more information? >> >> I will test soon with apic/acpi=off. > > Can you post your dmesg from bootup with the controller/drive detection? Below: [ 0.000000] Linux version 2.6.25.10 (root@p34.internal.lan) (gcc version 4.3.1 (Debian 4.3.1-2) ) #1 SMP Thu Jul 3 04:57:42 EDT 2008 [ 0.000000] Command line: auto BOOT_IMAGE=2.6.25.10-1 ro root=902 [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000008f000 (usable) [ 0.000000] BIOS-e820: 000000000008f000 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000cf58f000 (usable) [ 0.000000] BIOS-e820: 00000000cf58f000 - 00000000cf59c000 (reserved) [ 0.000000] BIOS-e820: 00000000cf59c000 - 00000000cf639000 (usable) [ 0.000000] BIOS-e820: 00000000cf639000 - 00000000cf694000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000cf694000 - 00000000cf697000 (ACPI data) [ 0.000000] BIOS-e820: 00000000cf697000 - 00000000cf6ef000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000cf6ef000 - 00000000cf6f1000 (ACPI data) [ 0.000000] BIOS-e820: 00000000cf6f1000 - 00000000cf6f2000 (usable) [ 0.000000] BIOS-e820: 00000000cf6f2000 - 00000000cf6ff000 (ACPI data) [ 0.000000] BIOS-e820: 00000000cf6ff000 - 00000000cf700000 (usable) [ 0.000000] BIOS-e820: 00000000cf700000 - 00000000d0000000 (reserved) [ 0.000000] BIOS-e820: 00000000f0000000 - 00000000f8000000 (reserved) [ 0.000000] BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 000000022c000000 (usable) [ 0.000000] Entering add_active_range(0, 0, 143) 0 entries of 256 used [ 0.000000] Entering add_active_range(0, 256, 849295) 1 entries of 256 used [ 0.000000] Entering add_active_range(0, 849308, 849465) 2 entries of 256 used [ 0.000000] Entering add_active_range(0, 849649, 849650) 3 entries of 256 used [ 0.000000] Entering add_active_range(0, 849663, 849664) 4 entries of 256 used [ 0.000000] Entering add_active_range(0, 1048576, 2277376) 5 entries of 256 used [ 0.000000] end_pfn_map = 2277376 [ 0.000000] DMI 2.4 present. [ 0.000000] ACPI: RSDP 000FE020, 0014 (r0 INTEL ) [ 0.000000] ACPI: RSDT CF6FD038, 0050 (r1 INTEL DG965WH 6CA 1000013) [ 0.000000] ACPI: FACP CF6FC000, 0074 (r1 INTEL DG965WH 6CA MSFT 1000013) [ 0.000000] ACPI: DSDT CF6F7000, 442C (r1 INTEL DG965WH 6CA MSFT 1000013) [ 0.000000] ACPI: FACS CF697000, 0040 [ 0.000000] ACPI: APIC CF6F6000, 0078 (r1 INTEL DG965WH 6CA MSFT 1000013) [ 0.000000] ACPI: WDDT CF6F5000, 0040 (r1 INTEL DG965WH 6CA MSFT 1000013) [ 0.000000] ACPI: MCFG CF6F4000, 003C (r1 INTEL DG965WH 6CA MSFT 1000013) [ 0.000000] ACPI: ASF! CF6F3000, 00A6 (r32 INTEL DG965WH 6CA MSFT 1000013) [ 0.000000] ACPI: HPET CF6F2000, 0038 (r1 INTEL DG965WH 6CA MSFT 1000013) [ 0.000000] ACPI: SSDT CF6F0000, 020C (r1 INTEL CpuPm 6CA MSFT 1000013) [ 0.000000] ACPI: SSDT CF6EF000, 0175 (r1 INTEL Cpu0Ist 6CA MSFT 1000013) [ 0.000000] ACPI: SSDT CF696000, 0175 (r1 INTEL Cpu1Ist 6CA MSFT 1000013) [ 0.000000] ACPI: SSDT CF695000, 0175 (r1 INTEL Cpu2Ist 6CA MSFT 1000013) [ 0.000000] ACPI: SSDT CF694000, 0175 (r1 INTEL Cpu3Ist 6CA MSFT 1000013) [ 0.000000] Entering add_active_range(0, 0, 143) 0 entries of 256 used [ 0.000000] Entering add_active_range(0, 256, 849295) 1 entries of 256 used [ 0.000000] Entering add_active_range(0, 849308, 849465) 2 entries of 256 used [ 0.000000] Entering add_active_range(0, 849649, 849650) 3 entries of 256 used [ 0.000000] Entering add_active_range(0, 849663, 849664) 4 entries of 256 used [ 0.000000] Entering add_active_range(0, 1048576, 2277376) 5 entries of 256 used [ 0.000000] early res: 0 [0-fff] BIOS data page [ 0.000000] early res: 1 [6000-7fff] SMP_TRAMPOLINE [ 0.000000] early res: 2 [200000-7c93a7] TEXT DATA BSS [ 0.000000] early res: 3 [9a400-a03ff] EBDA [ 0.000000] early res: 4 [8000-11fff] PGTABLE [ 0.000000] [ffffe20000000000-ffffe200001fffff] PMD ->ffff810001200000 on node 0 [ 0.000000] [ffffe20000200000-ffffe200003fffff] PMD ->ffff810001600000 on node 0 [ 0.000000] [ffffe20000400000-ffffe200005fffff] PMD ->ffff810001a00000 on node 0 [ 0.000000] [ffffe20000600000-ffffe200007fffff] PMD ->ffff810001e00000 on node 0 [ 0.000000] [ffffe20000800000-ffffe200009fffff] PMD ->ffff810002200000 on node 0 [ 0.000000] [ffffe20000a00000-ffffe20000bfffff] PMD ->ffff810002600000 on node 0 [ 0.000000] [ffffe20000c00000-ffffe20000dfffff] PMD ->ffff810002a00000 on node 0 [ 0.000000] [ffffe20000e00000-ffffe20000ffffff] PMD ->ffff810002e00000 on node 0 [ 0.000000] [ffffe20001000000-ffffe200011fffff] PMD ->ffff810003200000 on node 0 [ 0.000000] [ffffe20001200000-ffffe200013fffff] PMD ->ffff810003600000 on node 0 [ 0.000000] [ffffe20001400000-ffffe200015fffff] PMD ->ffff810003a00000 on node 0 [ 0.000000] [ffffe20001600000-ffffe200017fffff] PMD ->ffff810003e00000 on node 0 [ 0.000000] [ffffe20001800000-ffffe200019fffff] PMD ->ffff810004200000 on node 0 [ 0.000000] [ffffe20001a00000-ffffe20001bfffff] PMD ->ffff810004600000 on node 0 [ 0.000000] [ffffe20001c00000-ffffe20001dfffff] PMD ->ffff810004a00000 on node 0 [ 0.000000] [ffffe20001e00000-ffffe20001ffffff] PMD ->ffff810004e00000 on node 0 [ 0.000000] [ffffe20002000000-ffffe200021fffff] PMD ->ffff810005200000 on node 0 [ 0.000000] [ffffe20002200000-ffffe200023fffff] PMD ->ffff810005600000 on node 0 [ 0.000000] [ffffe20002400000-ffffe200025fffff] PMD ->ffff810005a00000 on node 0 [ 0.000000] [ffffe20002600000-ffffe200027fffff] PMD ->ffff810005e00000 on node 0 [ 0.000000] [ffffe20002800000-ffffe200029fffff] PMD ->ffff810006200000 on node 0 [ 0.000000] [ffffe20002a00000-ffffe20002bfffff] PMD ->ffff810006600000 on node 0 [ 0.000000] [ffffe20002c00000-ffffe20002dfffff] PMD ->ffff810006a00000 on node 0 [ 0.000000] [ffffe20002e00000-ffffe20002ffffff] PMD ->ffff810006e00000 on node 0 [ 0.000000] [ffffe20003000000-ffffe200031fffff] PMD ->ffff810007200000 on node 0 [ 0.000000] [ffffe20003200000-ffffe200033fffff] PMD ->ffff810007600000 on node 0 [ 0.000000] [ffffe20003400000-ffffe200035fffff] PMD ->ffff810007a00000 on node 0 [ 0.000000] [ffffe20003600000-ffffe200037fffff] PMD ->ffff810007e00000 on node 0 [ 0.000000] [ffffe20003800000-ffffe200039fffff] PMD ->ffff810008200000 on node 0 [ 0.000000] [ffffe20003a00000-ffffe20003bfffff] PMD ->ffff810008600000 on node 0 [ 0.000000] [ffffe20003c00000-ffffe20003dfffff] PMD ->ffff810008a00000 on node 0 [ 0.000000] [ffffe20003e00000-ffffe20003ffffff] PMD ->ffff810008e00000 on node 0 [ 0.000000] [ffffe20004000000-ffffe200041fffff] PMD ->ffff810009200000 on node 0 [ 0.000000] [ffffe20004200000-ffffe200043fffff] PMD ->ffff810009600000 on node 0 [ 0.000000] [ffffe20004400000-ffffe200045fffff] PMD ->ffff810009a00000 on node 0 [ 0.000000] [ffffe20004600000-ffffe200047fffff] PMD ->ffff810009e00000 on node 0 [ 0.000000] [ffffe20004800000-ffffe200049fffff] PMD ->ffff81000a200000 on node 0 [ 0.000000] [ffffe20004a00000-ffffe20004bfffff] PMD ->ffff81000a600000 on node 0 [ 0.000000] [ffffe20004c00000-ffffe20004dfffff] PMD ->ffff81000aa00000 on node 0 [ 0.000000] [ffffe20004e00000-ffffe20004ffffff] PMD ->ffff81000ae00000 on node 0 [ 0.000000] [ffffe20005000000-ffffe200051fffff] PMD ->ffff81000b200000 on node 0 [ 0.000000] [ffffe20005200000-ffffe200053fffff] PMD ->ffff81000b600000 on node 0 [ 0.000000] [ffffe20005400000-ffffe200055fffff] PMD ->ffff81000ba00000 on node 0 [ 0.000000] [ffffe20005600000-ffffe200057fffff] PMD ->ffff81000be00000 on node 0 [ 0.000000] [ffffe20005800000-ffffe200059fffff] PMD ->ffff81000c200000 on node 0 [ 0.000000] [ffffe20005a00000-ffffe20005bfffff] PMD ->ffff81000c600000 on node 0 [ 0.000000] [ffffe20005c00000-ffffe20005dfffff] PMD ->ffff81000ca00000 on node 0 [ 0.000000] [ffffe20005e00000-ffffe20005ffffff] PMD ->ffff81000ce00000 on node 0 [ 0.000000] [ffffe20006000000-ffffe200061fffff] PMD ->ffff81000d200000 on node 0 [ 0.000000] [ffffe20006200000-ffffe200063fffff] PMD ->ffff81000d600000 on node 0 [ 0.000000] [ffffe20006400000-ffffe200065fffff] PMD ->ffff81000da00000 on node 0 [ 0.000000] [ffffe20006600000-ffffe200067fffff] PMD ->ffff81000de00000 on node 0 [ 0.000000] [ffffe20006800000-ffffe200069fffff] PMD ->ffff81000e200000 on node 0 [ 0.000000] [ffffe20006a00000-ffffe20006bfffff] PMD ->ffff81000e600000 on node 0 [ 0.000000] [ffffe20006c00000-ffffe20006dfffff] PMD ->ffff81000ea00000 on node 0 [ 0.000000] [ffffe20006e00000-ffffe20006ffffff] PMD ->ffff81000ee00000 on node 0 [ 0.000000] [ffffe20007000000-ffffe200071fffff] PMD ->ffff81000f200000 on node 0 [ 0.000000] [ffffe20007200000-ffffe200073fffff] PMD ->ffff81000f600000 on node 0 [ 0.000000] [ffffe20007400000-ffffe200075fffff] PMD ->ffff81000fa00000 on node 0 [ 0.000000] [ffffe20007600000-ffffe200077fffff] PMD ->ffff81000fe00000 on node 0 [ 0.000000] [ffffe20007800000-ffffe200079fffff] PMD ->ffff810010200000 on node 0 [ 0.000000] [ffffe20007a00000-ffffe20007bfffff] PMD ->ffff810010600000 on node 0 [ 0.000000] Zone PFN ranges: [ 0.000000] DMA 0 -> 4096 [ 0.000000] DMA32 4096 -> 1048576 [ 0.000000] Normal 1048576 -> 2277376 [ 0.000000] Movable zone start PFN for each node [ 0.000000] early_node_map[6] active PFN ranges [ 0.000000] 0: 0 -> 143 [ 0.000000] 0: 256 -> 849295 [ 0.000000] 0: 849308 -> 849465 [ 0.000000] 0: 849649 -> 849650 [ 0.000000] 0: 849663 -> 849664 [ 0.000000] 0: 1048576 -> 2277376 [ 0.000000] On node 0 totalpages: 2078141 [ 0.000000] DMA zone: 56 pages used for memmap [ 0.000000] DMA zone: 1502 pages reserved [ 0.000000] DMA zone: 2425 pages, LIFO batch:0 [ 0.000000] DMA32 zone: 14280 pages used for memmap [ 0.000000] DMA32 zone: 831078 pages, LIFO batch:31 [ 0.000000] Normal zone: 16800 pages used for memmap [ 0.000000] Normal zone: 1212000 pages, LIFO batch:31 [ 0.000000] Movable zone: 0 pages used for memmap [ 0.000000] ACPI: PM-Timer IO Port: 0x408 [ 0.000000] ACPI: Local APIC address 0xfee00000 [ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) [ 0.000000] Processor #0 (Bootup-CPU) [ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) [ 0.000000] Processor #2 [ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) [ 0.000000] Processor #1 [ 0.000000] ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) [ 0.000000] Processor #3 [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1]) [ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1]) [ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) [ 0.000000] IOAPIC[0]: apic_id 2, address 0xfec00000, GSI 0-23 [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [ 0.000000] ACPI: IRQ0 used by override. [ 0.000000] ACPI: IRQ2 used by override. [ 0.000000] ACPI: IRQ9 used by override. [ 0.000000] Setting APIC routing to flat [ 0.000000] ACPI: HPET id: 0x8086a201 base: 0xfed00000 [ 0.000000] Using ACPI (MADT) for SMP configuration information [ 0.000000] Allocating PCI resources starting at d2000000 (gap: d0000000:20000000) [ 0.000000] PERCPU: Allocating 21960 bytes of per cpu data [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 2045503 [ 0.000000] Kernel command line: auto BOOT_IMAGE=2.6.25.10-1 ro root=902 [ 0.000000] Initializing CPU#0 [ 0.000000] PID hash table entries: 4096 (order: 12, 32768 bytes) [ 0.000000] TSC calibrated against PM_TIMER [ 0.000001] time.c: Detected 2397.601 MHz processor. [ 0.000017] Console: colour dummy device 80x25 [ 0.000020] console [tty0] enabled [ 0.000999] Dentry cache hash table entries: 1048576 (order: 11, 8388608 bytes) [ 0.000999] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes) [ 0.000999] Checking aperture... [ 0.000999] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) [ 0.000999] Placing software IO TLB between 0x11433000 - 0x15433000 [ 0.000999] Memory: 8100044k/9109504k available (3999k kernel code, 211796k reserved, 1251k data, 256k init) [ 0.000999] CPA: page pool initialized 1 of 1 pages preallocated [ 0.000999] hpet clockevent registered [ 0.059992] Calibrating delay using timer specific routine.. 4797.82 BogoMIPS (lpj=2398913) [ 0.060037] Mount-cache hash table entries: 256 [ 0.060140] CPU: L1 I cache: 32K, L1 D cache: 32K [ 0.060143] CPU: L2 cache: 4096K [ 0.060146] CPU: Physical Processor ID: 0 [ 0.060148] CPU: Processor Core ID: 0 [ 0.060155] CPU0: Thermal monitoring enabled (TM2) [ 0.060157] using mwait in idle threads. [ 0.060165] Freeing SMP alternatives: 35k freed [ 0.060183] ACPI: Core revision 20070126 [ 0.077084] Using local APIC timer interrupts. [ 0.077989] APIC timer calibration result 16649993 [ 0.077990] Detected 16.649 MHz APIC timer. [ 0.078079] Booting processor 1/4 APIC 0x2 [ 0.000999] Initializing CPU#1 [ 0.000999] Calibrating delay using timer specific routine.. 4794.99 BogoMIPS (lpj=2397499) [ 0.000999] CPU: L1 I cache: 32K, L1 D cache: 32K [ 0.000999] CPU: L2 cache: 4096K [ 0.000999] CPU: Physical Processor ID: 0 [ 0.000999] CPU: Processor Core ID: 2 [ 0.000999] CPU1: Thermal monitoring enabled (TM2) [ 0.000999] Intel(R) Core(TM)2 Quad CPU @ 2.40GHz stepping 07 [ 0.149473] checking TSC synchronization [CPU#0 -> CPU#1]: passed. [ 0.150050] Booting processor 2/4 APIC 0x1 [ 0.000999] Initializing CPU#2 [ 0.000999] Calibrating delay using timer specific routine.. 4795.02 BogoMIPS (lpj=2397514) [ 0.000999] CPU: L1 I cache: 32K, L1 D cache: 32K [ 0.000999] CPU: L2 cache: 4096K [ 0.000999] CPU: Physical Processor ID: 0 [ 0.000999] CPU: Processor Core ID: 1 [ 0.000999] CPU2: Thermal monitoring enabled (TM2) [ 0.000999] Intel(R) Core(TM)2 Quad CPU @ 2.40GHz stepping 07 [ 0.221461] checking TSC synchronization [CPU#0 -> CPU#2]: passed. [ 0.222057] Booting processor 3/4 APIC 0x3 [ 0.000999] Initializing CPU#3 [ 0.000999] Calibrating delay using timer specific routine.. 4794.98 BogoMIPS (lpj=2397491) [ 0.000999] CPU: L1 I cache: 32K, L1 D cache: 32K [ 0.000999] CPU: L2 cache: 4096K [ 0.000999] CPU: Physical Processor ID: 0 [ 0.000999] CPU: Processor Core ID: 3 [ 0.000999] CPU3: Thermal monitoring enabled (TM2) [ 0.000999] Intel(R) Core(TM)2 Quad CPU @ 2.40GHz stepping 07 [ 0.293467] checking TSC synchronization [CPU#0 -> CPU#3]: passed. [ 0.293961] Brought up 4 CPUs [ 0.294306] net_namespace: 880 bytes [ 0.294415] xor: automatically using best checksumming function: generic_sse [ 0.298955] generic_sse: 8536.000 MB/sec [ 0.298957] xor: using function: generic_sse (8536.000 MB/sec) [ 0.299014] NET: Registered protocol family 16 [ 0.299181] No dock devices found. [ 0.299286] ACPI: bus type pci registered [ 0.303042] PCI: Using MMCONFIG at f0000000 - f7ffffff [ 0.303044] PCI: Using configuration type 1 [ 0.306292] ACPI: EC: Look up EC in DSDT [ 0.308191] ACPI: Interpreter enabled [ 0.308194] ACPI: (supports S0 S5) [ 0.308211] ACPI: Using IOAPIC for interrupt routing [ 0.312322] ACPI: PCI Root Bridge [PCI0] (0000:00) [ 0.313000] pci 0000:00:1f.0: quirk: region 0400-047f claimed by ICH6 ACPI/GPIO/TCO [ 0.313005] pci 0000:00:1f.0: quirk: region 0500-053f claimed by ICH6 GPIO [ 0.313823] PCI: Transparent bridge - 0000:00:1e.0 [ 0.313853] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] [ 0.314182] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P32_._PRT] [ 0.314416] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX0._PRT] [ 0.314506] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX1._PRT] [ 0.314596] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX2._PRT] [ 0.314685] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX3._PRT] [ 0.314774] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX4._PRT] [ 0.319373] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 10 *11 12) [ 0.319459] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 9 *10 11 12) [ 0.319555] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 9 10 *11 12) [ 0.319639] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 9 10 *11 12) [ 0.319722] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 *9 10 11 12) [ 0.319804] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 9 *10 11 12) [ 0.319887] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 7 *9 10 11 12) [ 0.319951] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 7 9 10 *11 12) [ 0.320223] Linux Plug and Play Support v0.97 (c) Adam Belay [ 0.320284] pnp: PnP ACPI init [ 0.320293] ACPI: bus type pnp registered [ 0.323494] pnp: PnP ACPI: found 11 devices [ 0.323498] ACPI: ACPI bus type pnp unregistered [ 0.323753] SCSI subsystem initialized [ 0.323851] libata version 3.00 loaded. [ 0.323950] usbcore: registered new interface driver usbfs [ 0.323960] usbcore: registered new interface driver hub [ 0.324020] usbcore: registered new device driver usb [ 0.324274] PCI: Using ACPI for IRQ routing [ 0.324277] PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report [ 0.328963] PCI-GART: No AMD northbridge found. [ 0.328970] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0 [ 0.328976] hpet0: 3 64-bit timers, 14318180 Hz [ 0.332963] system 00:01: iomem range 0xf0000000-0xf7ffffff could not be reserved [ 0.332969] system 00:01: iomem range 0xfed13000-0xfed13fff has been reserved [ 0.332974] system 00:01: iomem range 0xfed14000-0xfed17fff has been reserved [ 0.332978] system 00:01: iomem range 0xfed18000-0xfed18fff has been reserved [ 0.332983] system 00:01: iomem range 0xfed19000-0xfed19fff has been reserved [ 0.332987] system 00:01: iomem range 0xfed1c000-0xfed1ffff has been reserved [ 0.332991] system 00:01: iomem range 0xfed20000-0xfed3ffff has been reserved [ 0.332996] system 00:01: iomem range 0xfed45000-0xfed99fff has been reserved [ 0.333000] system 00:01: iomem range 0xc0000-0xdffff has been reserved [ 0.333004] system 00:01: iomem range 0xe0000-0xfffff could not be reserved [ 0.333014] system 00:06: ioport range 0x500-0x53f has been reserved [ 0.333018] system 00:06: ioport range 0x400-0x47f has been reserved [ 0.333022] system 00:06: ioport range 0x360-0x361 has been reserved [ 0.333026] system 00:06: ioport range 0x680-0x6ff has been reserved [ 0.333686] PCI: Bridge: 0000:00:1c.0 [ 0.333689] IO window: disabled. [ 0.333693] MEM window: disabled. [ 0.333696] PREFETCH window: disabled. [ 0.333701] PCI: Bridge: 0000:00:1c.1 [ 0.333703] IO window: 5000-5fff [ 0.333708] MEM window: 0xe0400000-0xe04fffff [ 0.333711] PREFETCH window: disabled. [ 0.333716] PCI: Bridge: 0000:00:1c.2 [ 0.333719] IO window: 4000-4fff [ 0.333723] MEM window: 0xe0300000-0xe03fffff [ 0.333727] PREFETCH window: 0x00000000e0700000-0x00000000e07fffff [ 0.333732] PCI: Bridge: 0000:00:1c.3 [ 0.333735] IO window: 3000-3fff [ 0.333739] MEM window: 0xe0200000-0xe02fffff [ 0.333742] PREFETCH window: 0x00000000e0800000-0x00000000e08fffff [ 0.333748] PCI: Bridge: 0000:00:1c.4 [ 0.333750] IO window: 2000-2fff [ 0.333754] MEM window: 0xe0100000-0xe01fffff [ 0.333758] PREFETCH window: 0x00000000e0900000-0x00000000e09fffff [ 0.333764] PCI: Bridge: 0000:00:1e.0 [ 0.333766] IO window: 1000-1fff [ 0.333770] MEM window: 0xe0000000-0xe00fffff [ 0.333774] PREFETCH window: 0x00000000e0a00000-0x00000000e0afffff [ 0.333794] ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 17 (level, low) -> IRQ 17 [ 0.333800] PCI: Setting latency timer of device 0000:00:1c.0 to 64 [ 0.333814] ACPI: PCI Interrupt 0000:00:1c.1[B] -> GSI 16 (level, low) -> IRQ 16 [ 0.333820] PCI: Setting latency timer of device 0000:00:1c.1 to 64 [ 0.333833] ACPI: PCI Interrupt 0000:00:1c.2[C] -> GSI 18 (level, low) -> IRQ 18 [ 0.333839] PCI: Setting latency timer of device 0000:00:1c.2 to 64 [ 0.333872] ACPI: PCI Interrupt 0000:00:1c.3[D] -> GSI 19 (level, low) -> IRQ 19 [ 0.333878] PCI: Setting latency timer of device 0000:00:1c.3 to 64 [ 0.333891] ACPI: PCI Interrupt 0000:00:1c.4[A] -> GSI 17 (level, low) -> IRQ 17 [ 0.333896] PCI: Setting latency timer of device 0000:00:1c.4 to 64 [ 0.333904] PCI: Setting latency timer of device 0000:00:1e.0 to 64 [ 0.333949] NET: Registered protocol family 2 [ 0.345005] IP route cache hash table entries: 262144 (order: 9, 2097152 bytes) [ 0.345590] TCP established hash table entries: 262144 (order: 10, 4194304 bytes) [ 0.347184] TCP bind hash table entries: 65536 (order: 8, 1048576 bytes) [ 0.347731] TCP: Hash tables configured (established 262144 bind 65536) [ 0.347735] TCP reno registered [ 0.056035] Installing knfsd (copyright (C) 1996 okir@monad.swb.de). [ 0.056134] SGI XFS with large block/inode numbers, no debug enabled [ 0.056622] async_tx: api initialized (sync-only) [ 0.056625] io scheduler noop registered [ 0.056649] io scheduler cfq registered (default) [ 0.056657] pci 0000:00:02.0: Boot video device [ 0.056993] PCI: Setting latency timer of device 0000:00:1c.0 to 64 [ 0.057019] assign_interrupt_mode Found MSI capability [ 0.057048] Allocate Port Service[0000:00:1c.0:pcie00] [ 0.057106] Allocate Port Service[0000:00:1c.0:pcie02] [ 0.057152] Allocate Port Service[0000:00:1c.0:pcie03] [ 0.057246] PCI: Setting latency timer of device 0000:00:1c.1 to 64 [ 0.057276] assign_interrupt_mode Found MSI capability [ 0.057308] Allocate Port Service[0000:00:1c.1:pcie00] [ 0.057348] Allocate Port Service[0000:00:1c.1:pcie02] [ 0.057386] Allocate Port Service[0000:00:1c.1:pcie03] [ 0.057468] PCI: Setting latency timer of device 0000:00:1c.2 to 64 [ 0.057498] assign_interrupt_mode Found MSI capability [ 0.057530] Allocate Port Service[0000:00:1c.2:pcie00] [ 0.057570] Allocate Port Service[0000:00:1c.2:pcie02] [ 0.057607] Allocate Port Service[0000:00:1c.2:pcie03] [ 0.057712] PCI: Setting latency timer of device 0000:00:1c.3 to 64 [ 0.057737] assign_interrupt_mode Found MSI capability [ 0.057763] Allocate Port Service[0000:00:1c.3:pcie00] [ 0.057815] Allocate Port Service[0000:00:1c.3:pcie02] [ 0.057861] Allocate Port Service[0000:00:1c.3:pcie03] [ 0.057957] PCI: Setting latency timer of device 0000:00:1c.4 to 64 [ 0.057986] assign_interrupt_mode Found MSI capability [ 0.057991] Allocate Port Service[0000:00:1c.4:pcie00] [ 0.057991] Allocate Port Service[0000:00:1c.4:pcie02] [ 0.058031] Allocate Port Service[0000:00:1c.4:pcie03] [ 0.058403] vesafb: framebuffer at 0xd0000000, mapped to 0xffffc20008100000, using 2560k, total 7616k [ 0.058407] vesafb: mode is 1280x1024x8, linelength=1280, pages=4 [ 0.058409] vesafb: scrolling: redraw [ 0.058412] vesafb: Pseudocolor: size=8:8:8:8, shift=0:0:0:0 [ 0.069212] Console: switching to colour frame buffer device 160x64 [ 0.079909] fb0: VESA VGA frame buffer device [ 0.080054] input: Power Button (FF) as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input0 [ 0.080170] ACPI: Power Button (FF) [PWRF] [ 0.080298] input: Sleep Button (CM) as /devices/LNXSYSTM:00/device:00/PNP0C0E:00/input/input1 [ 0.080417] ACPI: Sleep Button (CM) [SLPB] [ 0.090085] Real Time Clock Driver v1.12ac [ 0.090232] hpet_resources: 0xfed00000 is busy [ 0.090273] Linux agpgart interface v0.103 [ 0.090341] agpgart: Detected an Intel 965G Chipset. [ 0.091700] agpgart: Detected 7676K stolen memory. [ 0.104465] agpgart: AGP aperture is 256M @ 0xd0000000 [ 0.104650] [drm] Initialized drm 1.1.0 20060810 [ 0.104735] ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 16 [ 0.104840] PCI: Setting latency timer of device 0000:00:02.0 to 64 [ 0.104982] [drm] Initialized i915 1.6.0 20060119 on minor 0 [ 0.105433] loop: module loaded [ 0.105552] Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI [ 0.105640] Copyright (c) 1999-2006 Intel Corporation. [ 0.105738] ACPI: PCI Interrupt 0000:06:00.0[A] -> GSI 21 (level, low) -> IRQ 21 [ 0.388945] Switched to high resolution mode on CPU 1 [ 0.208970] Switched to high resolution mode on CPU 3 [ 0.296959] Switched to high resolution mode on CPU 2 [ 0.500925] Switched to high resolution mode on CPU 0 [ 0.353439] e1000: 0000:06:00.0: e1000_probe: (PCI:33MHz:32-bit) 00:07:e9:29:37:db [ 0.379214] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection [ 0.379323] ACPI: PCI Interrupt 0000:06:01.0[A] -> GSI 22 (level, low) -> IRQ 22 [ 0.641506] e1000: 0000:06:01.0: e1000_probe: (PCI:33MHz:32-bit) 00:0e:0c:00:cd:b1 [ 0.789084] e1000: eth1: e1000_probe: Intel(R) PRO/1000 Network Connection [ 0.789212] e1000e: Intel(R) PRO/1000 Network Driver - 0.2.0 [ 0.789288] e1000e: Copyright (c) 1999-2007 Intel Corporation. [ 0.789393] ACPI: PCI Interrupt 0000:00:19.0[A] -> GSI 20 (level, low) -> IRQ 20 [ 0.789502] PCI: Setting latency timer of device 0000:00:19.0 to 64 [ 0.889198] eth2: (PCI Express:2.5GB/s:Width x1) 00:19:d1:6e:9d:43 [ 0.889282] eth2: Intel(R) PRO/1000 Network Connection [ 0.889371] eth2: MAC: 4, PHY: 6, PBA No: ffffff-0ff [ 0.889485] console [netcon0] enabled [ 0.889555] netconsole: network logging started [ 0.889660] Driver 'sd' needs updating - please use bus_type methods [ 0.889819] Driver 'sr' needs updating - please use bus_type methods [ 0.889917] ahci 0000:00:1f.2: version 3.0 [ 0.889931] ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 19 (level, low) -> IRQ 19 [ 1.890735] ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 6 ports 3 Gbps 0x3f impl SATA mode [ 1.890845] ahci 0000:00:1f.2: flags: 64bit ncq sntf led clo pio slum part [ 1.890940] PCI: Setting latency timer of device 0000:00:1f.2 to 64 [ 1.891185] scsi0 : ahci [ 1.891310] scsi1 : ahci [ 1.891419] scsi2 : ahci [ 1.891527] scsi3 : ahci [ 1.891806] scsi4 : ahci [ 1.892805] scsi5 : ahci [ 1.893844] ata1: SATA max UDMA/133 abar m2048@0xe0625000 port 0xe0625100 irq 378 [ 1.894714] ata2: SATA max UDMA/133 abar m2048@0xe0625000 port 0xe0625180 irq 378 [ 1.895713] ata3: SATA max UDMA/133 abar m2048@0xe0625000 port 0xe0625200 irq 378 [ 1.896713] ata4: SATA max UDMA/133 abar m2048@0xe0625000 port 0xe0625280 irq 378 [ 1.897723] ata5: SATA max UDMA/133 abar m2048@0xe0625000 port 0xe0625300 irq 378 [ 1.898713] ata6: SATA max UDMA/133 abar m2048@0xe0625000 port 0xe0625380 irq 378 [ 2.356649] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 2.673654] ata1.00: ATA-8: WDC WD3000GLFS-01F8U0, 03.03V01, max UDMA/133 [ 2.674595] ata1.00: 586072368 sectors, multi 0: LBA48 NCQ (depth 31/32) [ 2.679961] ata1.00: configured for UDMA/133 [ 2.836575] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 3.155395] ata2.00: ATA-8: WDC WD3000GLFS-01F8U0, 03.03V01, max UDMA/133 [ 3.155521] ata2.00: 586072368 sectors, multi 0: LBA48 NCQ (depth 31/32) [ 3.161112] ata2.00: configured for UDMA/133 [ 3.322501] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 3.633983] ata3.00: ATA-8: WDC WD3000GLFS-01F8U0, 03.03V01, max UDMA/133 [ 3.634449] ata3.00: 586072368 sectors, multi 0: LBA48 NCQ (depth 31/32) [ 3.640394] ata3.00: configured for UDMA/133 [ 3.806428] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 4.112403] ata4.00: ATA-8: WDC WD3000GLFS-01F8U0, 03.03V01, max UDMA/133 [ 4.113376] ata4.00: 586072368 sectors, multi 0: LBA48 NCQ (depth 31/32) [ 4.119137] ata4.00: configured for UDMA/133 [ 4.397339] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 4.591563] ata5.00: ATA-8: WDC WD3000GLFS-01F8U0, 03.03V01, max UDMA/133 [ 4.592303] ata5.00: 586072368 sectors, multi 0: LBA48 NCQ (depth 31/32) [ 4.598246] ata5.00: configured for UDMA/133 [ 4.881265] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 5.069692] ata6.00: ATA-8: WDC WD3000GLFS-01F8U0, 03.03V01, max UDMA/133 [ 5.070230] ata6.00: 586072368 sectors, multi 0: LBA48 NCQ (depth 31/32) [ 5.076402] ata6.00: configured for UDMA/133 [ 4.805409] scsi 0:0:0:0: Direct-Access ATA WDC WD3000GLFS-0 03.0 PQ: 0 ANSI: 5 [ 4.806411] sd 0:0:0:0: [sda] 586072368 512-byte hardware sectors (300069 MB) [ 4.808276] sd 0:0:0:0: [sda] Write Protect is off [ 4.809270] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 4.809285] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 4.810314] sd 0:0:0:0: [sda] 586072368 512-byte hardware sectors (300069 MB) [ 4.811277] sd 0:0:0:0: [sda] Write Protect is off [ 4.812269] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [ 4.812284] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 4.813271] sda: sda1 sda2 sda3 [ 5.107470] sd 0:0:0:0: [sda] Attached SCSI disk [ 5.108393] scsi 1:0:0:0: Direct-Access ATA WDC WD3000GLFS-0 03.0 PQ: 0 ANSI: 5 [ 5.109362] sd 1:0:0:0: [sdb] 586072368 512-byte hardware sectors (300069 MB) [ 5.110233] sd 1:0:0:0: [sdb] Write Protect is off [ 5.111224] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [ 5.111239] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 5.112256] sd 1:0:0:0: [sdb] 586072368 512-byte hardware sectors (300069 MB) [ 5.113230] sd 1:0:0:0: [sdb] Write Protect is off [ 5.114223] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [ 5.114238] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 5.115223] sdb: sdb1 sdb2 sdb3 [ 5.183395] sd 1:0:0:0: [sdb] Attached SCSI disk [ 5.184338] scsi 2:0:0:0: Direct-Access ATA WDC WD3000GLFS-0 03.0 PQ: 0 ANSI: 5 [ 5.185346] sd 2:0:0:0: [sdc] 586072368 512-byte hardware sectors (300069 MB) [ 5.186220] sd 2:0:0:0: [sdc] Write Protect is off [ 5.187213] sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 [ 5.187227] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 5.188239] sd 2:0:0:0: [sdc] 586072368 512-byte hardware sectors (300069 MB) [ 5.189219] sd 2:0:0:0: [sdc] Write Protect is off [ 5.190212] sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00 [ 5.190226] sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 5.191212] sdc: sdc1 [ 5.196323] sd 2:0:0:0: [sdc] Attached SCSI disk [ 5.197334] scsi 3:0:0:0: Direct-Access ATA WDC WD3000GLFS-0 03.0 PQ: 0 ANSI: 5 [ 5.198338] sd 3:0:0:0: [sdd] 586072368 512-byte hardware sectors (300069 MB) [ 5.199218] sd 3:0:0:0: [sdd] Write Protect is off [ 5.200211] sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00 [ 5.200225] sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 5.201238] sd 3:0:0:0: [sdd] 586072368 512-byte hardware sectors (300069 MB) [ 5.202217] sd 3:0:0:0: [sdd] Write Protect is off [ 5.203210] sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00 [ 5.203224] sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 5.204210] sdd: sdd1 [ 5.210279] sd 3:0:0:0: [sdd] Attached SCSI disk [ 5.211333] scsi 4:0:0:0: Direct-Access ATA WDC WD3000GLFS-0 03.0 PQ: 0 ANSI: 5 [ 5.212335] sd 4:0:0:0: [sde] 586072368 512-byte hardware sectors (300069 MB) [ 5.213216] sd 4:0:0:0: [sde] Write Protect is off [ 5.214209] sd 4:0:0:0: [sde] Mode Sense: 00 3a 00 00 [ 5.214223] sd 4:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 5.215236] sd 4:0:0:0: [sde] 586072368 512-byte hardware sectors (300069 MB) [ 5.216215] sd 4:0:0:0: [sde] Write Protect is off [ 5.217208] sd 4:0:0:0: [sde] Mode Sense: 00 3a 00 00 [ 5.217222] sd 4:0:0:0: [sde] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 5.218208] sde: sde1 [ 5.226329] sd 4:0:0:0: [sde] Attached SCSI disk [ 5.227335] scsi 5:0:0:0: Direct-Access ATA WDC WD3000GLFS-0 03.0 PQ: 0 ANSI: 5 [ 5.228332] sd 5:0:0:0: [sdf] 586072368 512-byte hardware sectors (300069 MB) [ 5.229214] sd 5:0:0:0: [sdf] Write Protect is off [ 5.230206] sd 5:0:0:0: [sdf] Mode Sense: 00 3a 00 00 [ 5.230221] sd 5:0:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 5.231234] sd 5:0:0:0: [sdf] 586072368 512-byte hardware sectors (300069 MB) [ 5.232213] sd 5:0:0:0: [sdf] Write Protect is off [ 5.233205] sd 5:0:0:0: [sdf] Mode Sense: 00 3a 00 00 [ 5.233220] sd 5:0:0:0: [sdf] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 5.234205] sdf: sdf1 [ 5.240317] sd 5:0:0:0: [sdf] Attached SCSI disk [ 5.241403] sata_sil24 0000:03:00.0: version 1.1 [ 5.241433] ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 18 (level, low) -> IRQ 18 [ 5.242246] PCI: Setting latency timer of device 0000:03:00.0 to 64 [ 5.243248] scsi6 : sata_sil24 [ 5.245287] scsi7 : sata_sil24 [ 5.247256] ata7: SATA max UDMA/100 host m128@0xe0304000 port 0xe0300000 irq 18 [ 5.248205] ata8: SATA max UDMA/100 host m128@0xe0304000 port 0xe0302000 irq 18 [ 7.228923] ata7: SATA link up 3.0 Gbps (SStatus 123 SControl 0) [ 7.400910] ata7.00: ATA-8: WDC WD3000GLFS-01F8U0, 03.03V01, max UDMA/133 [ 7.401876] ata7.00: 586072368 sectors, multi 16: LBA48 NCQ (depth 31/32) [ 7.407950] ata7.00: configured for UDMA/100 [ 9.394593] ata8: SATA link up 3.0 Gbps (SStatus 123 SControl 0) [ 9.561003] ata8.00: ATA-8: WDC WD3000GLFS-01F8U0, 03.03V01, max UDMA/133 [ 9.561548] ata8.00: 586072368 sectors, multi 16: LBA48 NCQ (depth 31/32) [ 9.567892] ata8.00: configured for UDMA/100 [ 9.568598] scsi 6:0:0:0: Direct-Access ATA WDC WD3000GLFS-0 03.0 PQ: 0 ANSI: 5 [ 9.569683] sd 6:0:0:0: [sdg] 586072368 512-byte hardware sectors (300069 MB) [ 9.570561] sd 6:0:0:0: [sdg] Write Protect is off [ 9.571546] sd 6:0:0:0: [sdg] Mode Sense: 00 3a 00 00 [ 9.572553] sd 6:0:0:0: [sdg] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 9.573575] sd 6:0:0:0: [sdg] 586072368 512-byte hardware sectors (300069 MB) [ 9.574553] sd 6:0:0:0: [sdg] Write Protect is off [ 9.575545] sd 6:0:0:0: [sdg] Mode Sense: 00 3a 00 00 [ 9.575560] sd 6:0:0:0: [sdg] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 9.576546] sdg: sdg1 [ 9.609654] sd 6:0:0:0: [sdg] Attached SCSI disk [ 9.610670] scsi 7:0:0:0: Direct-Access ATA WDC WD3000GLFS-0 03.0 PQ: 0 ANSI: 5 [ 9.611677] sd 7:0:0:0: [sdh] 586072368 512-byte hardware sectors (300069 MB) [ 9.612547] sd 7:0:0:0: [sdh] Write Protect is off [ 9.613540] sd 7:0:0:0: [sdh] Mode Sense: 00 3a 00 00 [ 9.613554] sd 7:0:0:0: [sdh] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 9.614566] sd 7:0:0:0: [sdh] 586072368 512-byte hardware sectors (300069 MB) [ 9.615546] sd 7:0:0:0: [sdh] Write Protect is off [ 9.616539] sd 7:0:0:0: [sdh] Mode Sense: 00 3a 00 00 [ 9.616553] sd 7:0:0:0: [sdh] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 9.617539] sdh: sdh1 [ 9.620650] sd 7:0:0:0: [sdh] Attached SCSI disk [ 9.621631] ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 19 (level, low) -> IRQ 19 [ 9.622573] PCI: Setting latency timer of device 0000:04:00.0 to 64 [ 9.622685] scsi8 : sata_sil24 [ 9.623643] scsi9 : sata_sil24 [ 9.624621] ata9: SATA max UDMA/100 host m128@0xe0204000 port 0xe0200000 irq 19 [ 9.625539] ata10: SATA max UDMA/100 host m128@0xe0204000 port 0xe0202000 irq 19 [ 11.684245] ata9: SATA link up 3.0 Gbps (SStatus 123 SControl 0) [ 11.780237] ata9.00: ATA-8: WDC WD3000GLFS-01F8U0, 03.03V01, max UDMA/133 [ 11.781210] ata9.00: 586072368 sectors, multi 16: LBA48 NCQ (depth 31/32) [ 11.789115] ata9.00: configured for UDMA/100 [ 13.852915] ata10: SATA link up 3.0 Gbps (SStatus 123 SControl 0) [ 13.937011] ata10.00: ATA-8: WDC WD3000GLFS-01F8U0, 03.03V01, max UDMA/133 [ 13.938882] ata10.00: 586072368 sectors, multi 16: LBA48 NCQ (depth 31/32) [ 13.945218] ata10.00: configured for UDMA/100 [ 13.945947] scsi 8:0:0:0: Direct-Access ATA WDC WD3000GLFS-0 03.0 PQ: 0 ANSI: 5 [ 13.947020] sd 8:0:0:0: [sdi] 586072368 512-byte hardware sectors (300069 MB) [ 13.947889] sd 8:0:0:0: [sdi] Write Protect is off [ 13.948881] sd 8:0:0:0: [sdi] Mode Sense: 00 3a 00 00 [ 13.948895] sd 8:0:0:0: [sdi] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 13.949909] sd 8:0:0:0: [sdi] 586072368 512-byte hardware sectors (300069 MB) [ 13.950887] sd 8:0:0:0: [sdi] Write Protect is off [ 13.951880] sd 8:0:0:0: [sdi] Mode Sense: 00 3a 00 00 [ 13.951894] sd 8:0:0:0: [sdi] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 13.952880] sdi: sdi1 [ 13.988990] sd 8:0:0:0: [sdi] Attached SCSI disk [ 13.990005] scsi 9:0:0:0: Direct-Access ATA WDC WD3000GLFS-0 03.0 PQ: 0 ANSI: 5 [ 13.991004] sd 9:0:0:0: [sdj] 586072368 512-byte hardware sectors (300069 MB) [ 13.991881] sd 9:0:0:0: [sdj] Write Protect is off [ 13.992874] sd 9:0:0:0: [sdj] Mode Sense: 00 3a 00 00 [ 13.992889] sd 9:0:0:0: [sdj] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 13.993901] sd 9:0:0:0: [sdj] 586072368 512-byte hardware sectors (300069 MB) [ 13.994881] sd 9:0:0:0: [sdj] Write Protect is off [ 13.995873] sd 9:0:0:0: [sdj] Mode Sense: 00 3a 00 00 [ 13.995887] sd 9:0:0:0: [sdj] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 13.996873] sdj: sdj1 [ 14.003988] sd 9:0:0:0: [sdj] Attached SCSI disk [ 14.004964] ACPI: PCI Interrupt 0000:05:00.0[A] -> GSI 16 (level, low) -> IRQ 16 [ 14.006907] PCI: Setting latency timer of device 0000:05:00.0 to 64 [ 14.007021] scsi10 : sata_sil24 [ 14.007976] scsi11 : sata_sil24 [ 14.008943] ata11: SATA max UDMA/100 host m128@0xe0104000 port 0xe0100000 irq 16 [ 14.009873] ata12: SATA max UDMA/100 host m128@0xe0104000 port 0xe0102000 irq 16 [ 16.144568] ata11: SATA link up 3.0 Gbps (SStatus 123 SControl 0) [ 16.161178] ata11.00: ATA-8: WDC WD3000GLFS-01F8U0, 03.03V01, max UDMA/133 [ 16.161544] ata11.00: 586072368 sectors, multi 16: LBA48 NCQ (depth 31/32) [ 16.167968] ata11.00: configured for UDMA/100 [ 18.309238] ata12: SATA link up 3.0 Gbps (SStatus 123 SControl 0) [ 18.319689] ata12.00: ATA-8: WDC WD3000GLFS-01F8U0, 03.03V01, max UDMA/133 [ 18.320216] ata12.00: 586072368 sectors, multi 16: LBA48 NCQ (depth 31/32) [ 18.326309] ata12.00: configured for UDMA/100 [ 18.327263] scsi 10:0:0:0: Direct-Access ATA WDC WD3000GLFS-0 03.0 PQ: 0 ANSI: 5 [ 18.328352] sd 10:0:0:0: [sdk] 586072368 512-byte hardware sectors (300069 MB) [ 18.329222] sd 10:0:0:0: [sdk] Write Protect is off [ 18.330215] sd 10:0:0:0: [sdk] Mode Sense: 00 3a 00 00 [ 18.330229] sd 10:0:0:0: [sdk] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 18.331252] sd 10:0:0:0: [sdk] 586072368 512-byte hardware sectors (300069 MB) [ 18.332221] sd 10:0:0:0: [sdk] Write Protect is off [ 18.333214] sd 10:0:0:0: [sdk] Mode Sense: 00 3a 00 00 [ 18.333228] sd 10:0:0:0: [sdk] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 18.334214] sdk: sdk1 [ 18.368324] sd 10:0:0:0: [sdk] Attached SCSI disk [ 18.369335] scsi 11:0:0:0: Direct-Access ATA WDC WD3000GLFS-0 03.0 PQ: 0 ANSI: 5 [ 18.370336] sd 11:0:0:0: [sdl] 586072368 512-byte hardware sectors (300069 MB) [ 18.371216] sd 11:0:0:0: [sdl] Write Protect is off [ 18.372208] sd 11:0:0:0: [sdl] Mode Sense: 00 3a 00 00 [ 18.372223] sd 11:0:0:0: [sdl] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 18.373235] sd 11:0:0:0: [sdl] 586072368 512-byte hardware sectors (300069 MB) [ 18.374215] sd 11:0:0:0: [sdl] Write Protect is off [ 18.375207] sd 11:0:0:0: [sdl] Mode Sense: 00 3a 00 00 [ 18.375222] sd 11:0:0:0: [sdl] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 18.376207] sdl: sdl1 [ 18.380321] sd 11:0:0:0: [sdl] Attached SCSI disk [ 18.381333] ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 17 (level, low) -> IRQ 17 [ 18.382224] PCI: Setting latency timer of device 0000:02:00.0 to 64 [ 18.382298] scsi12 : pata_marvell [ 18.383309] scsi13 : pata_marvell [ 18.384281] ata13: PATA max UDMA/100 cmd 0x5018 ctl 0x5024 bmdma 0x5000 irq 17 [ 18.385206] ata14: DUMMY [ 18.466560] BAR5:00:00 01:7F 02:22 03:CA 04:00 05:00 06:00 07:00 08:00 09:00 0A:00 0B:00 0C:01 0D:00 0E:00 0F:00 [ 18.772535] ata13.00: ATAPI: _NEC DVD_RW ND-3520A, 1.04, max UDMA/33 [ 18.930500] ata13.00: configured for UDMA/33 [ 18.861800] scsi 12:0:0:0: CD-ROM _NEC DVD_RW ND-3520A 1.04 PQ: 0 ANSI: 5 [ 18.865373] sr0: scsi3-mmc drive: 48x/48x writer cd/rw xa/form2 cdda tray [ 18.866133] Uniform CD-ROM driver Revision: 3.20 [ 18.867235] sr 12:0:0:0: Attached scsi CD-ROM sr0 [ 18.867611] ACPI: PCI Interrupt 0000:06:03.0[A] -> GSI 19 (level, low) -> IRQ 19 [ 18.918810] ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[19] MMIO=[e0084000-e00847ff] Max Packet=[2048] IR/IT contexts=[4/8] [ 18.919278] ACPI: PCI Interrupt 0000:00:1a.7[C] -> GSI 18 (level, low) -> IRQ 18 [ 18.920130] PCI: Setting latency timer of device 0000:00:1a.7 to 64 [ 18.920143] ehci_hcd 0000:00:1a.7: EHCI Host Controller [ 18.921206] ehci_hcd 0000:00:1a.7: new USB bus registered, assigned bus number 1 [ 18.926036] ehci_hcd 0000:00:1a.7: debug port 1 [ 18.926127] PCI: cache line size of 32 is not supported by device 0000:00:1a.7 [ 18.926131] ehci_hcd 0000:00:1a.7: irq 18, io mem 0xe0625c00 [ 18.937125] ehci_hcd 0000:00:1a.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 [ 18.938335] usb usb1: configuration #1 chosen from 1 choice [ 18.939201] hub 1-0:1.0: USB hub found [ 18.940135] hub 1-0:1.0: 4 ports detected [ 19.042249] ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 23 (level, low) -> IRQ 23 [ 19.043110] PCI: Setting latency timer of device 0000:00:1d.7 to 64 [ 19.043113] ehci_hcd 0000:00:1d.7: EHCI Host Controller [ 19.044174] ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 2 [ 19.049012] ehci_hcd 0000:00:1d.7: debug port 1 [ 19.049108] PCI: cache line size of 32 is not supported by device 0000:00:1d.7 [ 19.049114] ehci_hcd 0000:00:1d.7: irq 23, io mem 0xe0625800 [ 19.060107] ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 [ 19.062156] usb usb2: configuration #1 chosen from 1 choice [ 19.063169] hub 2-0:1.0: USB hub found [ 19.064106] hub 2-0:1.0: 6 ports detected [ 19.166238] USB Universal Host Controller Interface driver v3.0 [ 19.168113] ACPI: PCI Interrupt 0000:00:1a.0[A] -> GSI 16 (level, low) -> IRQ 16 [ 19.169090] PCI: Setting latency timer of device 0000:00:1a.0 to 64 [ 19.169092] uhci_hcd 0000:00:1a.0: UHCI Host Controller [ 19.170155] uhci_hcd 0000:00:1a.0: new USB bus registered, assigned bus number 3 [ 19.171104] uhci_hcd 0000:00:1a.0: irq 16, io base 0x000060c0 [ 19.172265] usb usb3: configuration #1 chosen from 1 choice [ 19.173151] hub 3-0:1.0: USB hub found [ 19.174089] hub 3-0:1.0: 2 ports detected [ 19.276199] ACPI: PCI Interrupt 0000:00:1a.1[B] -> GSI 21 (level, low) -> IRQ 21 [ 19.277073] PCI: Setting latency timer of device 0000:00:1a.1 to 64 [ 19.277076] uhci_hcd 0000:00:1a.1: UHCI Host Controller [ 19.278138] uhci_hcd 0000:00:1a.1: new USB bus registered, assigned bus number 4 [ 19.279091] uhci_hcd 0000:00:1a.1: irq 21, io base 0x000060a0 [ 19.280226] usb usb4: configuration #1 chosen from 1 choice [ 19.281135] hub 4-0:1.0: USB hub found [ 19.282073] hub 4-0:1.0: 2 ports detected [ 19.464056] hub 2-0:1.0: unable to enumerate USB device on port 1 [ 19.384175] ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 23 (level, low) -> IRQ 23 [ 19.385057] PCI: Setting latency timer of device 0000:00:1d.0 to 64 [ 19.385059] uhci_hcd 0000:00:1d.0: UHCI Host Controller [ 19.386124] uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 5 [ 19.387070] uhci_hcd 0000:00:1d.0: irq 23, io base 0x00006080 [ 19.388214] usb usb5: configuration #1 chosen from 1 choice [ 19.389120] hub 5-0:1.0: USB hub found [ 19.390056] hub 5-0:1.0: 2 ports detected [ 19.672020] hub 2-0:1.0: unable to enumerate USB device on port 4 [ 19.492163] ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 19 [ 19.493040] PCI: Setting latency timer of device 0000:00:1d.1 to 64 [ 19.493043] uhci_hcd 0000:00:1d.1: UHCI Host Controller [ 19.494105] uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 6 [ 19.495056] uhci_hcd 0000:00:1d.1: irq 19, io base 0x00006060 [ 19.497094] usb usb6: configuration #1 chosen from 1 choice [ 19.498103] hub 6-0:1.0: USB hub found [ 19.499040] hub 6-0:1.0: 2 ports detected [ 19.601147] ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 18 [ 19.602024] PCI: Setting latency timer of device 0000:00:1d.2 to 64 [ 19.602026] uhci_hcd 0000:00:1d.2: UHCI Host Controller [ 19.603090] uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 7 [ 19.605028] uhci_hcd 0000:00:1d.2: irq 18, io base 0x00006040 [ 19.606177] usb usb7: configuration #1 chosen from 1 choice [ 19.607085] hub 7-0:1.0: USB hub found [ 19.608023] hub 7-0:1.0: 2 ports detected [ 19.893981] usb 5-1: new low speed USB device using uhci_hcd and address 2 [ 19.710157] Initializing USB Mass Storage driver... [ 19.827405] usb 5-1: configuration #1 chosen from 1 choice [ 20.023123] ieee1394: Host added: ID:BUS[0-00:1023] GUID[0090270001c5be9f] [ 20.036960] usb 6-2: new full speed USB device using uhci_hcd and address 2 [ 20.196959] usb 6-2: configuration #1 chosen from 1 choice [ 20.203891] hub 6-2:1.0: USB hub found [ 20.204409] hub 6-2:1.0: 3 ports detected [ 20.488800] usb 6-2.1: new full speed USB device using uhci_hcd and address 3 [ 20.614902] usb 6-2.1: configuration #1 chosen from 1 choice [ 20.801753] usb 6-2.2: new low speed USB device using uhci_hcd and address 4 [ 20.921856] usb 6-2.2: configuration #1 chosen from 1 choice [ 20.928781] usbcore: registered new interface driver usb-storage [ 20.928826] USB Mass Storage support registered. [ 20.930025] PNP: No PS/2 controller found. Probing ports directly. [ 20.933984] serio: i8042 KBD port at 0x60,0x64 irq 1 [ 20.934820] serio: i8042 AUX port at 0x60,0x64 irq 12 [ 20.935892] mice: PS/2 mouse device common for all mice [ 21.267717] input: PC Speaker as /devices/platform/pcspkr/input/input2 [ 21.347193] coretemp coretemp.0: Using relative temperature scale! [ 21.347866] coretemp coretemp.1: Using relative temperature scale! [ 21.348895] coretemp coretemp.2: Using relative temperature scale! [ 21.349863] coretemp coretemp.3: Using relative temperature scale! [ 21.351816] md: raid0 personality registered for level 0 [ 21.352755] md: raid1 personality registered for level 1 [ 21.370766] raid6: int64x1 2277 MB/s [ 21.388751] raid6: int64x2 3000 MB/s [ 21.406758] raid6: int64x4 2789 MB/s [ 21.424753] raid6: int64x8 2089 MB/s [ 21.442750] raid6: sse2x1 3730 MB/s [ 21.460752] raid6: sse2x2 4285 MB/s [ 21.478742] raid6: sse2x4 6664 MB/s [ 21.479735] raid6: using algorithm sse2x4 (6664 MB/s) [ 21.480736] md: raid6 personality registered for level 6 [ 21.481735] md: raid5 personality registered for level 5 [ 21.482735] md: raid4 personality registered for level 4 [ 21.483797] usbcore: registered new interface driver hiddev [ 21.880059] hiddev96: USB HID v1.00 Device [ UPS] on usb-0000:00:1d.0-1 [ 21.883920] input: Dell Dell USB Keyboard Hub as /devices/pci0000:00/0000:00:1d.1/usb6/6-2/6-2.1/6-2.1:1.0/input/input3 [ 21.888678] input: USB HID v1.10 Keyboard [Dell Dell USB Keyboard Hub] on usb-0000:00:1d.1-2.1 [ 21.895665] input: Dell Dell USB Keyboard Hub as /devices/pci0000:00/0000:00:1d.1/usb6/6-2/6-2.1/6-2.1:1.1/input/input4 [ 21.899676] input: USB HID v1.10 Device [Dell Dell USB Keyboard Hub] on usb-0000:00:1d.1-2.1 [ 21.913811] input: USB Optical Mouse as /devices/pci0000:00/0000:00:1d.1/usb6/6-2/6-2.2/6-2.2:1.0/input/input5 [ 21.918715] input: USB HID v1.11 Mouse [USB Optical Mouse] on usb-0000:00:1d.1-2.2 [ 21.919727] usbcore: registered new interface driver usbhid [ 21.920680] drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver [ 21.921741] Advanced Linux Sound Architecture Driver Version 1.0.16rc2 (Thu Jan 31 16:40:16 2008 UTC). [ 21.923773] ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 22 (level, low) -> IRQ 22 [ 21.924681] PCI: Setting latency timer of device 0000:00:1b.0 to 64 [ 21.962235] ALSA device list: [ 21.962662] #0: HDA Intel at 0xe0620000 irq 22 [ 21.963692] u32 classifier [ 21.964661] Actions configured [ 21.965716] nf_conntrack version 0.5.0 (16384 buckets, 65536 max) [ 21.967776] ip_tables: (C) 2000-2006 Netfilter Core Team [ 21.968682] TCP cubic registered [ 21.969680] NET: Registered protocol family 1 [ 21.970670] NET: Registered protocol family 17 [ 21.971846] RPC: Registered udp transport module. [ 21.972661] RPC: Registered tcp transport module. [ 21.974046] md: Autodetecting RAID arrays. [ 22.130876] md: Scanned 16 and added 16 devices. [ 22.131636] md: autorun ... [ 22.132636] md: considering sdl1 ... [ 22.133639] md: adding sdl1 ... [ 22.134638] md: adding sdk1 ... [ 22.135638] md: adding sdj1 ... [ 22.137637] md: adding sdi1 ... [ 22.138637] md: adding sdh1 ... [ 22.139637] md: adding sdg1 ... [ 22.140637] md: adding sdf1 ... [ 22.141637] md: adding sde1 ... [ 22.142637] md: adding sdd1 ... [ 22.143636] md: adding sdc1 ... [ 22.144636] md: sdb3 has different UUID to sdl1 [ 22.145635] md: sdb2 has different UUID to sdl1 [ 22.146635] md: sdb1 has different UUID to sdl1 [ 22.147635] md: sda3 has different UUID to sdl1 [ 22.148634] md: sda2 has different UUID to sdl1 [ 22.149634] md: sda1 has different UUID to sdl1 [ 22.151643] md: created md3 [ 22.152633] md: bind [ 22.153639] md: bind [ 22.154640] md: bind [ 22.155638] md: bind [ 22.156639] md: bind [ 22.157638] md: bind [ 22.158638] md: bind [ 22.159637] md: bind [ 22.160638] md: bind [ 22.161638] md: bind [ 22.162637] md: running: [ 22.163652] md: kicking non-fresh sdd1 from array! [ 22.164633] md: unbind [ 22.165633] md: export_rdev(sdd1) [ 22.166637] raid5: device sdl1 operational as raid disk 9 [ 22.167631] raid5: device sdk1 operational as raid disk 8 [ 22.168631] raid5: device sdj1 operational as raid disk 7 [ 22.169630] raid5: device sdi1 operational as raid disk 6 [ 22.170630] raid5: device sdh1 operational as raid disk 5 [ 22.171630] raid5: device sdg1 operational as raid disk 4 [ 22.172630] raid5: device sdf1 operational as raid disk 3 [ 22.173630] raid5: device sde1 operational as raid disk 2 [ 22.174630] raid5: device sdc1 operational as raid disk 0 [ 22.176994] raid5: allocated 10574kB for md3 [ 22.177629] raid5: raid level 5 set md3 active with 9 out of 10 devices, algorithm 2 [ 22.178629] RAID5 conf printout: [ 22.179629] --- rd:10 wd:9 [ 22.180651] disk 0, o:1, dev:sdc1 [ 22.181629] disk 2, o:1, dev:sde1 [ 22.182629] disk 3, o:1, dev:sdf1 [ 22.183628] disk 4, o:1, dev:sdg1 [ 22.184628] disk 5, o:1, dev:sdh1 [ 22.185628] disk 6, o:1, dev:sdi1 [ 22.186628] disk 7, o:1, dev:sdj1 [ 22.187628] disk 8, o:1, dev:sdk1 [ 22.187629] disk 9, o:1, dev:sdl1 [ 22.190980] md: considering sdb3 ... [ 22.191631] md: adding sdb3 ... [ 22.192628] md: sdb2 has different UUID to sdb3 [ 22.193628] md: sdb1 has different UUID to sdb3 [ 22.194629] md: adding sda3 ... [ 22.195628] md: sda2 has different UUID to sdb3 [ 22.196627] md: sda1 has different UUID to sdb3 [ 22.197712] md: created md2 [ 22.198626] md: bind [ 22.199632] md: bind [ 22.200631] md: running: [ 22.201702] raid1: raid set md2 active with 2 out of 2 mirrors [ 22.202691] md: considering sdb2 ... [ 22.203628] md: adding sdb2 ... [ 22.204626] md: sdb1 has different UUID to sdb2 [ 22.205627] md: adding sda2 ... [ 22.206626] md: sda1 has different UUID to sdb2 [ 22.207703] md: created md1 [ 22.208625] md: bind [ 22.209630] md: bind [ 22.210629] md: running: [ 22.212700] raid1: raid set md1 active with 2 out of 2 mirrors [ 22.213690] md: considering sdb1 ... [ 22.214626] md: adding sdb1 ... [ 22.215626] md: adding sda1 ... [ 22.216624] md: created md0 [ 22.217623] md: bind [ 22.218630] md: bind [ 22.219629] md: running: [ 22.220700] raid1: raid set md0 active with 2 out of 2 mirrors [ 22.221690] md: ... autorun DONE. [ 22.259336] UDF-fs: No VRS found [ 22.259957] Filesystem "md2": Disabling barriers, not supported by the underlying device [ 22.260618] XFS: correcting sb_features alignment problem [ 22.272582] XFS mounting filesystem md2 [ 22.377567] Ending clean XFS mount for filesystem: md2 [ 22.377598] VFS: Mounted root (xfs filesystem) readonly. [ 22.377609] Freeing unused kernel memory: 256k freed [ 24.720255] Adding 16787768k swap on /dev/md0. Priority:-1 extents:1 across:16787768k [ 24.824654] Filesystem "md2": Disabling barriers, not supported by the underlying device [ 26.944903] kjournald starting. Commit interval 5 seconds [ 26.518955] EXT3 FS on md1, internal journal [ 26.518959] EXT3-fs: mounted filesystem with ordered data mode. [ 26.519307] Filesystem "md3": Disabling barriers, not supported by the underlying device [ 26.519447] XFS mounting filesystem md3 [ 26.683692] Ending clean XFS mount for filesystem: md3 [ 28.560034] e1000: eth1: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX [ 28.734046] e1000: eth2: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX [ 30.053502] eth0: Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX [ 33.513766] warning: `named' uses 32-bit capabilities (legacy support in use) [ 185.127945] md: bind [ 185.150226] RAID5 conf printout: [ 185.150230] --- rd:10 wd:9 [ 185.150232] disk 0, o:1, dev:sdc1 [ 185.150235] disk 1, o:1, dev:sdd1 [ 185.150238] disk 2, o:1, dev:sde1 [ 185.150241] disk 3, o:1, dev:sdf1 [ 185.150244] disk 4, o:1, dev:sdg1 [ 185.150247] disk 5, o:1, dev:sdh1 [ 185.150250] disk 6, o:1, dev:sdi1 [ 185.150253] disk 7, o:1, dev:sdj1 [ 185.150256] disk 8, o:1, dev:sdk1 [ 185.150258] disk 9, o:1, dev:sdl1 [ 185.053336] md: recovery of RAID array md3 [ 185.053361] md: minimum _guaranteed_ speed: 1000 KB/sec/disk. [ 185.053362] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for recovery. [ 185.053371] md: using 128k window, over a total of 293032960 blocks. [ 5832.879634] md: md3: recovery done. [ 5833.870866] RAID5 conf printout: [ 5833.870875] --- rd:10 wd:10 [ 5833.870878] disk 0, o:1, dev:sdc1 [ 5833.870882] disk 1, o:1, dev:sdd1 [ 5833.870885] disk 2, o:1, dev:sde1 [ 5833.870888] disk 3, o:1, dev:sdf1 [ 5833.870891] disk 4, o:1, dev:sdg1 [ 5833.870893] disk 5, o:1, dev:sdh1 [ 5833.870896] disk 6, o:1, dev:sdi1 [ 5833.870909] disk 7, o:1, dev:sdj1 [ 5833.870911] disk 8, o:1, dev:sdk1 [ 5833.870913] disk 9, o:1, dev:sdl1 [55164.325258] md: data-check of RAID array md0 [55164.325266] md: minimum _guaranteed_ speed: 1000 KB/sec/disk. [55164.325268] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for data-check. [55164.325271] md: using 128k window, over a total of 16787776 blocks. [55165.960235] md: delaying data-check of md1 until md0 has finished (they share one or more physical units) [55166.383909] md: delaying data-check of md2 until md0 has finished (they share one or more physical units) [55166.964687] md: delaying data-check of md1 until md2 has finished (they share one or more physical units) [55167.386914] md: data-check of RAID array md3 [55167.386919] md: minimum _guaranteed_ speed: 1000 KB/sec/disk. [55167.386921] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for data-check. [55167.386928] md: using 128k window, over a total of 293032960 blocks. [55315.529779] md: md0: data-check done. [55315.445302] md: delaying data-check of md1 until md2 has finished (they share one or more physical units) [55315.445319] md: data-check of RAID array md2 [55315.445321] md: minimum _guaranteed_ speed: 1000 KB/sec/disk. [55315.445322] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for data-check. [55315.445327] md: using 128k window, over a total of 276109056 blocks. [55315.556313] RAID1 conf printout: [55315.556321] --- wd:2 rd:2 [55315.556322] disk 0, wo:0, o:1, dev:sda1 [55315.556324] disk 1, wo:0, o:1, dev:sdb1 [58682.444937] md: md2: data-check done. [58682.365721] md: data-check of RAID array md1 [58682.365729] md: minimum _guaranteed_ speed: 1000 KB/sec/disk. [58682.365730] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for data-check. [58682.365734] md: using 128k window, over a total of 136448 blocks. [58682.485403] RAID1 conf printout: [58682.485408] --- wd:2 rd:2 [58682.485420] disk 0, wo:0, o:1, dev:sda3 [58682.485422] disk 1, wo:0, o:1, dev:sdb3 [58683.793698] md: md1: data-check done. [58683.831793] RAID1 conf printout: [58683.831798] --- wd:2 rd:2 [58683.831800] disk 0, wo:0, o:1, dev:sda2 [58683.831801] disk 1, wo:0, o:1, dev:sdb2 [61891.936511] md: md3: data-check done. [61893.152803] RAID5 conf printout: [61893.152812] --- rd:10 wd:10 [61893.152815] disk 0, o:1, dev:sdc1 [61893.152817] disk 1, o:1, dev:sdd1 [61893.152819] disk 2, o:1, dev:sde1 [61893.152821] disk 3, o:1, dev:sdf1 [61893.152822] disk 4, o:1, dev:sdg1 [61893.152824] disk 5, o:1, dev:sdh1 [61893.152826] disk 6, o:1, dev:sdi1 [61893.152827] disk 7, o:1, dev:sdj1 [61893.152829] disk 8, o:1, dev:sdk1 [61893.152831] disk 9, o:1, dev:sdl1 [86349.168562] kvm: emulating exchange as write [87546.433705] apic write: bad size=1 fee00030 [87546.433814] Ignoring de-assert INIT to vcpu 0 [89725.513763] handle_exception: unexpected, vectoring info 0x80000306 intr info 0x80000b0d [89725.514930] pending exception: not handled yet [89725.517367] pending exception: not handled yet [107360.796671] ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen [107360.796680] ata4.00: cmd b0/d8:00:00:4f:c2/00:00:00:00:00/00 tag 0 [107360.796681] res 40/00:ff:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) [107360.796685] ata4.00: status: { DRDY } [107361.099615] ata4: soft resetting link [107361.252599] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [107361.273562] ata4.00: configured for UDMA/133 [107361.273604] ata4: EH complete [107361.018520] sd 3:0:0:0: [sdd] 586072368 512-byte hardware sectors (300069 MB) [107361.018683] sd 3:0:0:0: [sdd] Write Protect is off [107361.018687] sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00 [107361.040887] sd 3:0:0:0: [sdd] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA From owner-xfs@oss.sgi.com Sat Jul 5 13:10:38 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 05 Jul 2008 13:10:39 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m65KAbYa001482 for ; Sat, 5 Jul 2008 13:10:37 -0700 X-ASG-Debug-ID: 1215288701-2e7a032c0000-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 D480D18810F0 for ; Sat, 5 Jul 2008 13:11:41 -0700 (PDT) Received: from mail.lichtvoll.de (mondschein.lichtvoll.de [194.150.191.11]) by cuda.sgi.com with ESMTP id MuoX3IJL39rLaxkK for ; Sat, 05 Jul 2008 13:11:41 -0700 (PDT) Received: from localhost (DSL01.83.171.151.103.ip-pool.NEFkom.net [83.171.151.103]) by mail.lichtvoll.de (Postfix) with ESMTP id EF3045AE2C for ; Sat, 5 Jul 2008 22:11:40 +0200 (CEST) To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: grub fails boot after update Subject: Re: grub fails boot after update From: Martin Steigerwald Date: Sat, 5 Jul 2008 22:11:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807052211.34884.Martin@lichtvoll.de> X-Barracuda-Connect: mondschein.lichtvoll.de[194.150.191.11] X-Barracuda-Start-Time: 1215288701 X-Barracuda-Bayes: INNOCENT GLOBAL 0.2813 1.0000 -0.4296 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= X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.55238 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16739 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs Hi! Am Donnerstag 03 Juli 2008 schrieb Jason White: > On Wed, Jul 02, 2008 at 10:54:38PM -0500, Eric Sandeen wrote: > > This really is grub that is busted, but I'd still just suggest using > > ext3 to (mostly) work around the breakage for the foreseeable future. > > > > The other option is to teach grub to always do its io via the > > filesystem not the block device while the fs is mounted (IIRC there > > are various & sundry non-intuitive commands which actually nudge grub > > towards or away from this desired behavior... --with-stage2=/path is > > one I think, skipping the "verification" phase (i.e. trying to read > > the block dev while mounted) is another) > > Does grub 2 (still in development when last I checked) improve on this > situation? > > I managed to get Grub 1 installed on machines with XFS root file > systems by running the install from within the grub "shell" environment > rather than using grub-install. Maybe this skips the checks that > attempt to read the block device directly. I also recall that > grub-install failed. I use GRUB 1 on XFS ever since. But I also used the GRUB shell directly to write it. grub-install doesn't work reliable. I even use the functionality to save the last booted menu entry into /boot/grub/default without a problem. I agree, reading or writing a mounted filesystem directly is not a good idea. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 From owner-xfs@oss.sgi.com Sat Jul 5 13:10:16 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 05 Jul 2008 13:10:18 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m65KAGBS001413 for ; Sat, 5 Jul 2008 13:10:16 -0700 X-ASG-Debug-ID: 1215288678-2e7c033b0000-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 93EAC18810E4 for ; Sat, 5 Jul 2008 13:11:18 -0700 (PDT) Received: from mail.lichtvoll.de (mondschein.lichtvoll.de [194.150.191.11]) by cuda.sgi.com with ESMTP id sQ5aH93GyrxcCxwL for ; Sat, 05 Jul 2008 13:11:18 -0700 (PDT) Received: from localhost (DSL01.83.171.151.103.ip-pool.NEFkom.net [83.171.151.103]) by mail.lichtvoll.de (Postfix) with ESMTP id 75A9B5AE2C for ; Sat, 5 Jul 2008 22:11:17 +0200 (CEST) From: Martin Steigerwald To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: grub fails boot after update Subject: Re: grub fails boot after update Date: Sat, 5 Jul 2008 22:11:10 +0200 User-Agent: KMail/1.9.9 References: <486C4D7E.8060608@sandeen.net> <20080703044755.GA13630@jdc.jasonjgw.net> (sfid-20080703_143045_158241_F738FCFB) In-Reply-To: <20080703044755.GA13630@jdc.jasonjgw.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1458418.nLvPYxNhxp"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200807052211.10899.Martin@lichtvoll.de> X-Barracuda-Connect: mondschein.lichtvoll.de[194.150.191.11] X-Barracuda-Start-Time: 1215288679 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0248 1.0000 -1.8599 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.86 X-Barracuda-Spam-Status: No, SCORE=-1.86 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.1, rules version 3.1.55238 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16738 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: Martin@lichtvoll.de Precedence: bulk X-list: xfs --nextPart1458418.nLvPYxNhxp Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi! Am Donnerstag 03 Juli 2008 schrieb Jason White: > On Wed, Jul 02, 2008 at 10:54:38PM -0500, Eric Sandeen wrote: > > This really is grub that is busted, but I'd still just suggest using > > ext3 to (mostly) work around the breakage for the foreseeable future. > > > > The other option is to teach grub to always do its io via the > > filesystem not the block device while the fs is mounted (IIRC there > > are various & sundry non-intuitive commands which actually nudge grub > > towards or away from this desired behavior... --with-stage2=3D/path is > > one I think, skipping the "verification" phase (i.e. trying to read > > the block dev while mounted) is another) > > Does grub 2 (still in development when last I checked) improve on this > situation? > > I managed to get Grub 1 installed on machines with XFS root file > systems by running the install from within the grub "shell" environment > rather than using grub-install. Maybe this skips the checks that > attempt to read the block device directly. I also recall that > grub-install failed. I use GRUB 1 on XFS ever since. But I also used the GRUB shell directly to= =20 write it. grub-install doesn't work reliable. I even use the functionality to save the last booted menu entry=20 into /boot/grub/default without a problem. I agree, reading or writing a mounted filesystem directly is not a good=20 idea. Ciao, --=20 Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 --nextPart1458418.nLvPYxNhxp Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEABECAAYFAkhv1V4ACgkQmRvqrKWZhMdDqwCePOKU7SJNz/BZzeyK4RFzmCil MJMAn2geMcOGw3UWCJKl/gE39nsaLfK+ =ckdq -----END PGP SIGNATURE----- --nextPart1458418.nLvPYxNhxp-- From owner-xfs@oss.sgi.com Sat Jul 5 16:21:19 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 05 Jul 2008 16:21:23 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m65NLJ8O018830 for ; Sat, 5 Jul 2008 16:21:19 -0700 X-ASG-Debug-ID: 1215300142-5ae4033e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pd2mo1so-dmz.prod.shaw.ca (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8CF1312DD0E5 for ; Sat, 5 Jul 2008 16:22:22 -0700 (PDT) Received: from pd2mo1so-dmz.prod.shaw.ca (idcmail-mo1so.shaw.ca [24.71.223.10]) by cuda.sgi.com with ESMTP id 3XqyaK7ST6Sj1tuT for ; Sat, 05 Jul 2008 16:22:22 -0700 (PDT) Received: from unknown (HELO pd2ml1so-ssvc.prod.shaw.ca) ([10.0.141.139]) by pd2mo1so-svcs.prod.shaw.ca with ESMTP; 05 Jul 2008 17:22:22 -0600 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.0 c=0 a=06YJs3ZYCObwu2VayQ8A:9 a=_igs-5A00fB-RLDi04kdxpAoJYoA:4 a=YMwqvzZXbQMA:10 a=EWWKLeJB2BwA:10 Received: from s0106000c41bb86e1.ss.shawcable.net (HELO [192.168.1.113]) ([70.64.130.4]) by pd2ml1so-dmz.prod.shaw.ca with ESMTP; 05 Jul 2008 17:22:21 -0600 Message-ID: <48700228.7060904@shaw.ca> Date: Sat, 05 Jul 2008 17:22:16 -0600 From: Robert Hancock User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Justin Piszcz CC: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, linux-ide@vger.kernel.org, xfs@oss.sgi.com, Alan Piszcz X-ASG-Orig-Subj: Re: Lots of con-current I/O = resets SATA link? (2.6.25.10) Subject: Re: Lots of con-current I/O = resets SATA link? (2.6.25.10) References: <486FBFAB.5050303@shaw.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: idcmail-mo1so.shaw.ca[24.71.223.10] X-Barracuda-Start-Time: 1215300143 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.1, rules version 3.1.55241 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16740 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: hancockr@shaw.ca Precedence: bulk X-list: xfs Justin Piszcz wrote: >> Can you post your dmesg from bootup with the controller/drive detection? > > Below: > > [ 0.889917] ahci 0000:00:1f.2: version 3.0 > [ 0.889931] ACPI: PCI Interrupt 0000:00:1f.2[A] -> GSI 19 (level, > low) -> IRQ 19 > [ 1.890735] ahci 0000:00:1f.2: AHCI 0001.0100 32 slots 6 ports 3 Gbps > 0x3f impl SATA mode > [ 1.890845] ahci 0000:00:1f.2: flags: 64bit ncq sntf led clo pio slum > part [ 1.890940] PCI: Setting latency timer of device 0000:00:1f.2 to 64 > [ 1.891185] scsi0 : ahci > [ 1.891310] scsi1 : ahci > [ 1.891419] scsi2 : ahci > [ 1.891527] scsi3 : ahci > [ 1.891806] scsi4 : ahci > [ 1.892805] scsi5 : ahci > [ 1.893844] ata1: SATA max UDMA/133 abar m2048@0xe0625000 port > 0xe0625100 irq 378 > [ 1.894714] ata2: SATA max UDMA/133 abar m2048@0xe0625000 port > 0xe0625180 irq 378 > [ 1.895713] ata3: SATA max UDMA/133 abar m2048@0xe0625000 port > 0xe0625200 irq 378 > [ 1.896713] ata4: SATA max UDMA/133 abar m2048@0xe0625000 port > 0xe0625280 irq 378 > [ 1.897723] ata5: SATA max UDMA/133 abar m2048@0xe0625000 port > 0xe0625300 irq 378 > [ 1.898713] ata6: SATA max UDMA/133 abar m2048@0xe0625000 port > 0xe0625380 irq 378 > [ 2.356649] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > [ 2.673654] ata1.00: ATA-8: WDC WD3000GLFS-01F8U0, 03.03V01, max > UDMA/133 > [ 2.674595] ata1.00: 586072368 sectors, multi 0: LBA48 NCQ (depth 31/32) > [ 2.679961] ata1.00: configured for UDMA/133 > [ 2.836575] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > [ 3.155395] ata2.00: ATA-8: WDC WD3000GLFS-01F8U0, 03.03V01, max > UDMA/133 > [ 3.155521] ata2.00: 586072368 sectors, multi 0: LBA48 NCQ (depth 31/32) > [ 3.161112] ata2.00: configured for UDMA/133 > [ 3.322501] ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > [ 3.633983] ata3.00: ATA-8: WDC WD3000GLFS-01F8U0, 03.03V01, max > UDMA/133 > [ 3.634449] ata3.00: 586072368 sectors, multi 0: LBA48 NCQ (depth 31/32) > [ 3.640394] ata3.00: configured for UDMA/133 > [ 3.806428] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > [ 4.112403] ata4.00: ATA-8: WDC WD3000GLFS-01F8U0, 03.03V01, max > UDMA/133 > [ 4.113376] ata4.00: 586072368 sectors, multi 0: LBA48 NCQ (depth 31/32) > [ 4.119137] ata4.00: configured for UDMA/133 > [ 4.397339] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > [ 4.591563] ata5.00: ATA-8: WDC WD3000GLFS-01F8U0, 03.03V01, max > UDMA/133 > [ 4.592303] ata5.00: 586072368 sectors, multi 0: LBA48 NCQ (depth 31/32) > [ 4.598246] ata5.00: configured for UDMA/133 > [ 4.881265] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > [ 5.069692] ata6.00: ATA-8: WDC WD3000GLFS-01F8U0, 03.03V01, max > UDMA/133 > [ 5.070230] ata6.00: 586072368 sectors, multi 0: LBA48 NCQ (depth 31/32) > [ 5.076402] ata6.00: configured for UDMA/133 So you've got 6 drives in the machine. Intel chipsets normally seem pretty robust with AHCI. > [107360.796671] ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action > 0x2 frozen > [107360.796680] ata4.00: cmd b0/d8:00:00:4f:c2/00:00:00:00:00/00 tag 0 > [107360.796681] res 40/00:ff:00:00:00/00:00:00:00:00/00 Emask > 0x4 (timeout) > [107360.796685] ata4.00: status: { DRDY } > [107361.099615] ata4: soft resetting link > [107361.252599] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300) > [107361.273562] ata4.00: configured for UDMA/133 > [107361.273604] ata4: EH complete > [107361.018520] sd 3:0:0:0: [sdd] 586072368 512-byte hardware sectors > (300069 MB) > [107361.018683] sd 3:0:0:0: [sdd] Write Protect is off > [107361.018687] sd 3:0:0:0: [sdd] Mode Sense: 00 3a 00 00 > [107361.040887] sd 3:0:0:0: [sdd] Write cache: enabled, read cache: > enabled, doesn't support DPO or FUA Are you certain that your machine has enough power to run all those drives properly? We've seen in a number of cases that power fluctuations or noise can cause these kinds of errors. From owner-xfs@oss.sgi.com Sat Jul 5 16:23:49 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 05 Jul 2008 16:23:51 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda1.sgi.com [192.48.168.28]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m65NNnxT019229 for ; Sat, 5 Jul 2008 16:23:49 -0700 X-ASG-Debug-ID: 1215300292-5af3037c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 8D23CDA2A47 for ; Sat, 5 Jul 2008 16:24:52 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id Z8rKcLFEXweaZrX0 for ; Sat, 05 Jul 2008 16:24:52 -0700 (PDT) Received: by lucidpixels.com (Postfix, from userid 1001) id 8435B5A568; Sat, 5 Jul 2008 19:24:52 -0400 (EDT) Date: Sat, 5 Jul 2008 19:24:52 -0400 (EDT) From: Justin Piszcz To: Robert Hancock cc: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, linux-ide@vger.kernel.org, xfs@oss.sgi.com, Alan Piszcz X-ASG-Orig-Subj: Re: Lots of con-current I/O = resets SATA link? (2.6.25.10) Subject: Re: Lots of con-current I/O = resets SATA link? (2.6.25.10) In-Reply-To: <48700228.7060904@shaw.ca> Message-ID: References: <486FBFAB.5050303@shaw.ca> <48700228.7060904@shaw.ca> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1215300293 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.1, rules version 3.1.55241 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16741 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Sat, 5 Jul 2008, Robert Hancock wrote: > Justin Piszcz wrote: >>> Can you post your dmesg from bootup with the controller/drive detection? > > So you've got 6 drives in the machine. Intel chipsets normally seem pretty > robust with AHCI. > > Are you certain that your machine has enough power to run all those drives > properly? We've seen in a number of cases that power fluctuations or noise > can cause these kinds of errors. I have a 650watt PSU (nice antec one) and the power draw of the box is ~148watts w/ veliciraptors, ~250 when fully load all 4 cores + all 12 disks writing. I have turned off the irqbalance daemon and I am going to see if the problem re-occurs. Justin. From owner-xfs@oss.sgi.com Sat Jul 5 21:18:48 2008 Received: with ECARTIS (v1.0.0; list xfs); Sat, 05 Jul 2008 21:18:54 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m664Ikwg011867 for ; Sat, 5 Jul 2008 21:18:47 -0700 X-ASG-Debug-ID: 1215317988-10cb03150000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from ipmail01.adl6.internode.on.net (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 25CDC1BB218D for ; Sat, 5 Jul 2008 21:19:48 -0700 (PDT) Received: from ipmail01.adl6.internode.on.net (ipmail01.adl6.internode.on.net [203.16.214.146]) by cuda.sgi.com with ESMTP id ELDckLtAwivUrBDP for ; Sat, 05 Jul 2008 21:19:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAM/kb0h5LBzp/2dsb2JhbACsMA X-IronPort-AV: E=Sophos;i="4.30,309,1212330600"; d="scan'208";a="142781062" Received: from ppp121-44-28-233.lns10.syd7.internode.on.net (HELO disturbed) ([121.44.28.233]) by ipmail01.adl6.internode.on.net with ESMTP; 06 Jul 2008 13:49:46 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KFLiz-00044T-PY; Sun, 06 Jul 2008 14:19:45 +1000 Date: Sun, 6 Jul 2008 14:19:45 +1000 From: Dave Chinner To: Sagar Borikar Cc: Eric Sandeen , Nathan Scott , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Xfs Access to block zero exception and system crash Subject: Re: Xfs Access to block zero exception and system crash Message-ID: <20080706041945.GH29319@disturbed> Mail-Followup-To: Sagar Borikar , Eric Sandeen , Nathan Scott , xfs@oss.sgi.com References: <20080702065652.GS14251@build-svl-1.agami.com> <486B6062.6040201@pmc-sierra.com> <486C4F89.9030009@sandeen.net> <486C6053.7010503@pmc-sierra.com> <486CE9EA.90502@sandeen.net> <486DF8F0.5010700@pmc-sierra.com> <20080704122726.GG29319@disturbed> <340C71CD25A7EB49BFA81AE8C839266702997641@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <486E5F4D.1010009@sandeen.net> <340C71CD25A7EB49BFA81AE8C839266702997658@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <340C71CD25A7EB49BFA81AE8C839266702997658@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: ipmail01.adl6.internode.on.net[203.16.214.146] X-Barracuda-Start-Time: 1215317990 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0210 1.0000 -1.8848 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.88 X-Barracuda-Spam-Status: No, SCORE=-1.88 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.1, rules version 3.1.55264 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16742 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@fromorbit.com Precedence: bulk X-list: xfs On Fri, Jul 04, 2008 at 10:51:47AM -0700, Sagar Borikar wrote: > > Copy is of the same file to 30 different directories and it is basically > overwrite. Not an overwrite - cp truncates the destination file first: # cp t.t fred # strace cp -f t.t fred ..... stat("fred", {st_mode=S_IFREG|0644, st_size=5, ...}) = 0 stat("t.t", {st_mode=S_IFREG|0644, st_size=5, ...}) = 0 stat("fred", {st_mode=S_IFREG|0644, st_size=5, ...}) = 0 open("t.t", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=5, ...}) = 0 open("fred", O_WRONLY|O_TRUNC) = 4 ^^^^^^^^^^^^^^^^ fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 read(3, "fred\n", 4096) = 5 write(4, "fred\n", 5) = 5 close(4) = 0 close(3) = 0 ..... That being said, I can't reproduce it on a 2.6.24 (debian) kernel, either. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Sun Jul 6 03:30:40 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Jul 2008 03:31:05 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m66AUdRx012717 for ; Sun, 6 Jul 2008 03:30:40 -0700 X-ASG-Debug-ID: 1215340302-737502150000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 250AD29963 for ; Sun, 6 Jul 2008 03:31:42 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id 1RY0vbYlNKuWGKDJ for ; Sun, 06 Jul 2008 03:31:42 -0700 (PDT) Received: by lucidpixels.com (Postfix, from userid 1001) id C81A75A564; Sun, 6 Jul 2008 06:31:41 -0400 (EDT) Date: Sun, 6 Jul 2008 06:31:41 -0400 (EDT) From: Justin Piszcz To: Robert Hancock cc: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, linux-ide@vger.kernel.org, xfs@oss.sgi.com, Alan Piszcz X-ASG-Orig-Subj: Re: Lots of con-current I/O = resets SATA link? (2.6.25.10) Subject: Re: Lots of con-current I/O = resets SATA link? (2.6.25.10) In-Reply-To: Message-ID: References: <486FBFAB.5050303@shaw.ca> <48700228.7060904@shaw.ca> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1215340303 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.1, rules version 3.1.55286 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16743 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Sat, 5 Jul 2008, Justin Piszcz wrote: > > > On Sat, 5 Jul 2008, Robert Hancock wrote: > >> Justin Piszcz wrote: >>>> Can you post your dmesg from bootup with the controller/drive detection? >> >> So you've got 6 drives in the machine. Intel chipsets normally seem pretty >> robust with AHCI. >> >> Are you certain that your machine has enough power to run all those drives >> properly? We've seen in a number of cases that power fluctuations or noise >> can cause these kinds of errors. > > I have a 650watt PSU (nice antec one) and the power draw of the box is > ~148watts w/ veliciraptors, ~250 when fully load all 4 cores + all 12 disks > writing. I have turned off the irqbalance daemon and I am going to see if > the problem re-occurs. > > Justin. > With IRQ balance turned off, it did not make any difference. This time I also left NCQ on (bad idea): And infact this time (w/NCQ enabled), it was so bad it dropped a disk from my RAID: (and later it dropped another disk when it was rebuilding (again, w/NCQ on), words of wisdom? do NOT use NCQ w/raptor disks)) md3 : active raid5 sdl1[9] sdk1[8] sdj1[7] sdi1[6] sdh1[5] sdg1[4] sdf1[10](F) sde1[2] sdd1[1] sdc1[0] 2637296640 blocks level 5, 1024k chunk, algorithm 2 [10/9] [UUU_UUUUUU] p34:~# fdisk -l /dev/sdf p34:~# [ 27.080281] EXT3 FS on md1, internal journal [ 27.080285] EXT3-fs: mounted filesystem with ordered data mode. [ 27.080631] Filesystem "md3": Disabling barriers, not supported by the underlying device [ 27.080762] XFS mounting filesystem md3 [ 27.231444] Ending clean XFS mount for filesystem: md3 [ 30.003809] e1000: eth1: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX [ 30.174956] e1000: eth2: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX [ 31.619294] eth0: Link is Up 1000 Mbps Full Duplex, Flow Control: RX/TX [ 35.112182] warning: `named' uses 32-bit capabilities (legacy support in use) [ 1842.570355] ata12.00: exception Emask 0x2 SAct 0x7 SErr 0x0 action 0x2 frozen [ 1842.570361] ata12.00: irq_stat 0x00060002, protocol mismatch [ 1842.570367] ata12.00: cmd 60/e0:00:3f:c8:1c/03:00:15:00:00/40 tag 0 ncq 507904 in [ 1842.570368] res 50/00:01:00:00:00/00:00:00:00:00/00 Emask 0x2 (HSM violation) [ 1842.570371] ata12.00: status: { DRDY } [ 1842.570376] ata12.00: cmd 60/e0:08:1f:cc:1c/03:00:15:00:00/40 tag 1 ncq 507904 in [ 1842.570377] res 50/00:01:00:00:00/00:00:00:00:00/00 Emask 0x2 (HSM violation) [ 1842.570380] ata12.00: status: { DRDY } [ 1842.570384] ata12.00: cmd 60/40:10:ff:cf:1c/00:00:15:00:00/40 tag 2 ncq 32768 in [ 1842.570385] res 50/00:01:00:00:00/00:00:00:00:00/00 Emask 0x2 (HSM violation) [ 1842.570387] ata12.00: status: { DRDY } [ 1842.570396] ata12: hard resetting link [ 1844.690631] ata12: softreset failed (SRST command error) [ 1844.690638] ata12: reset failed (errno=-5), retrying in 8 secs [ 1852.568418] ata12: hard resetting link [ 1854.700112] ata12: SATA link up 3.0 Gbps (SStatus 123 SControl 0) [ 1854.710188] ata12.00: configured for UDMA/100 [ 1854.710207] ata12: EH complete [ 1855.138782] sd 11:0:0:0: [sdl] 586072368 512-byte hardware sectors (300069 MB) [ 1855.138799] sd 11:0:0:0: [sdl] Write Protect is off [ 1855.138804] sd 11:0:0:0: [sdl] Mode Sense: 00 3a 00 00 [ 1855.138842] sd 11:0:0:0: [sdl] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 1931.593377] ata6.00: exception Emask 0x2 SAct 0x7fff SErr 0x3000400 action 0x2 frozen [ 1931.593386] ata6: SError: { Proto TrStaTrns UnrecFIS } [ 1931.593392] ata6.00: cmd 60/e0:00:3f:08:c8/03:00:20:00:00/40 tag 0 ncq 507904 in [ 1931.593393] res 40/00:28:ff:0f:e0/00:00:15:00:00/40 Emask 0x6 (timeout) [ 1931.593396] ata6.00: status: { DRDY } [ 1931.593400] ata6.00: cmd 60/e0:08:1f:0c:c8/03:00:20:00:00/40 tag 1 ncq 507904 in [ 1931.593402] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x6 (timeout) [ 1931.593404] ata6.00: status: { DRDY } [ 1931.593408] ata6.00: cmd 60/40:10:ff:0f:c8/00:00:20:00:00/40 tag 2 ncq 32768 in [ 1931.593409] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x6 (timeout) [ 1931.593412] ata6.00: status: { DRDY } [ 1931.593416] ata6.00: cmd 60/f8:18:3f:18:c8/00:00:20:00:00/40 tag 3 ncq 126976 in [ 1931.593417] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x6 (timeout) [ 1931.593420] ata6.00: status: { DRDY } [ 1931.593424] ata6.00: cmd 60/e0:20:37:19:c8/03:00:20:00:00/40 tag 4 ncq 507904 in [ 1931.593425] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x6 (timeout) [ 1931.593427] ata6.00: status: { DRDY } [ 1931.593431] ata6.00: cmd 60/28:28:17:1d:c8/03:00:20:00:00/40 tag 5 ncq 413696 in [ 1931.593433] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x6 (timeout) [ 1931.593437] ata6.00: status: { DRDY } [ 1931.593442] ata6.00: cmd 60/e0:30:3f:20:c8/03:00:20:00:00/40 tag 6 ncq 507904 in [ 1931.593443] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x6 (timeout) [ 1931.593447] ata6.00: status: { DRDY } [ 1931.593452] ata6.00: cmd 60/e0:38:1f:24:c8/03:00:20:00:00/40 tag 7 ncq 507904 in [ 1931.593453] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x6 (timeout) [ 1931.593457] ata6.00: status: { DRDY } [ 1931.593463] ata6.00: cmd 60/28:40:ff:27:c8/03:00:20:00:00/40 tag 8 ncq 413696 in [ 1931.593464] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x6 (timeout) [ 1931.593468] ata6.00: status: { DRDY } [ 1931.593473] ata6.00: cmd 60/f8:48:27:2b:c8/00:00:20:00:00/40 tag 9 ncq 126976 in [ 1931.593474] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x6 (timeout) [ 1931.593478] ata6.00: status: { DRDY } [ 1931.593483] ata6.00: cmd 60/e0:50:1f:2c:c8/03:00:20:00:00/40 tag 10 ncq 507904 in [ 1931.593485] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x6 (timeout) [ 1931.593489] ata6.00: status: { DRDY } [ 1931.593494] ata6.00: cmd 60/28:58:ff:2f:c8/03:00:20:00:00/40 tag 11 ncq 413696 in [ 1931.593495] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x6 (timeout) [ 1931.593499] ata6.00: status: { DRDY } [ 1931.593504] ata6.00: cmd 60/e0:60:27:33:c8/03:00:20:00:00/40 tag 12 ncq 507904 in [ 1931.593505] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x6 (timeout) [ 1931.593509] ata6.00: status: { DRDY } [ 1931.593514] ata6.00: cmd 60/f8:68:07:37:c8/00:00:20:00:00/40 tag 13 ncq 126976 in [ 1931.593516] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x6 (timeout) [ 1931.593520] ata6.00: status: { DRDY } [ 1931.593525] ata6.00: cmd 60/40:70:ff:37:c8/00:00:20:00:00/40 tag 14 ncq 32768 in [ 1931.593526] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x6 (timeout) [ 1931.593530] ata6.00: status: { DRDY } [ 1931.896320] ata6: soft resetting link [ 1937.097529] ata6: port is slow to respond, please be patient (Status 0xc0) [ 1941.941795] ata6: softreset failed (device not ready) [ 1941.941802] ata6: hard resetting link [ 1947.445957] ata6: port is slow to respond, please be patient (Status 0x80) [ 1951.984266] ata6: COMRESET failed (errno=-16) [ 1951.984272] ata6: hard resetting link [ 1957.488431] ata6: port is slow to respond, please be patient (Status 0x80) [ 1987.012943] ata6: COMRESET failed (errno=-16) [ 1987.012952] ata6: limiting SATA link speed to 1.5 Gbps [ 1987.012955] ata6: hard resetting link [ 1992.058175] ata6: COMRESET failed (errno=-16) [ 1992.058182] ata6: reset failed, giving up [ 1992.058187] ata6.00: disabled [ 1992.058240] ata6: EH complete [ 1992.058285] sd 5:0:0:0: [sdf] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK [ 1992.058292] end_request: I/O error, dev sdf, sector 549992447 [ 1992.058303] sd 5:0:0:0: [sdf] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK [ 1992.058305] end_request: I/O error, dev sdf, sector 549992199 [ 1992.058311] sd 5:0:0:0: [sdf] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK [ 1992.058313] end_request: I/O error, dev sdf, sector 549991207 [ 1992.058319] sd 5:0:0:0: [sdf] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK [ 1992.058321] end_request: I/O error, dev sdf, sector 549990399 [ 1992.058327] sd 5:0:0:0: [sdf] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK [ 1992.058329] end_request: I/O error, dev sdf, sector 549989407 [ 1992.058333] sd 5:0:0:0: [sdf] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK [ 1992.058335] end_request: I/O error, dev sdf, sector 549989159 [ 1992.058340] sd 5:0:0:0: [sdf] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK [ 1992.058342] end_request: I/O error, dev sdf, sector 549988351 [ 1992.058348] sd 5:0:0:0: [sdf] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK [ 1992.058350] end_request: I/O error, dev sdf, sector 549987359 [ 1992.058356] sd 5:0:0:0: [sdf] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK [ 1992.058358] end_request: I/O error, dev sdf, sector 549986367 [ 1992.058364] sd 5:0:0:0: [sdf] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK [ 1992.058366] end_request: I/O error, dev sdf, sector 549985559 [ 1992.058372] sd 5:0:0:0: [sdf] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK [ 1992.058374] end_request: I/O error, dev sdf, sector 549984567 [ 1992.058379] sd 5:0:0:0: [sdf] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK [ 1992.058383] end_request: I/O error, dev sdf, sector 549984319 [ 1992.058387] sd 5:0:0:0: [sdf] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK [ 1992.058391] end_request: I/O error, dev sdf, sector 549982207 [ 1992.058397] sd 5:0:0:0: [sdf] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK [ 1992.058402] end_request: I/O error, dev sdf, sector 549981215 [ 1992.058408] sd 5:0:0:0: [sdf] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK [ 1992.058412] end_request: I/O error, dev sdf, sector 549980223 [ 1992.058421] sd 5:0:0:0: [sdf] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK,SUGGEST_OK [ 1992.058425] end_request: I/O error, dev sdf, sector 586067135 [ 1992.058430] end_request: I/O error, dev sdf, sector 586067135 [ 1992.058434] md: super_written gets error=-5, uptodate=0 [ 1992.058437] raid5: Disk failure on sdf1, disabling device. Operation continuing on 9 devices [ 1991.645896] RAID5 conf printout: [ 1991.645903] --- rd:10 wd:9 [ 1991.645906] disk 0, o:1, dev:sdc1 [ 1991.645908] disk 1, o:1, dev:sdd1 [ 1991.645910] disk 2, o:1, dev:sde1 [ 1991.645912] disk 3, o:0, dev:sdf1 [ 1991.645914] disk 4, o:1, dev:sdg1 [ 1991.645916] disk 5, o:1, dev:sdh1 [ 1991.645918] disk 6, o:1, dev:sdi1 [ 1991.645920] disk 7, o:1, dev:sdj1 [ 1991.645922] disk 8, o:1, dev:sdk1 [ 1991.645923] disk 9, o:1, dev:sdl1 [ 1991.678270] RAID5 conf printout: [ 1991.678275] --- rd:10 wd:9 [ 1991.678278] disk 0, o:1, dev:sdc1 [ 1991.678280] disk 1, o:1, dev:sdd1 [ 1991.678282] disk 2, o:1, dev:sde1 [ 1991.678284] disk 4, o:1, dev:sdg1 [ 1991.678286] disk 5, o:1, dev:sdh1 [ 1991.678288] disk 6, o:1, dev:sdi1 [ 1991.678290] disk 7, o:1, dev:sdj1 [ 1991.678292] disk 8, o:1, dev:sdk1 [ 1991.678293] disk 9, o:1, dev:sdl1 [ 2053.744827] program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO Even after rebooting, the port was still 'hung' / having problems, I power cycled the host and it came up just fine, ran SMART tests too, no issues! # smartctl -a /dev/sdf smartctl version 5.38 [x86_64-unknown-linux-gnu] Copyright (C) 2002-8 Bruce Allen Home page is http://smartmontools.sourceforge.net/ === START OF INFORMATION SECTION === Device Model: WDC WD3000GLFS-01F8U0 Serial Number: ************** Firmware Version: 03.03V01 User Capacity: 300,069,052,416 bytes Device is: Not in smartctl database [for details use: -P showall] ATA Version is: 8 ATA Standard is: Exact ATA specification draft version not indicated Local Time is: Sun Jul 6 04:58:37 2008 EDT SMART support is: Available - device has SMART capability. SMART support is: Enabled .. etc No Errors Logged SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Short offline Completed without error 00% 705 - # 2 Extended offline Completed without error 00% 702 - # 3 Short offline Completed without error 00% 677 - # 4 Short offline Completed without error 00% 630 - # 5 Short offline Completed without error 00% 271 - I will try booting with the various options disabling APIC/ACPI/nolapic to see if it is possible to not get these errors/problems under heavy I/O: $ cat runtest.sh #!/bin/bash for i in `seq 0 20` do cd $i tar xf ../linux-2.6.25.10.tar & cd .. done -- In short, utilizing Raptors (especially veliciraptors)+NCQ on the ICH8 w/AHCI & other cards in a RAID 5 configuration is a death trap (a good way to lose your data), it appears unsafe to use NCQ w/raptors in a RAID 5 configuration. I've defaulted back to disabling it like I always do and my RAID5 is rebuilding now. After the rebuild is completed I will perform more testing. Justin. From owner-xfs@oss.sgi.com Sun Jul 6 03:43:28 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Jul 2008 03:43:29 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m66AhR8E013778 for ; Sun, 6 Jul 2008 03:43:27 -0700 X-ASG-Debug-ID: 1215341071-78c601d60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp-out002.kontent.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 39CD51882073 for ; Sun, 6 Jul 2008 03:44:31 -0700 (PDT) Received: from smtp-out002.kontent.com (smtp-out002.kontent.com [81.88.40.216]) by cuda.sgi.com with ESMTP id SBVX9VOjGAw0wrj1 for ; Sun, 06 Jul 2008 03:44:31 -0700 (PDT) Received: from lstyd.lan (p5B162542.dip0.t-ipconnect.de [91.22.37.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp-out.kontent.com (Postfix) with ESMTP id E53735986361; Sun, 6 Jul 2008 12:44:29 +0200 (CEST) Received: from [10.0.0.2] (para.lan [10.0.0.2]) by lstyd.lan (Postfix) with ESMTP id F357B207A4BA; Sun, 6 Jul 2008 12:44:26 +0200 (CEST) Message-ID: <4870A20C.7080802@theendofthetunnel.de> Date: Sun, 06 Jul 2008 12:44:28 +0200 From: Hannes Dorbath User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Alan Piszcz Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: Lots of con-current I/O = resets SATA link? (2.6.25.10) Subject: Re: Lots of con-current I/O = resets SATA link? (2.6.25.10) References: <486FBFAB.5050303@shaw.ca> <48700228.7060904@shaw.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: smtp-out002.kontent.com[81.88.40.216] X-Barracuda-Start-Time: 1215341072 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.1, rules version 3.1.55286 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16744 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: light@theendofthetunnel.de Precedence: bulk X-list: xfs Justin Piszcz wrote: > In short, utilizing Raptors (especially veliciraptors)+NCQ on the ICH8 > w/AHCI & other cards in a RAID 5 configuration is a death trap (a good > way to lose your data), it appears unsafe to use NCQ w/raptors in a RAID 5 > configuration. I've defaulted back to disabling it like I always do > and my RAID5 is rebuilding now. To my knowledge NCQ and Raptors is completely broken. Besides that, I have really bad experiences with the reliability of those drives. -- Best regards, Hannes Dorbath From owner-xfs@oss.sgi.com Sun Jul 6 05:11:58 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Jul 2008 05:12:01 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,RDNS_NONE autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com ([192.48.176.15]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m66CBvu9026375 for ; Sun, 6 Jul 2008 05:11:58 -0700 X-ASG-Debug-ID: 1215346380-78c203680000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3900F1882023 for ; Sun, 6 Jul 2008 05:13:00 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id PIx9q5kjpHAwonIm for ; Sun, 06 Jul 2008 05:13:00 -0700 (PDT) Received: by lucidpixels.com (Postfix, from userid 1001) id 718D219A76; Sun, 6 Jul 2008 08:13:00 -0400 (EDT) Date: Sun, 6 Jul 2008 08:13:00 -0400 (EDT) From: Justin Piszcz To: Robert Hancock cc: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, linux-ide@vger.kernel.org, xfs@oss.sgi.com, Alan Piszcz X-ASG-Orig-Subj: Re: Lots of con-current I/O = resets SATA link? (2.6.25.10) Subject: Re: Lots of con-current I/O = resets SATA link? (2.6.25.10) In-Reply-To: Message-ID: References: <486FBFAB.5050303@shaw.ca> <48700228.7060904@shaw.ca> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1215346381 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.1, rules version 3.1.55292 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16745 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Sun, 6 Jul 2008, Justin Piszcz wrote: > On Sat, 5 Jul 2008, Justin Piszcz wrote: >> On Sat, 5 Jul 2008, Robert Hancock wrote: > > In short, utilizing Raptors (especially veliciraptors)+NCQ on the ICH8 w/AHCI > & other cards in a RAID 5 configuration is a death trap (a good way to lose > your data), it appears unsafe to use NCQ w/raptors in a RAID 5 > configuration. I've defaulted back to disabling it like I always do > and my RAID5 is rebuilding now. > > After the rebuild is completed I will perform more testing. Running many parallel, tar, untar and copies of big fileskernel tarball and the kernel source tree) $ ps auxww | grep -c cp 437 $ ps auxww | grep -c tar 71 More than ~50k context switches.. procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- r b swpd free buff cache si so bi bo in cs us sy id wa 9 8 160 48092 160 6640044 0 0 524 21776 2264 50571 0 27 30 43 0 9 160 46572 160 6642572 0 0 220 22956 2032 45197 0 40 11 49 0 47 160 51424 160 6642800 0 0 0 22900 1799 39694 0 57 5 38 0 6 160 48916 160 6646272 0 0 112 23932 1763 41746 0 49 13 38 0 7 160 49316 160 6646192 0 0 0 25712 1513 37190 0 20 30 50 0 7 160 49240 160 6646264 0 0 0 28352 1853 38319 0 27 18 55 0 1 160 46652 160 6649688 0 0 548 22800 1933 34609 0 22 69 8 0 0 160 47032 160 6651108 0 0 2268 23652 1998 40729 0 22 56 22 1 0 160 47192 160 6651580 0 0 340 21220 1718 34293 1 17 60 23 This is with the "noapic" boot option and NCQ disabled. If there are no further errors I will reboot once more and re-run these tests without the "noapic" boot option and NCQ+irqbalance disabled as before I left NCQ enabled when irqbalance was disabled. Trying to find a pattern here but not having much luck. When all is said and done with over > 500 processes doing I/O with NCQ disabled and IRQ balance disabled w/noapic, I could not reproduce the problem. The problem here is look at the IRQ routing, nearly every device is on IRQ 11: $ cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 0: 100 0 0 0 XT-PIC-XT timer 1: 2 0 0 0 XT-PIC-XT i8042 2: 0 0 0 0 XT-PIC-XT cascade 8: 1 0 0 0 XT-PIC-XT rtc 9: 60454 0 0 0 XT-PIC-XT acpi, HDA Intel, eth2 10: 129911 0 0 0 XT-PIC-XT pata_marvell, uhci_hcd:usb4, eth1 11: 10278157 0 0 0 XT-PIC-XT sata_sil24, sata_sil24, sata_sil24, ohci1394, ehci_hcd:usb1, ehci_hcd:usb2, uhci_hcd:usb3, uhci_hcd:usb5, uhci_hcd:usb6, uhci_hcd:usb7, i915@pci:0000:00:02.0 12: 4 0 0 0 XT-PIC-XT i8042 377: 3027113 0 0 0 PCI-MSI-edge eth0 378: 9168537 0 0 0 PCI-MSI-edge ahci NMI: 0 0 0 0 Non-maskable interrupts LOC: 9832917 9837364 9833540 9842241 Local timer interrupts RES: 2313942 5729262 5207216 5776735 Rescheduling interrupts CAL: 24888 884 25272 25155 function call interrupts TLB: 7990 21120 23055 43247 TLB shootdowns TRM: 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 Threshold APIC interrupts SPU: 0 0 0 0 Spurious interrupts ERR: 0 Justin. From owner-xfs@oss.sgi.com Sun Jul 6 05:41:56 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Jul 2008 05:42:00 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_44 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m66Cfu9p029389 for ; Sun, 6 Jul 2008 05:41:56 -0700 X-ASG-Debug-ID: 1215348180-1831031e0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from lucidpixels.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D6CE32BDB93 for ; Sun, 6 Jul 2008 05:43:00 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id jkZzqKyEZvABOT2m for ; Sun, 06 Jul 2008 05:43:00 -0700 (PDT) Received: by lucidpixels.com (Postfix, from userid 1001) id BB67E32862; Sun, 6 Jul 2008 08:42:59 -0400 (EDT) Date: Sun, 6 Jul 2008 08:42:59 -0400 (EDT) From: Justin Piszcz To: Robert Hancock cc: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, linux-ide@vger.kernel.org, xfs@oss.sgi.com, Alan Piszcz X-ASG-Orig-Subj: Re: Lots of con-current I/O = resets SATA link? (2.6.25.10) Subject: Re: Lots of con-current I/O = resets SATA link? (2.6.25.10) In-Reply-To: Message-ID: References: <486FBFAB.5050303@shaw.ca> <48700228.7060904@shaw.ca> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: lucidpixels.com[75.144.35.66] X-Barracuda-Start-Time: 1215348180 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.1, rules version 3.1.55293 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Status: Clean X-archive-position: 16746 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jpiszcz@lucidpixels.com Precedence: bulk X-list: xfs On Sun, 6 Jul 2008, Justin Piszcz wrote: > On Sun, 6 Jul 2008, Justin Piszcz wrote: >> On Sat, 5 Jul 2008, Justin Piszcz wrote: >>> On Sat, 5 Jul 2008, Robert Hancock wrote: >> After the rebuild is completed I will perform more testing. The following setup is in-place: Kernel: 2.6.25.10 Boot options: none NCQ: disabled on all disks irqbalance: disabled/not running Removal of all old test data: $ for i in [0-9]*; do rm -rf $i & done .. [468] 5158 [469] 5159 [470] 5160 [471] 5161 [472] 5162 $ -- no problems yet -- run untar test+copy test: $ mkdir `seq 0 20` $ ./runtest.sh for i in `seq 0 20` do cd $i tar xf ../linux-2.6.25.10.tar & cd .. done for b in `seq 21 40` do cp linux-2.6.25.10.tar $b & done -- waiting for problems -- If no problems at the end of this test, will start up IRQ balance (how I normally ran my system) and re-test to see it is relegated to the irqbalance daemon running. ----------------------------- Success .. $ du -sh `seq 0 40` 311M 0 311M 1 311M 2 311M 3 311M 4 311M 5 311M 6 311M 7 311M 8 311M 9 311M 10 311M 11 311M 12 311M 13 311M 14 311M 15 311M 16 311M 17 311M 18 311M 19 311M 20 272M 21 272M 22 272M 23 272M 24 272M 25 272M 26 272M 27 272M 28 272M 29 272M 30 272M 31 272M 32 272M 33 272M 34 272M 35 272M 36 272M 37 272M 38 272M 39 272M 40 ----------------------------- .. no problems .. .. proceeded with test mentioned above .. Second round: The following setup is in-place: Kernel: 2.6.25.10 Boot options: none NCQ: disabled on all disks irqbalance: enabled -- Remove old cruft: $ for i in `seq 0 40` > do > rm -rf $i & > done Create new directories, re-run test: $ mkdir `seq 0 20` $ ./runtest.sh .. no problems either .. -- I do not have a method to reproduce the problem at will unfortunately. Justin. From owner-xfs@oss.sgi.com Sun Jul 6 10:23:04 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Jul 2008 10:23:11 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.0-r574664 (2007-09-11) on oss.sgi.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_31, J_CHICKENPOX_45 autolearn=no version=3.3.0-r574664 Received: from cuda.sgi.com (cuda2.sgi.com [192.48.168.29]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m66HN1pG024060 for ; Sun, 6 Jul 2008 10:23:04 -0700 X-ASG-Debug-ID: 1215365043-430000160000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from bby1mta03.pmc-sierra.bc.ca (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 597D22BE5C8 for ; Sun, 6 Jul 2008 10:24:03 -0700 (PDT) Received: from bby1mta03.pmc-sierra.bc.ca (bby1mta03.pmc-sierra.com [216.241.235.118]) by cuda.sgi.com with ESMTP id 4mdiisWqlEp9fTU7 for ; Sun, 06 Jul 2008 10:24:03 -0700 (PDT) Received: from bby1mta03.pmc-sierra.bc.ca (localhost.pmc-sierra.bc.ca [127.0.0.1]) by localhost (Postfix) with SMTP id 90D4D1070079; Sun, 6 Jul 2008 10:26:43 -0700 (PDT) Received: from bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca (BBY1EXG02.pmc-sierra.bc.ca [216.241.231.167]) by bby1mta03.pmc-sierra.bc.ca (Postfix) with SMTP id E429E107007D; Sun, 6 Jul 2008 10:26:40 -0700 (PDT) Received: from BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca ([216.241.231.156]) by bby1exg02.pmc_nt.nt.pmc-sierra.bc.ca with Microsoft SMTPSVC(6.0.3790.3959); Sun, 6 Jul 2008 10:24:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-ASG-Orig-Subj: RE: Xfs Access to block zero exception and system crash Subject: RE: Xfs Access to block zero exception and system crash Date: Sun, 6 Jul 2008 10:24:32 -0700 Message-ID: <340C71CD25A7EB49BFA81AE8C839266702A084A6@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> In-Reply-To: <486FA095.1050106@sandeen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Xfs Access to block zero exception and system crash Thread-Index: Acjeu+vnjBaNVLt7QAG//TmvR5I8jwAy4MaA References: <486B01A6.4030104@pmc-sierra.com> <20080702051337.GX29319@disturbed> <486B13AD.2010500@pmc-sierra.com> <1214979191.6025.22.camel@verge.scott.net.au> <20080702065652.GS14251@build-svl-1.agami.com> <486B6062.6040201@pmc-sierra.com> <486C4F89.9030009@sandeen.net> <486C6053.7010503@pmc-sierra.com> <486CE9EA.90502@sandeen.net> <486DF8F0.5010700@pmc-sierra.com> <20080704122726.GG29319@disturbed> <340C71CD25A7EB49BFA81AE8C839266702997641@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <486E5F4D.1010009@sandeen.net> <340C71CD25A7EB49BFA81AE8C839266702997658@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <486FA095.1050106@sandeen.net> From: "Sagar Borikar" To: "Eric Sandeen" Cc: "Dave Chinner" , "Nathan Scott" , X-OriginalArrivalTime: 06 Jul 2008 17:24:36.0559 (UTC) FILETIME=[29D