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=[29D9EDF0:01C8DF8D] X-PMX-Version: 5.4.2.338381, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.7.6.170557 X-PMC-SpamCheck: Gauge=IIIIIII, Probability=7%, Report='BODY_SIZE_10000_PLUS 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' X-Barracuda-Connect: bby1mta03.pmc-sierra.com[216.241.235.118] X-Barracuda-Start-Time: 1215365044 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.55313 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 m66HN4pG024064 X-archive-position: 16747 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 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. Sure Eric but I reran the test and I got similar errors with 2.6.24 kernel on x86. I am still confused with the results that I see on 2.6.24 kernel on x86 machine. I see that the used size shown by ls is way too huge than the actual size. Here is the log of the system [root@lab00 ~/test_partition]# ls -lSah total 202M -rw-r--r-- 1 root root 202M Jul 4 14:06 original ---> this I sthe file Which I copy. drwxr-x--- 65 root root 12K Jul 6 21:57 .. -rwxr-xr-x 1 root root 189 Jul 4 16:31 runall -rwxr-xr-x 1 root root 50 Jul 4 16:32 copy drwxr-xr-x 2 root root 45 Jul 6 22:07 . -------> Total size is roughly 202MB. [root@lab00 ~/test_partition]# df -lh . Filesystem Size Used Avail Use% Mounted on /mnt/xfstest 9.6G 7.7G 2.0G 80% /root/test_partition Size reported by df is 7.7G which is complete anomaly here. This is 10GB loopback partition and it mentions that only 2 GB is available. [root@lab00 ~/test_partition]# cat /etc/mtab /dev/mapper/VolGroup00-LogVol00 / ext3 rw 0 0 proc /proc proc rw 0 0 sysfs /sys sysfs rw 0 0 devpts /dev/pts devpts rw,gid=5,mode=620 0 0 /dev/sda1 /boot ext3 rw 0 0 tmpfs /dev/shm tmpfs rw 0 0 automount(pid3151) /net autofs rw,fd=4,pgrp=3151,minproto=2,maxproto=4 0 0 /mnt/xfstest /root/test_partition xfs rw,loop=/dev/loop0 0 0 ---> XFS partition. Here is the fragmentation result [root@lab00 ~/test_partition]# xfs_db -c frag -r /mnt/xfstest actual 7781, ideal 32, fragmentation factor 99.59% Here is the kernel version: [root@lab00 ~/test_partition]# uname -a Linux lab00 2.6.24 #1 SMP Fri Jul 4 12:20:56 IST 2008 i686 i686 i386 GNU/Linux 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. Surprising. I see it every time. I do it on 20 GB and 10GB partition on loopback device. When looked for the bad inode, Might also be worth checking dmesg for any errors when you run. dmesg log doesn't give any information. Here is XFS related info: XFS mounting filesystem loop0 Ending clean XFS mount for filesystem: loop0 Which is basically for mounting XFS cleanly. But there is no exception in XFS. Filesystem has become completely sluggish and response time is increased to 3-4 minutes for every command. Not a single copy is complete and all the copy processes are sleeping continuously. Xfs_repair starts reporting severe bugs: - agno = 1 entry "testfile" in shortform directory 16777472 references free inode 16777473 would have junked entry "testfile" in directory inode 16777472 - agno = 0 entry "testfile_3" at block 0 offset 664 in directory inode 128 references free inode 138 would clear inode number in entry at offset 664... entry "testfile_4" at block 0 offset 712 in directory inode 128 references free inode 140 would clear inode number in entry at offset 712... entry "testfile_5" at block 0 offset 760 in directory inode 128 references free inode 142 would clear inode number in entry at offset 760... entry "testfile_6" at block 0 offset 808 in directory inode 128 references free inode 143 would clear inode number in entry at offset 808... entry "testfile_7" at block 0 offset 856 in directory inode 128 references free inode 144 would clear inode number in entry at offset 856... entry "testfile_8" at block 0 offset 904 in directory inode 128 references free inode 146 would clear inode number in entry at offset 904... entry "testfile_9" at block 0 offset 952 in directory inode 128 references free inode 148 would clear inode number in entry at offset 952... entry "testfile_10" at block 0 offset 976 in directory inode 128 references free inode 149 would clear inode number in entry at offset 976... entry "testfile_12" at block 0 offset 1048 in directory inode 128 references free inode 150 would clear inode number in entry at offset 1048... entry "testfile_11" at block 0 offset 1072 in directory inode 128 references free inode 151 would clear inode number in entry at offset 1072... entry "testfile_13" at block 0 offset 1144 in directory inode 128 references free inode 154 data fork in ino 16777473 claims dup extent, off - 5266, start - 2164956, cnt 192 bad data fork in inode 16777473 would have cleared inode 16777473 entry "testfile" in shortform directory 16777474 references free inode 16777475 would have junked entry "testfile" in directory inode 16777474 would clear inode number in entry at offset 1144... entry "testfile_14" at block 0 offset 1168 in directory inode 128 references free inode 155 would clear inode number in entry at offset 1168... entry "testfile_15" at block 0 offset 1240 in directory inode 128 references free inode 156 would clear inode number in entry at offset 1240... entry "testfile_16" at block 0 offset 1264 in directory inode 128 references free inode 157 would clear inode number in entry at offset 1264... entry "testfile_17" at block 0 offset 1336 in directory inode 128 references free inode 160 would clear inode number in entry at offset 1336... entry "testfile_18" at block 0 offset 1360 in directory inode 128 references free inode 161 would clear inode number in entry at offset 1360... entry "testfile_19" at block 0 offset 1432 in directory inode 128 references free inode 162 would clear inode number in entry at offset 1432... entry "testfile_20" at block 0 offset 1456 in directory inode 128 references free inode 163 would clear inode number in entry at offset 1456... entry "testfile_2" at block 0 offset 3032 in directory inode 128 references free inode 137 would clear inode number in entry at offset 3032... data fork in ino 16777475 claims dup extent, off - 8178, start - 3200553, cnt 104 bad data fork in inode 16777475 would have cleared inode 16777475 entry "testfile" in shortform directory 16777476 references free inode 16777477 would have junked entry "testfile" in directory inode 16777476 data fork in ino 16777477 claims dup extent, off - 9402, start - 3221565, cnt 56 bad data fork in inode 16777477 would have cleared inode 16777477 entry "testfile" in shortform directory 16777478 references free inode 16777479 would have junked entry "testfile" in directory inode 16777478 data fork in ino 16777479 claims dup extent, off - 9586, start - 170361, cnt 96 bad data fork in inode 16777479 would have cleared inode 16777479 entry "testfile" in shortform directory 16777480 references free inode 16777481 would have junked entry "testfile" in directory inode 16777480 data fork in ino 16777481 claims dup extent, off - 8338, start - 3203018, cnt 128 bad data fork in inode 16777481 would have cleared inode 16777481 - agno = 2 entry "testfile" in shortform directory 33595712 references free inode 33595713 would have junked entry "testfile" in directory inode 33595712 bad data fork in inode 33595713 would have cleared inode 33595713 entry "testfile" in shortform directory 33595714 references free inode 33595715 would have junked entry "testfile" in directory inode 33595714 imap claims in-use inode 33595715 is free, correcting imap entry "testfile" in shortform directory 33595716 references free inode 33595717 would have junked entry "testfile" in directory inode 33595716 data fork in ino 33595717 claims dup extent, off - 0, start - 3281880, cnt 6180 bad data fork in inode 33595717 would have cleared inode 33595717 entry "testfile" in shortform directory 33595718 references free inode 33595719 would have junked entry "testfile" in directory inode 33595718 bad data fork in inode 33595719 would have cleared inode 33595719 entry "testfile" in shortform directory 33595720 references free inode 33595721 would have junked entry "testfile" in directory inode 33595720 bad data fork in inode 33595721 would have cleared inode 33595721 - agno = 3 entry "testfile" in shortform directory 50331904 references free inode 50331905 would have junked entry "testfile" in directory inode 50331904 bad data fork in inode 50331905 would have cleared inode 50331905 entry "testfile" in shortform directory 50331906 references free inode 50331907 would have junked entry "testfile" in directory inode 50331906 data fork in ino 50331907 claims dup extent, off - 609, start - 3151886, cnt 311 bad data fork in inode 50331907 would have cleared inode 50331907 entry "testfile" in shortform directory 50331908 references free inode 50331909 would have junked entry "testfile" in directory inode 50331908 imap claims in-use inode 50331909 is free, correcting imap entry "testfile" in shortform directory 50331910 references free inode 50331911 would have junked entry "testfile" in directory inode 50331910 bad data fork in inode 50331911 would have cleared inode 50331911 entry "testfile" in shortform directory 50331912 references free inode 50331913 would have junked entry "testfile" in directory inode 50331912 data fork in ino 50331913 claims dup extent, off - 6358, start - 3224389, cnt 469 bad data fork in inode 50331913 would have cleared inode 50331913 data fork in regular inode 133 claims used block 1075592 would have cleared inode 133 data fork in regular inode 136 claims used block 1075930 would have cleared inode 136 data fork in regular inode 137 claims used block 2162044 would have cleared inode 137 data fork in regular inode 138 claims used block 1075938 would have cleared inode 138 entry "testfile" in shortform directory 139 references free inode 141 would have junked entry "testfile" in directory inode 139 data fork in ino 140 claims dup extent, off - 12298, start - 202587, cnt 30 bad data fork in inode 140 would have cleared inode 140 data fork in ino 141 claims dup extent, off - 8562, start - 160071, cnt 384 bad data fork in inode 141 would have cleared inode 141 data fork in ino 142 claims dup extent, off - 1458, start - 80521, cnt 32 bad data fork in inode 142 would have cleared inode 142 data fork in ino 143 claims dup extent, off - 13770, start - 235117, cnt 96 bad data fork in inode 143 would have cleared inode 143 bad magic # 0 in inode 144 (data fork) bmbt block 3262925 bad data fork in inode 144 would have cleared inode 144 entry "testfile" in shortform directory 145 references free inode 147 would have junked entry "testfile" in directory inode 145 data fork in ino 146 claims dup extent, off - 8082, start - 138272, cnt 32 bad data fork in inode 146 would have cleared inode 146 data fork in regular inode 147 claims used block 1075759 would have cleared inode 147 data fork in regular inode 148 claims used block 3231076 would have cleared inode 148 data fork in ino 149 claims dup extent, off - 9426, start - 168635, cnt 8 bad data fork in inode 149 would have cleared inode 149 data fork in ino 150 claims dup extent, off - 3607, start - 105990, cnt 59 bad data fork in inode 150 would have cleared inode 150 data fork in regular inode 151 claims used block 1076476 would have cleared inode 151 entry "testfile" in shortform directory 152 references free inode 153 would have junked entry "testfile" in directory inode 152 bad magic # 0 in inode 153 (data fork) bmbt block 3271407 bad data fork in inode 153 would have cleared inode 153 data fork in regular inode 154 claims used block 1076388 would have cleared inode 154 data fork in regular inode 155 claims used block 1076068 would have cleared inode 155 data fork in regular inode 156 claims used block 3224002 would have cleared inode 156 data fork in ino 157 claims dup extent, off - 9554, start - 170265, cnt 96 bad data fork in inode 157 would have cleared inode 157 entry "testfile" in shortform directory 158 references free inode 159 would have junked entry "testfile" in directory inode 158 data fork in regular inode 159 claims used block 1076564 would have cleared inode 159 data fork in ino 160 claims dup extent, off - 9394, start - 168489, cnt 8 bad data fork in inode 160 would have cleared inode 160 data fork in ino 161 claims dup extent, off - 14662, start - 253175, cnt 32 bad data fork in inode 161 would have cleared inode 161 data fork in regular inode 162 claims used block 2209542 would have cleared inode 162 bad magic # 0 in inode 163 (data fork) bmbt block 3270098 bad data fork in inode 163 would have cleared inode 163 No modify flag set, skipping phase 5 Phase 6 - check inode connectivity... - traversing filesystem ... - agno = 0 entry "testfile_3" in directory inode 128 points to free inode 138, would junk entry entry "testfile_4" in directory inode 128 points to free inode 140, would junk entry entry "testfile_5" in directory inode 128 points to free inode 142, would junk entry entry "testfile_6" in directory inode 128 points to free inode 143, would junk entry entry "testfile_7" in directory inode 128 points to free inode 144, would junk entry entry "testfile_8" in directory inode 128 points to free inode 146, would junk entry entry "testfile_9" in directory inode 128 points to free inode 148, would junk entry entry "testfile_10" in directory inode 128 points to free inode 149, would junk entry entry "testfile_12" in directory inode 128 points to free inode 150, would junk entry entry "testfile_11" in directory inode 128 points to free inode 151, would junk entry entry "testfile_13" in directory inode 128 points to free inode 154, would junk entry entry "testfile_14" in directory inode 128 points to free inode 155, would junk entry entry "testfile_15" in directory inode 128 points to free inode 156, would junk entry entry "testfile_16" in directory inode 128 points to free inode 157, would junk entry entry "testfile_17" in directory inode 128 points to free inode 160, would junk entry entry "testfile_18" in directory inode 128 points to free inode 161, would junk entry entry "testfile_19" in directory inode 128 points to free inode 162, would junk entry entry "testfile_20" in directory inode 128 points to free inode 163, would junk entry entry "testfile_1" in directory inode 128 points to free inode 136, would junk entry entry "testfile_2" in directory inode 128 points to free inode 137, would junk entry bad hash table for directory inode 128 (no data entry): would rebuild entry "testfile" in shortform directory inode 132 points to free inode 133would junk entry entry "testfile" in shortform directory inode 139 points to free inode 141would junk entry entry "testfile" in shortform directory inode 145 points to free inode 147would junk entry entry "testfile" in shortform directory inode 152 points to free inode 153would junk entry entry "testfile" in shortform directory inode 158 points to free inode 159would junk entry - agno = 1 entry "testfile" in shortform directory inode 16777472 points to free inode 16777473would junk entry entry "testfile" in shortform directory inode 16777474 points to free inode 16777475would junk entry entry "testfile" in shortform directory inode 16777476 points to free inode 16777477would junk entry entry "testfile" in shortform directory inode 16777478 points to free inode 16777479would junk entry entry "testfile" in shortform directory inode 16777480 points to free inode 16777481would junk entry - agno = 2 entry "testfile" in shortform directory inode 33595712 points to free inode 33595713would junk entry entry "testfile" in shortform directory inode 33595716 points to free inode 33595717would junk entry entry "testfile" in shortform directory inode 33595718 points to free inode 33595719would junk entry entry "testfile" in shortform directory inode 33595720 points to free inode 33595721would junk entry - agno = 3 entry "testfile" in shortform directory inode 50331904 points to free inode 50331905would junk entry entry "testfile" in shortform directory inode 50331906 points to free inode 50331907would junk entry entry "testfile" in shortform directory inode 50331910 points to free inode 50331911would junk entry entry "testfile" in shortform directory inode 50331912 points to free inode 50331913would junk entry - 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 Sun Jul 6 22:43:36 2008 Phase Start End Duration Phase 1: 07/06 22:39:18 07/06 22:39:33 15 seconds Phase 2: 07/06 22:39:33 07/06 22:41:47 2 minutes, 14 seconds Phase 3: 07/06 22:41:47 07/06 22:43:15 1 minute, 28 seconds Phase 4: 07/06 22:43:15 07/06 22:43:36 21 seconds Phase 5: Skipped Phase 6: 07/06 22:43:36 07/06 22:43:36 Phase 7: 07/06 22:43:36 07/06 22:43:36 Total run time: 4 minutes, 18 seconds When checked for bad inode in xfs_db, then the parent inode was shown as -1 I presume it should point to right parent directory inode. 1: byte offset 2560065792, length 256 buffer block 5000128 (fsbno 1048592), 8 bbs inode 16777473, dir inode -1, type inode I don't know what I am doing wrong here. Sagar From owner-xfs@oss.sgi.com Sun Jul 6 12:06:38 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Jul 2008 12:06: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,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 m66J6cvs000435 for ; Sun, 6 Jul 2008 12:06:38 -0700 X-ASG-Debug-ID: 1215371262-50c4016a0000-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 AC0891882A88 for ; Sun, 6 Jul 2008 12:07:42 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id m6ykREfWzWX7UD6S for ; Sun, 06 Jul 2008 12:07:42 -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 15F18AC626B; Sun, 6 Jul 2008 14:07:41 -0500 (CDT) Message-ID: <487117FC.9090109@sandeen.net> Date: Sun, 06 Jul 2008 14:07:40 -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> <486FA095.1050106@sandeen.net> <340C71CD25A7EB49BFA81AE8C839266702A084A6@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> In-Reply-To: <340C71CD25A7EB49BFA81AE8C839266702A084A6@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: 1215371262 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.55319 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: 16748 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: > 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. > > Sure Eric but I reran the test and I got similar errors with > 2.6.24 kernel on x86. I am still confused with the results that I see on > 2.6.24 kernel on x86 machine. I see that the used size shown by ls is > way too huge than the actual size. Here is the log of the system > > [root@lab00 ~/test_partition]# ls -lSah > total 202M > -rw-r--r-- 1 root root 202M Jul 4 14:06 original ---> this I sthe file > Which I copy. > drwxr-x--- 65 root root 12K Jul 6 21:57 .. > -rwxr-xr-x 1 root root 189 Jul 4 16:31 runall > -rwxr-xr-x 1 root root 50 Jul 4 16:32 copy > drwxr-xr-x 2 root root 45 Jul 6 22:07 . It'd be great if you provided these actual scripts so we don't have to guess at what you're doing or work backwards from the repair output :) > dmesg log doesn't give any information. Here is XFS related > info: > > XFS mounting filesystem loop0 > Ending clean XFS mount for filesystem: loop0 > Which is basically for mounting XFS cleanly. But there is no exception > in XFS. and nothing else of interest either? > Filesystem has become completely sluggish and response time is increased > to > 3-4 minutes for every command. Not a single copy is complete and all > the copy processes are sleeping continuously. And how did you recover from this; did you power-cycle the box? -Eric From owner-xfs@oss.sgi.com Sun Jul 6 12:49:59 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Jul 2008 12:50: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=-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 m66JnwnY009553 for ; Sun, 6 Jul 2008 12:49:59 -0700 X-ASG-Debug-ID: 1215373861-731101600000-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 3A966C35A83 for ; Sun, 6 Jul 2008 12:51:01 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id g7Ey8MJKqQTu2SWb for ; Sun, 06 Jul 2008 12:51:01 -0700 (PDT) Received: by lucidpixels.com (Postfix, from userid 1001) id 197555A56D; Sun, 6 Jul 2008 15:51:01 -0400 (EDT) Date: Sun, 6 Jul 2008 15:51:01 -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: 1215373863 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.55321 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: 16749 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 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. As more or less of a last-ditch effort, I replaced all 12 SATA cables. Will see if/when the problem happens again. Justin. From owner-xfs@oss.sgi.com Sun Jul 6 16:52:15 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Jul 2008 16:52:38 -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 m66NqEGl000777 for ; Sun, 6 Jul 2008 16:52:15 -0700 X-ASG-Debug-ID: 1215388398-574400230000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp.sauce.co.nz (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 841C011DBF4F for ; Sun, 6 Jul 2008 16:53:18 -0700 (PDT) Received: from smtp.sauce.co.nz (smtp.sauce.co.nz [210.48.49.72]) by cuda.sgi.com with ESMTP id lZEoFBWDFqPJUVZG for ; Sun, 06 Jul 2008 16:53:18 -0700 (PDT) Received: (qmail 17559 invoked from network); 6 Jul 2008 23:53:17 -0000 Received: from unknown (HELO ?192.168.4.111?) (192.168.4.111) by smtp.sauce.co.nz with (DHE-RSA-AES256-SHA encrypted) SMTP; 6 Jul 2008 23:53:17 -0000 Message-ID: <48715CEF.8010008@sauce.co.nz> Date: Mon, 07 Jul 2008 12:01:51 +1200 From: Richard Scobie User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: xfs@oss.sgi.com X-ASG-Orig-Subj: XFS Recovery Subject: XFS Recovery Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: smtp.sauce.co.nz[210.48.49.72] X-Barracuda-Start-Time: 1215388399 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4676 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.55338 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: 16750 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: richard@sauce.co.nz Precedence: bulk X-list: xfs If the following log entry appears after mounting an XFS fs, is it safe to assume that whatever issue initiated the recovery has been repaired, or is further checking/repair required? XFS mounting filesystem md5 Starting XFS recovery on filesystem: md5 (logdev: /dev/md0) Ending XFS recovery on filesystem: md5 (logdev: /dev/md0) Regards, Richard From owner-xfs@oss.sgi.com Sun Jul 6 17:06:46 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Jul 2008 17:06:48 -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 (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 m6706kLj002298 for ; Sun, 6 Jul 2008 17:06:46 -0700 X-ASG-Debug-ID: 1215389269-252d03830000-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 3873B2BEF58 for ; Sun, 6 Jul 2008 17:07:49 -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 mAfCr5HXUf2BAMQG for ; Sun, 06 Jul 2008 17:07:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAE/6cEh5LBzp/2dsb2JhbACtMg X-IronPort-AV: E=Sophos;i="4.30,312,1212330600"; d="scan'208";a="143213053" 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; 07 Jul 2008 09:37:47 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KFeGf-0001Ow-RG; Mon, 07 Jul 2008 10:07:45 +1000 Date: Mon, 7 Jul 2008 10:07:45 +1000 From: Dave Chinner To: Richard Scobie Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS Recovery Subject: Re: XFS Recovery Message-ID: <20080707000745.GI29319@disturbed> Mail-Followup-To: Richard Scobie , xfs@oss.sgi.com References: <48715CEF.8010008@sauce.co.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48715CEF.8010008@sauce.co.nz> 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: 1215389271 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4745 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.55339 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: 16751 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 Mon, Jul 07, 2008 at 12:01:51PM +1200, Richard Scobie wrote: > If the following log entry appears after mounting an XFS fs, is it safe > to assume that whatever issue initiated the recovery has been repaired, > or is further checking/repair required? No. > XFS mounting filesystem md5 > Starting XFS recovery on filesystem: md5 (logdev: /dev/md0) > Ending XFS recovery on filesystem: md5 (logdev: /dev/md0) That's normal output when mounting an XFS filesystem - if you see more than this then there might be problems... Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Sun Jul 6 18:13:18 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Jul 2008 18:13: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=-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 m671DHaY007140 for ; Sun, 6 Jul 2008 18:13:18 -0700 X-ASG-Debug-ID: 1215393261-5745035b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from smtp.sauce.co.nz (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 22A4611DC4BB for ; Sun, 6 Jul 2008 18:14:21 -0700 (PDT) Received: from smtp.sauce.co.nz (smtp.sauce.co.nz [210.48.49.72]) by cuda.sgi.com with ESMTP id V5z1fv5VKvJt0dVK for ; Sun, 06 Jul 2008 18:14:21 -0700 (PDT) Received: (qmail 18355 invoked from network); 7 Jul 2008 01:14:19 -0000 Received: from unknown (HELO ?192.168.4.111?) (192.168.4.111) by smtp.sauce.co.nz with (DHE-RSA-AES256-SHA encrypted) SMTP; 7 Jul 2008 01:14:19 -0000 Message-ID: <48716FEE.7070806@sauce.co.nz> Date: Mon, 07 Jul 2008 13:22:54 +1200 From: Richard Scobie User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040805 Netscape/7.2 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dave Chinner CC: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS Recovery Subject: Re: XFS Recovery References: <48715CEF.8010008@sauce.co.nz> <20080707000745.GI29319@disturbed> In-Reply-To: <20080707000745.GI29319@disturbed> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Barracuda-Connect: smtp.sauce.co.nz[210.48.49.72] X-Barracuda-Start-Time: 1215393262 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0323 1.0000 -1.8119 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.81 X-Barracuda-Spam-Status: No, SCORE=-1.81 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.55344 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: 16752 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: richard@sauce.co.nz Precedence: bulk X-list: xfs Dave Chinner wrote: >>XFS mounting filesystem md5 >>Starting XFS recovery on filesystem: md5 (logdev: /dev/md0) >>Ending XFS recovery on filesystem: md5 (logdev: /dev/md0) > > > That's normal output when mounting an XFS filesystem - if > you see more than this then there might be problems... Thanks Dave, I was more used to seeing: XFS mounting filesystem md5 Ending clean XFS mount for filesystem: md5 Maybe the message has changed with later kernels. In any case, it sounds like I have no issues. Regards, Richard From owner-xfs@oss.sgi.com Sun Jul 6 18:29:19 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Jul 2008 18:29: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.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 m671TGIs008843 for ; Sun, 6 Jul 2008 18:29:18 -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 LAA13666; Mon, 7 Jul 2008 11:30:15 +1000 Message-ID: <487171A7.4070602@sgi.com> Date: Mon, 07 Jul 2008 11:30:15 +1000 From: Timothy Shimmin User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Richard Scobie , xfs@oss.sgi.com Subject: Re: XFS Recovery References: <48715CEF.8010008@sauce.co.nz> <20080707000745.GI29319@disturbed> In-Reply-To: <20080707000745.GI29319@disturbed> 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: 16753 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 Dave Chinner wrote: > On Mon, Jul 07, 2008 at 12:01:51PM +1200, Richard Scobie wrote: >> If the following log entry appears after mounting an XFS fs, is it safe >> to assume that whatever issue initiated the recovery has been repaired, >> or is further checking/repair required? > > No. > >> XFS mounting filesystem md5 >> Starting XFS recovery on filesystem: md5 (logdev: /dev/md0) >> Ending XFS recovery on filesystem: md5 (logdev: /dev/md0) > > That's normal output when mounting an XFS filesystem - if > you see more than this then there might be problems... > Hmmm....I don't know if I would describe that as "normal" unless I am misunderstanding Dave here. There has been some recovery happening indicating that there wasn't a clean unmount (it didn't find an unmount record in the log). But recovery should have replayed the outstanding metadata to a time point in the near past and so no repair should be necessary (we have qa tests which do the test anyway and check that there are no complaints). --Tim From owner-xfs@oss.sgi.com Sun Jul 6 18:55:14 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Jul 2008 18:55:16 -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 m671tE6a012756 for ; Sun, 6 Jul 2008 18:55:14 -0700 X-ASG-Debug-ID: 1215395778-6a8100e90000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from web34505.mail.mud.yahoo.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 0080E1883A2F for ; Sun, 6 Jul 2008 18:56:18 -0700 (PDT) Received: from web34505.mail.mud.yahoo.com (web34505.mail.mud.yahoo.com [66.163.178.171]) by cuda.sgi.com with SMTP id vxZYGierty2RqhUc for ; Sun, 06 Jul 2008 18:56:18 -0700 (PDT) Received: (qmail 7481 invoked by uid 60001); 7 Jul 2008 01:56:17 -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=N1qE0OV6szutRoWT2jCgUzoG59lboCrpsSZ15GkdbL0623K/mLCV3Iph5S91icNZYYpYnezLg7bp/EHpBT1YjNUE/njGvQ97bDJmfwepLllvMEHOU2/mzU1ktFMP1uyZlMRdWMpu8176iUC4y/cYGudTe08SFb/8tS2paloTKmI=; Received: from [96.14.131.125] by web34505.mail.mud.yahoo.com via HTTP; Sun, 06 Jul 2008 18:56:17 PDT X-Mailer: YahooMailWebService/0.7.199 Date: Sun, 6 Jul 2008 18:56:17 -0700 (PDT) From: Mark Reply-To: MusicMan529@yahoo.com X-ASG-Orig-Subj: Re: XFS Recovery Subject: Re: XFS Recovery To: xfs@oss.sgi.com In-Reply-To: <487171A7.4070602@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <719163.7411.qm@web34505.mail.mud.yahoo.com> X-Barracuda-Connect: web34505.mail.mud.yahoo.com[66.163.178.171] X-Barracuda-Start-Time: 1215395779 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4676 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.55346 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: 16754 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 Sun, 7/6/08, Timothy Shimmin wrote: > >> XFS mounting filesystem md5 > >> Starting XFS recovery on filesystem: md5 (logdev: > /dev/md0) > >> Ending XFS recovery on filesystem: md5 (logdev: > /dev/md0) > > > > That's normal output when mounting an XFS > filesystem - if > > you see more than this then there might be problems... > > > Hmmm....I don't know if I would describe that as > "normal" > unless I am misunderstanding Dave here. > There has been some recovery happening indicating that > there > wasn't a clean unmount (it didn't find an unmount > record in the log). > But recovery should have replayed the > outstanding metadata to a time point in the near past > and so no repair should be necessary (we have qa tests > which do the > test anyway and check that there are no complaints). Maybe not "normal," but at least "acceptable"? If it's a regular occurrence, it might be worth looking into. If it was a one-off, with no further complaints, I'd ignore it. -- 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 Sun Jul 6 19:05:39 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Jul 2008 19:05: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 (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 m6725cIB014573 for ; Sun, 6 Jul 2008 19:05:38 -0700 X-ASG-Debug-ID: 1215396401-5ed1005a0000-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 791F32BF661 for ; Sun, 6 Jul 2008 19:06: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 3TD2qvSXwizt8vSB for ; Sun, 06 Jul 2008 19:06:42 -0700 (PDT) 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; 07 Jul 2008 11:35:51 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KFg64-0005hP-J5; Mon, 07 Jul 2008 12:04:56 +1000 Date: Mon, 7 Jul 2008 12:04:56 +1000 From: Dave Chinner To: Timothy Shimmin Cc: Richard Scobie , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: XFS Recovery Subject: Re: XFS Recovery Message-ID: <20080707020456.GJ29319@disturbed> Mail-Followup-To: Timothy Shimmin , Richard Scobie , xfs@oss.sgi.com References: <48715CEF.8010008@sauce.co.nz> <20080707000745.GI29319@disturbed> <487171A7.4070602@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <487171A7.4070602@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: 1215396403 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3753 1.0000 -0.0690 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.07 X-Barracuda-Spam-Status: No, SCORE=-0.07 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.55346 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: 16755 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 Mon, Jul 07, 2008 at 11:30:15AM +1000, Timothy Shimmin wrote: > Dave Chinner wrote: > > On Mon, Jul 07, 2008 at 12:01:51PM +1200, Richard Scobie wrote: > >> If the following log entry appears after mounting an XFS fs, is it safe > >> to assume that whatever issue initiated the recovery has been repaired, > >> or is further checking/repair required? > > > > No. > > > >> XFS mounting filesystem md5 > >> Starting XFS recovery on filesystem: md5 (logdev: /dev/md0) > >> Ending XFS recovery on filesystem: md5 (logdev: /dev/md0) > > > > That's normal output when mounting an XFS filesystem - if > > you see more than this then there might be problems... > > > Hmmm....I don't know if I would describe that as "normal" > unless I am misunderstanding Dave here. Normal as in "everything is OK - there's no need to worry". Recovery at mount time happens quite frequently for a variety of reasons - it's not a sign that there's something wrong as such.... Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Sun Jul 6 20:01:06 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Jul 2008 20:01: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.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 m673153Q022247 for ; Sun, 6 Jul 2008 20:01:06 -0700 X-ASG-Debug-ID: 1215399729-30b303190000-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 031CD11DD0A5 for ; Sun, 6 Jul 2008 20:02:09 -0700 (PDT) Received: from bby1mta03.pmc-sierra.bc.ca (bby1mta03.pmc-sierra.com [216.241.235.118]) by cuda.sgi.com with ESMTP id nOZv9jkLuVXAvpZa for ; Sun, 06 Jul 2008 20:02:09 -0700 (PDT) Received: from bby1mta03.pmc-sierra.bc.ca (localhost.pmc-sierra.bc.ca [127.0.0.1]) by localhost (Postfix) with SMTP id DEC3A1070088; Sun, 6 Jul 2008 20:04:52 -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 7AE401070071; Sun, 6 Jul 2008 20:04:50 -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 20:02:45 -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); Sun, 6 Jul 2008 20:02:44 -0700 Message-ID: <4871872B.9060107@pmc-sierra.com> Date: Mon, 07 Jul 2008 08:32:03 +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: 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> <486FA095.1050106@sandeen.net> <340C71CD25A7EB49BFA81AE8C839266702A084A6@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <487117FC.9090109@sandeen.net> In-Reply-To: <487117FC.9090109@sandeen.net> Content-Type: multipart/mixed; boundary="------------080806010108010907030600" X-OriginalArrivalTime: 07 Jul 2008 03:02:45.0222 (UTC) FILETIME=[EDE7D860:01C8DFDD] X-PMX-Version: 5.4.2.338381, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.7.7.24612 X-PMC-SpamCheck: Gauge=IIIIIII, Probability=7%, Report='BODY_SIZE_3000_3999 0, BODY_SIZE_5000_LESS 0, __BAT_BOUNDARY 0, __BOUNCE_CHALLENGE_SUBJ 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __HAS_MSGID 0, __KNOWN_PHONE_RU_MOSCOW_CELL 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __RUS_OBFU_PHONE 0, __SANE_MSGID 0, __STOCK_PHRASE_7 0, __USER_AGENT 0' X-Barracuda-Connect: bby1mta03.pmc-sierra.com[216.241.235.118] X-Barracuda-Start-Time: 1215399730 X-Barracuda-Bayes: INNOCENT GLOBAL 0.2127 1.0000 -0.7614 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.76 X-Barracuda-Spam-Status: No, SCORE=-0.76 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.55350 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: 16756 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. --------------080806010108010907030600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eric Sandeen wrote: > Sagar Borikar wrote: > >> 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. >> >> Sure Eric but I reran the test and I got similar errors with >> 2.6.24 kernel on x86. I am still confused with the results that I see on >> 2.6.24 kernel on x86 machine. I see that the used size shown by ls is >> way too huge than the actual size. Here is the log of the system >> >> [root@lab00 ~/test_partition]# ls -lSah >> total 202M >> -rw-r--r-- 1 root root 202M Jul 4 14:06 original ---> this I sthe file >> Which I copy. >> drwxr-x--- 65 root root 12K Jul 6 21:57 .. >> -rwxr-xr-x 1 root root 189 Jul 4 16:31 runall >> -rwxr-xr-x 1 root root 50 Jul 4 16:32 copy >> drwxr-xr-x 2 root root 45 Jul 6 22:07 . >> > > It'd be great if you provided these actual scripts so we don't have to > guess at what you're doing or work backwards from the repair output :) > Attaching the scripts with this mail. > >> dmesg log doesn't give any information. Here is XFS related >> info: >> >> XFS mounting filesystem loop0 >> Ending clean XFS mount for filesystem: loop0 >> Which is basically for mounting XFS cleanly. But there is no exception >> in XFS. >> > > and nothing else of interest either? > Not really. That's why it was surprising. Even after setting the error_level to 11 > >> Filesystem has become completely sluggish and response time is increased >> to >> 3-4 minutes for every command. Not a single copy is complete and all >> the copy processes are sleeping continuously. >> > > And how did you recover from this; did you power-cycle the box? > There was no failure. Only the processes were stalled. System was operative. > -Eric > --------------080806010108010907030600 Content-Type: text/plain; name="copy" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="copy" #! /bin/sh while [ 1 ] do cp -f $1 $2 done --------------080806010108010907030600 Content-Type: text/plain; name="runall" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="runall" #! /bin/sh for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 do mkdir -p testdir_$i ./copy testfile testdir_$i & rm -Rf testdir_$1/testfile ./copy testfile testfile_$i & done --------------080806010108010907030600-- From owner-xfs@oss.sgi.com Sun Jul 6 20:03:47 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Jul 2008 20:03:48 -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 m6733l2A022678 for ; Sun, 6 Jul 2008 20:03:47 -0700 X-ASG-Debug-ID: 1215399891-05f102760000-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 B04E71883F1D for ; Sun, 6 Jul 2008 20:04:51 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id SbhyuS47PCUNvXKL for ; Sun, 06 Jul 2008 20:04:51 -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 D9CD7AC626B; Sun, 6 Jul 2008 22:04:50 -0500 (CDT) Message-ID: <487187D2.8080105@sandeen.net> Date: Sun, 06 Jul 2008 22:04:50 -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> <486FA095.1050106@sandeen.net> <340C71CD25A7EB49BFA81AE8C839266702A084A6@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <487117FC.9090109@sandeen.net> <4871872B.9060107@pmc-sierra.com> In-Reply-To: <4871872B.9060107@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: 1215399891 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.55350 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: 16757 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: > There was no failure. Only the processes were stalled. System was > operative. I'm curious, if the processes were stalled, how did you unmount the filesystem to run repair on it? -Eric From owner-xfs@oss.sgi.com Sun Jul 6 20:06:07 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Jul 2008 20:06: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.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 m67367GD023116 for ; Sun, 6 Jul 2008 20:06:07 -0700 X-ASG-Debug-ID: 1215400031-6a81033d0000-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 546EA1883F98 for ; Sun, 6 Jul 2008 20:07:11 -0700 (PDT) Received: from bby1mta02.pmc-sierra.bc.ca (bby1mta02.pmc-sierra.com [216.241.235.117]) by cuda.sgi.com with ESMTP id kARH4hED4YMVnG6O for ; Sun, 06 Jul 2008 20:07:11 -0700 (PDT) Received: from bby1mta02.pmc-sierra.bc.ca (localhost.pmc-sierra.bc.ca [127.0.0.1]) by localhost (Postfix) with SMTP id 079B18E00A2; Sun, 6 Jul 2008 20:09:56 -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 E68EC8E007F; Sun, 6 Jul 2008 20:09:55 -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 20:07:49 -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); Sun, 6 Jul 2008 20:07:48 -0700 Message-ID: <4871885B.6090208@pmc-sierra.com> Date: Mon, 07 Jul 2008 08:37:07 +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: 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> <486FA095.1050106@sandeen.net> <340C71CD25A7EB49BFA81AE8C839266702A084A6@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <487117FC.9090109@sandeen.net> <4871872B.9060107@pmc-sierra.com> <487187D2.8080105@sandeen.net> In-Reply-To: <487187D2.8080105@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2008 03:07:49.0001 (UTC) FILETIME=[A2F8D790:01C8DFDE] X-Barracuda-Connect: bby1mta02.pmc-sierra.com[216.241.235.117] X-Barracuda-Start-Time: 1215400031 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0894 1.0000 -1.4565 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.46 X-Barracuda-Spam-Status: No, SCORE=-1.46 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.55350 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: 16758 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: > > > >> There was no failure. Only the processes were stalled. System was >> operative. >> > > > I'm curious, if the processes were stalled, how did you unmount the > filesystem to run repair on it? > > -Eric > I ran with -n option. xfs_repair -fvn /root/test_partition Sagar From owner-xfs@oss.sgi.com Sun Jul 6 20:10:48 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Jul 2008 20:10:50 -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 m673Alnb023662 for ; Sun, 6 Jul 2008 20:10:47 -0700 X-ASG-Debug-ID: 1215400312-5ba503590000-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 BF1702BFA4D for ; Sun, 6 Jul 2008 20:11:52 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id GIlhASmqd3PyCso6 for ; Sun, 06 Jul 2008 20:11:52 -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 B4FA0AC626B; Sun, 6 Jul 2008 22:11:51 -0500 (CDT) Message-ID: <48718977.1090005@sandeen.net> Date: Sun, 06 Jul 2008 22:11:51 -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> <486FA095.1050106@sandeen.net> <340C71CD25A7EB49BFA81AE8C839266702A084A6@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <487117FC.9090109@sandeen.net> <4871872B.9060107@pmc-sierra.com> <487187D2.8080105@sandeen.net> <4871885B.6090208@pmc-sierra.com> In-Reply-To: <4871885B.6090208@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: 1215400312 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0022 1.0000 -2.0063 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.55350 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: 16759 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: >> Sagar Borikar wrote: >> >> >> >>> There was no failure. Only the processes were stalled. System was >>> operative. >>> >> >> I'm curious, if the processes were stalled, how did you unmount the >> filesystem to run repair on it? >> >> -Eric >> > I ran with -n option. > > xfs_repair -fvn /root/test_partition oh.... So, you basically ran repair on a live, mounted filesystem; it's expected that it would not be consistent at this point. So, the errors you are seeing on this x86 are likely not related to those you see on mips. (the D state process might be interesting and worth looking into, but probably not related to the problem you're trying to solve.) -Eric From owner-xfs@oss.sgi.com Sun Jul 6 20:16:11 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Jul 2008 20:16: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.6 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 m673G9Ol024457 for ; Sun, 6 Jul 2008 20:16:10 -0700 X-ASG-Debug-ID: 1215400633-762e02090000-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 58B672BF940 for ; Sun, 6 Jul 2008 20:17:14 -0700 (PDT) Received: from bby1mta02.pmc-sierra.bc.ca (bby1mta02.pmc-sierra.com [216.241.235.117]) by cuda.sgi.com with ESMTP id lR62va5hIcMAtFJE for ; Sun, 06 Jul 2008 20:17:14 -0700 (PDT) Received: from bby1mta02.pmc-sierra.bc.ca (localhost.pmc-sierra.bc.ca [127.0.0.1]) by localhost (Postfix) with SMTP id AEFC18E007F; Sun, 6 Jul 2008 20:19:58 -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 94FC78E006F; Sun, 6 Jul 2008 20:19:58 -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 20:17:52 -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); Sun, 6 Jul 2008 20:17:51 -0700 Message-ID: <48718AB6.80709@pmc-sierra.com> Date: Mon, 07 Jul 2008 08:47:10 +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: 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> <486FA095.1050106@sandeen.net> <340C71CD25A7EB49BFA81AE8C839266702A084A6@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <487117FC.9090109@sandeen.net> <4871872B.9060107@pmc-sierra.com> <487187D2.8080105@sandeen.net> <4871885B.6090208@pmc-sierra.com> <48718977.1090005@sandeen.net> In-Reply-To: <48718977.1090005@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2008 03:17:51.0888 (UTC) FILETIME=[0A521900:01C8DFE0] X-Barracuda-Connect: bby1mta02.pmc-sierra.com[216.241.235.117] X-Barracuda-Start-Time: 1215400634 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3640 1.0000 -0.1049 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.10 X-Barracuda-Spam-Status: No, SCORE=-0.10 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.55352 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: 16760 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: > >> Eric Sandeen wrote: >> >>> Sagar Borikar wrote: >>> >>> >>> >>> >>>> There was no failure. Only the processes were stalled. System was >>>> operative. >>>> >>>> >>> I'm curious, if the processes were stalled, how did you unmount the >>> filesystem to run repair on it? >>> >>> -Eric >>> >>> >> I ran with -n option. >> >> xfs_repair -fvn /root/test_partition >> > > oh.... > > So, you basically ran repair on a live, mounted filesystem; it's > expected that it would not be consistent at this point. > > So, the errors you are seeing on this x86 are likely not related to > those you see on mips. (the D state process might be interesting and > worth looking into, but probably not related to the problem you're > trying to solve.) > > -Eric > Ok. But then I was surprised as why the copy is not successful. Here is the ps output root 29200 0.0 0.1 2088 652 ? D 01:41 0:00 cp -f testfile testdir_16 root 29201 0.0 0.1 2088 648 ? D 01:41 0:00 cp -f testfile testfile_16 root 29202 0.0 0.1 2088 648 ? D 01:41 0:00 cp -f testfile testfile_14 root 29203 0.0 0.1 2088 648 ? D 01:41 0:00 cp -f testfile testfile_2 root 29204 0.0 0.1 2088 652 ? D 01:41 0:00 cp -f testfile testdir_9 root 29205 0.0 0.1 2088 648 ? D 01:41 0:00 cp -f testfile testfile_5 root 29206 0.0 0.1 2088 652 ? D 01:41 0:00 cp -f testfile testdir_3 root 29207 0.0 0.1 2088 648 ? D 01:41 0:00 cp -f testfile testfile_15 root 29208 0.0 0.1 2088 648 ? D 01:41 0:00 cp -f testfile testdir_2 root 29209 0.0 0.1 2088 652 ? D 01:41 0:00 cp -f testfile testdir_12 root 29210 0.0 0.1 2088 644 ? D 01:41 0:00 cp -f testfile testfile_10 root 29211 0.0 0.1 2088 648 ? D 01:41 0:00 cp -f testfile testfile_4 root 29212 0.0 0.1 2088 652 ? D 01:41 0:00 cp -f testfile testdir_13 root 29213 0.0 0.1 2088 648 ? D 01:41 0:00 cp -f testfile testfile_20 root 29214 0.0 0.1 2088 648 ? D 01:41 0:00 cp -f testfile testdir_20 root 29215 0.0 0.1 2088 656 ? D 01:41 0:00 cp -f testfile testdir_18 root 29216 0.0 0.1 2088 644 ? D 01:41 0:00 cp -f testfile testfile_13 root 29217 0.0 0.1 2088 648 ? D 01:41 0:00 cp -f testfile testdir_1 root 29218 0.0 0.1 2088 652 ? D 01:41 0:00 cp -f testfile testdir_8 root 29219 0.0 0.1 2088 648 ? D 01:41 0:00 cp -f testfile testfile_11 root 29220 0.0 0.1 2088 652 ? D 01:41 0:00 cp -f testfile testdir_6 root 29221 0.0 0.1 2088 644 ? D 01:41 0:00 cp -f testfile testfile_6 root 29222 0.0 0.1 2088 652 ? D 01:41 0:00 cp -f testfile testdir_10 root 29223 0.0 0.1 2088 652 ? D 01:41 0:00 cp -f testfile testdir_14 root 29224 0.0 0.1 2088 648 ? D 01:41 0:00 cp -f testfile testfile_19 root 29225 0.0 0.1 2088 644 ? D 01:41 0:00 cp -f testfile testfile_12 root 29226 0.0 0.1 2088 652 ? D 01:41 0:00 cp -f testfile testdir_5 root 29227 0.0 0.1 2088 648 ? D 01:41 0:00 cp -f testfile testdir_11 root 29228 0.0 0.1 2088 648 ? D 01:41 0:00 cp -f testfile testfile_8 root 29229 0.0 0.1 2088 652 ? D 01:41 0:00 cp -f testfile testdir_4 root 29230 0.0 0.1 2088 652 ? D 01:41 0:00 cp -f testfile testdir_17 root 29231 0.0 0.1 2088 644 ? D 01:41 0:00 cp -f testfile testfile_18 root 29232 0.0 0.1 2088 648 ? D 01:41 0:00 cp -f testfile testdir_15 root 29233 0.0 0.1 2088 648 ? D 01:41 0:00 cp -f testfile testfile_7 root 29234 0.0 0.1 2088 644 ? D 01:41 0:00 cp -f testfile testfile_3 root 29235 0.0 0.1 2088 644 ? D 01:41 0:00 cp -f testfile testfile_1 root 29236 0.0 0.1 2088 648 ? D 01:41 0:00 cp -f testfile testfile_17 root 29237 0.0 0.1 2088 652 ? D 01:41 0:00 cp -f testfile testdir_7 root 29238 0.0 0.1 2088 648 ? D 01:41 0:00 cp -f testfile testdir_19 root 29239 0.0 0.1 2088 648 ? D 01:41 0:00 cp -f testfile testfile_9 All the the copies are pending and file size in those directories is constant. It is not increasing. And as the processes are in D state, the file system is marked as busy and I can't unmount it. Thanks Sagar From owner-xfs@oss.sgi.com Sun Jul 6 20:21:21 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Jul 2008 20:21: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.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 m673LL2c029637 for ; Sun, 6 Jul 2008 20:21:21 -0700 X-ASG-Debug-ID: 1215400945-2e3b00c80000-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 46EC62BFBA8 for ; Sun, 6 Jul 2008 20:22:25 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id WcOTXXLGD2ASU2ck for ; Sun, 06 Jul 2008 20:22:25 -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 3C148AC626B; Sun, 6 Jul 2008 22:22:25 -0500 (CDT) Message-ID: <48718BF0.2040700@sandeen.net> Date: Sun, 06 Jul 2008 22:22:24 -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> <486FA095.1050106@sandeen.net> <340C71CD25A7EB49BFA81AE8C839266702A084A6@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <487117FC.9090109@sandeen.net> <4871872B.9060107@pmc-sierra.com> <487187D2.8080105@sandeen.net> <4871885B.6090208@pmc-sierra.com> <48718977.1090005@sandeen.net> <48718AB6.80709@pmc-sierra.com> In-Reply-To: <48718AB6.80709@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: 1215400946 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0001 1.0000 -2.0201 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.55352 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: 16761 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: > All the the copies are pending and file size in those directories is > constant. It is not > increasing. > And as the processes are in D state, the file system is marked as busy > and I can't unmount > it. Understood. It looks like you've deadlocked somewhere. But, this is not the problem you are really trying to solve, right? You just were trying to recreate the mips problem on x86? If you want, do a sysrq-t to get traces of all those cp's to see where they're stuck, but this probably isn't getting you much closer to solving the original problem. (BTW: is this the exact same testcase that led to the block 0 access on mips which started this thread?) -Eric From owner-xfs@oss.sgi.com Sun Jul 6 20:41:11 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Jul 2008 20:41:14 -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 m673fBuA031071 for ; Sun, 6 Jul 2008 20:41:11 -0700 X-ASG-Debug-ID: 1215402135-66da02150000-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 AAB0A11DD133 for ; Sun, 6 Jul 2008 20:42:15 -0700 (PDT) Received: from bby1mta02.pmc-sierra.bc.ca (bby1mta02.pmc-sierra.com [216.241.235.117]) by cuda.sgi.com with ESMTP id CxYPKGyvQnK50kqt for ; Sun, 06 Jul 2008 20:42:15 -0700 (PDT) Received: from bby1mta02.pmc-sierra.bc.ca (localhost.pmc-sierra.bc.ca [127.0.0.1]) by localhost (Postfix) with SMTP id 7429B8E007E; Sun, 6 Jul 2008 20:45:00 -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 5A9538E0078; Sun, 6 Jul 2008 20:45:00 -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 20:42:53 -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); Sun, 6 Jul 2008 20:42:53 -0700 Message-ID: <48719093.3060907@pmc-sierra.com> Date: Mon, 07 Jul 2008 09:12:11 +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: 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> <486FA095.1050106@sandeen.net> <340C71CD25A7EB49BFA81AE8C839266702A084A6@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <487117FC.9090109@sandeen.net> <4871872B.9060107@pmc-sierra.com> <487187D2.8080105@sandeen.net> <4871885B.6090208@pmc-sierra.com> <48718977.1090005@sandeen.net> <48718AB6.80709@pmc-sierra.com> <48718BF0.2040700@sandeen.net> In-Reply-To: <48718BF0.2040700@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2008 03:42:53.0301 (UTC) FILETIME=[893B8A50:01C8DFE3] X-Barracuda-Connect: bby1mta02.pmc-sierra.com[216.241.235.117] X-Barracuda-Start-Time: 1215402135 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0017 1.0000 -2.0098 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.55354 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: 16762 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: > > >> All the the copies are pending and file size in those directories is >> constant. It is not >> increasing. >> And as the processes are in D state, the file system is marked as busy >> and I can't unmount >> it. >> > > Understood. It looks like you've deadlocked somewhere. But, this is > not the problem you are really trying to solve, right? You just were > trying to recreate the mips problem on x86? > That's right. The intention behind testing on 2.6.24 was to check whether we can imitate failure on x86 which is considered to be more robust. If we replicate the failure then there could be some issue in XFS and if the test passes then we can back port this kernel on MIPS ( Which any way I am doing with your patches ). But I faced similar deadlock on MIPS with exceptions which I posted earlier. > If you want, do a sysrq-t to get traces of all those cp's to see where > they're stuck, but this probably isn't getting you much closer to > solving the original problem. > > I'll keep you posted with it. > (BTW: is this the exact same testcase that led to the block 0 access on > mips which started this thread?) > > -Eric > Ok. So initially our multi client iozone stress test used to fail. But as it took 2-3 days to replicate the issue, I tried the test, standalone on MIPS and observed similar failures which I used to get in multi client test. The test is exactly same what I do in mutli client iozoen over network. Hence I came to conclusion that if we fix system to pass my test case then we can try iozone test with that fix. And now on x86 with 2.6.24, I am finding similar deadlock but the system is responsive and there are no lockups or exceptions. Do you observe similar failures on x86 at your setup? Also do you think the issues which I am seeing on x86 and MIPS are coming from the same sources? Thanks Sagar From owner-xfs@oss.sgi.com Sun Jul 6 20:46:12 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Jul 2008 20:46: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.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 m673kCt7031638 for ; Sun, 6 Jul 2008 20:46:12 -0700 X-ASG-Debug-ID: 1215402436-01d7003d0000-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 A8D6C188380B for ; Sun, 6 Jul 2008 20:47:16 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id 0BdF4mMcyb0Bmaua for ; Sun, 06 Jul 2008 20:47:16 -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 E4C90AC626B; Sun, 6 Jul 2008 22:47:14 -0500 (CDT) Message-ID: <487191C2.6090803@sandeen.net> Date: Sun, 06 Jul 2008 22:47:14 -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> <486FA095.1050106@sandeen.net> <340C71CD25A7EB49BFA81AE8C839266702A084A6@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <487117FC.9090109@sandeen.net> <4871872B.9060107@pmc-sierra.com> <487187D2.8080105@sandeen.net> <4871885B.6090208@pmc-sierra.com> <48718977.1090005@sandeen.net> <48718AB6.80709@pmc-sierra.com> <48718BF0.2040700@sandeen.net> <48719093.3060907@pmc-sierra.com> In-Reply-To: <48719093.3060907@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: 1215402436 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0001 1.0000 -2.0204 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.55353 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: 16763 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: > Ok. So initially our multi client iozone stress test used to fail. Are these multiple nfs clients? > But > as it took 2-3 days > to replicate the issue, I tried the test, standalone on MIPS and the iozone test again? > observed similar failures which > I used to get in multi client test. The test is exactly same what I do > in mutli client > iozoen over network. Hence I came to conclusion that if we fix system to > pass my test case > then we can try iozone test with that fix. And now on x86 with 2.6.24, > I am finding similar deadlock but > the system is responsive and there are no lockups or exceptions. Do you > observe similar failures on x86 > at your setup? So far I've not seen the deadlocks. > Also do you think the issues which I am seeing on x86 and > MIPS are coming from the > same sources? hard to say at this point, I think. -Eric > Thanks > Sagar > From owner-xfs@oss.sgi.com Sun Jul 6 20:57:53 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Jul 2008 20:57:56 -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 m673vrhx032597 for ; Sun, 6 Jul 2008 20:57:53 -0700 X-ASG-Debug-ID: 1215403137-01d300d40000-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 E1FDC18840CB for ; Sun, 6 Jul 2008 20:58:57 -0700 (PDT) Received: from bby1mta02.pmc-sierra.bc.ca (bby1mta02.pmc-sierra.com [216.241.235.117]) by cuda.sgi.com with ESMTP id s9slWUz4MS1Oh4mG for ; Sun, 06 Jul 2008 20:58:57 -0700 (PDT) Received: from bby1mta02.pmc-sierra.bc.ca (localhost.pmc-sierra.bc.ca [127.0.0.1]) by localhost (Postfix) with SMTP id 4164C8E009A; Sun, 6 Jul 2008 21:01:42 -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 272058E0092; Sun, 6 Jul 2008 21:01:42 -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 20:59:35 -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); Sun, 6 Jul 2008 20:59:34 -0700 Message-ID: <4871947D.2090701@pmc-sierra.com> Date: Mon, 07 Jul 2008 09:28:53 +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: 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> <486FA095.1050106@sandeen.net> <340C71CD25A7EB49BFA81AE8C839266702A084A6@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <487117FC.9090109@sandeen.net> <4871872B.9060107@pmc-sierra.com> <487187D2.8080105@sandeen.net> <4871885B.6090208@pmc-sierra.com> <48718977.1090005@sandeen.net> <48718AB6.80709@pmc-sierra.com> <48718BF0.2040700@sandeen.net> <48719093.3060907@pmc-sierra.com> <487191C2.6090803@sandeen .net> In-Reply-To: <487191C2.6090803@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2008 03:59:35.0200 (UTC) FILETIME=[DE693200:01C8DFE5] X-Barracuda-Connect: bby1mta02.pmc-sierra.com[216.241.235.117] X-Barracuda-Start-Time: 1215403137 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4715 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.55355 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: 16764 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: > > > >> Ok. So initially our multi client iozone stress test used to fail. >> > > Are these multiple nfs clients? > Actually mix of them. 15 CIFS clients, 4 NFS clients ( 19 iozone clients ) , 2 FTP clients, 4 HTTP transfers. ( Total 25 transactions simultaneously ) > >> But >> as it took 2-3 days >> to replicate the issue, I tried the test, standalone on MIPS and >> > > the iozone test again? > iozone test is continuously giving the access to block zero exception and xfs shutdown errors with transaction cancel exceptions plus alloc btree corruption exception which I reported earlier. And my test gives transaction cancel exception and block zero exception with processes under test in deadlock state on MIPS but on x86 there are no exceptions but only incomplete copies due to uninterruptible sleep state and deadlock. > >> observed similar failures which >> I used to get in multi client test. The test is exactly same what I do >> in mutli client >> iozoen over network. Hence I came to conclusion that if we fix system to >> pass my test case >> then we can try iozone test with that fix. And now on x86 with 2.6.24, >> I am finding similar deadlock but >> the system is responsive and there are no lockups or exceptions. Do you >> observe similar failures on x86 >> at your setup? >> > > So far I've not seen the deadlocks. > Could you kindly try with my test? I presume you should see failure soon. I tried this on 2 different x86 systems 2 times ( after rebooting the system ) and I saw it every time. > >> Also do you think the issues which I am seeing on x86 and >> MIPS are coming from the >> same sources? >> > > hard to say at this point, I think. > > -Eric > > >> Thanks >> Sagar >> >> > > From owner-xfs@oss.sgi.com Sun Jul 6 22:18:54 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Jul 2008 22:19: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=-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 m675IsOt004979 for ; Sun, 6 Jul 2008 22:18:54 -0700 X-ASG-Debug-ID: 1215407997-10de00d40000-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 A0D182BFC61 for ; Sun, 6 Jul 2008 22:19:58 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id CTKRnfJhEA9qXN6N for ; Sun, 06 Jul 2008 22:19:58 -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 A2E71A84DBF; Mon, 7 Jul 2008 00:19:57 -0500 (CDT) Message-ID: <4871A77D.7050803@sandeen.net> Date: Mon, 07 Jul 2008 00:19:57 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 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 References: <486B01A6.4030104@pmc-sierra.com> <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> <340C71CD25A7EB49BFA81AE8C839266702A084A6@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <487117FC.9090109@sandeen.net> <4871872B.9060107@pmc-sierra.com> <487187D2.8080105@sandeen.net> <4871885B.6090208@pmc-sierra.com> <48718977.1090005@sandeen.net> <48718AB6.80709@pmc-sierra.com> <48718BF0.2040700@sandeen.net> <48719093.3060907@pmc-sierra.com> <487191C2.6090803@sandeen .net> <4871947D.2090701@pmc-sierr a.com> In-Reply-To: <4871947D.2090701@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: 1215407998 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0171 1.0000 -1.9097 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.91 X-Barracuda-Spam-Status: No, SCORE=-1.91 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.55360 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: 16765 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: > Could you kindly try with my test? I presume you should see failure > soon. I tried this on > 2 different x86 systems 2 times ( after rebooting the system ) and I saw > it every time. Sure. Is there a reason you're doing this on a loopback file? That probably stresses the vm a bit more, and might get even trickier if the loopback file is sparse... But anyway, on an x86_64 machine with 2G of memory and a non-sparse 10G loopback file on 2.6.24.7-92.fc8, your test runs w/o problems for me, though the system does get sluggish. I let it run a bit then ran repair and it found no problems, I'll run it overnight to see if anything else turns up. -Eric From owner-xfs@oss.sgi.com Sun Jul 6 22:57:32 2008 Received: with ECARTIS (v1.0.0; list xfs); Sun, 06 Jul 2008 22:57:35 -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 (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 m675vWvw007372 for ; Sun, 6 Jul 2008 22:57:32 -0700 X-ASG-Debug-ID: 1215410316-37f4002f0000-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 875942BFF3F for ; Sun, 6 Jul 2008 22:58:36 -0700 (PDT) Received: from bby1mta01.pmc-sierra.bc.ca (bby1mta01.pmc-sierra.com [216.241.235.116]) by cuda.sgi.com with ESMTP id 6HKEE6GcrHr6KaLH for ; Sun, 06 Jul 2008 22:58:36 -0700 (PDT) Received: from bby1mta01.pmc-sierra.bc.ca (localhost.pmc-sierra.bc.ca [127.0.0.1]) by localhost (Postfix) with SMTP id 8B5CF18900C2; Sun, 6 Jul 2008 23:01:52 -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 7F420189009E; Sun, 6 Jul 2008 23:01: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); Sun, 6 Jul 2008 22:59:14 -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); Sun, 6 Jul 2008 22:59:14 -0700 Message-ID: <4871B085.10902@pmc-sierra.com> Date: Mon, 07 Jul 2008 11:28:29 +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: 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> <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> <340C71CD25A7EB49BFA81AE8C839266702A084A6@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> <487117FC.9090109@sandeen.net> <4871872B.9060107@pmc-sierra.com> <487187D2.8080105@sandeen.net> <4871885B.6090208@pmc-sierra.com> <48718977.1090005@sandeen.net> <48718AB6.80709@pmc-sierra.com> <48718BF0.2040700@sandeen.net> <48719093.3060907@pmc-sierra.com> <487191C2.6090803@sandeen .net> <4871947D.2090701@pmc-sierr a.com> <4871A77D.7050803@sandeen. net> In-Reply-To: <4871A77D.7050803@sandeen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2008 05:59:14.0342 (UTC) FILETIME=[95835460:01C8DFF6] X-Barracuda-Connect: bby1mta01.pmc-sierra.com[216.241.235.116] X-Barracuda-Start-Time: 1215410316 X-Barracuda-Bayes: INNOCENT GLOBAL 0.1652 1.0000 -1.0159 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.02 X-Barracuda-Spam-Status: No, SCORE=-1.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.55362 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: 16766 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: > > > >> Could you kindly try with my test? I presume you should see failure >> soon. I tried this on >> 2 different x86 systems 2 times ( after rebooting the system ) and I saw >> it every time. >> > > > Sure. Is there a reason you're doing this on a loopback file? That > probably stresses the vm a bit more, and might get even trickier if the > loopback file is sparse... > Initially I thought to do that since I didn't want to have a strict allocation limit but allowing allocations to grow as needed until the backing filesystem runs out of free space due to type of the test case I had. But then I dropped the plan and created a non-sparse loopback device. There was no specific reason to create loopback but as it was simplest option to do it. > But anyway, on an x86_64 machine with 2G of memory and a non-sparse 10G > loopback file on 2.6.24.7-92.fc8, your test runs w/o problems for me, > though the system does get sluggish. I let it run a bit then ran repair > and it found no problems, I'll run it overnight to see if anything else > turns up. > That will be great. Thanks indeed. Sagar > -Eric > From owner-xfs@oss.sgi.com Mon Jul 7 01:02:55 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Jul 2008 01:03: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 m6782rqG022479 for ; Mon, 7 Jul 2008 01:02:55 -0700 X-ASG-Debug-ID: 1215417837-23d502e00000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mailgate02.web.de (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9FE7911DE847 for ; Mon, 7 Jul 2008 01:03:58 -0700 (PDT) Received: from mailgate02.web.de (mailgate02.web.de [217.72.192.252]) by cuda.sgi.com with ESMTP id vsgGyXW5HYa0GJus for ; Mon, 07 Jul 2008 01:03:58 -0700 (PDT) Received: by lxjbe.webde.local (Postfix, from userid 1000) id 7CCE341261; Mon, 7 Jul 2008 10:04:09 +0200 (CEST) (R201) Date: Mon, 7 Jul 2008 10:04:09 +0200 From: Jens Beyer To: 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: <20080707080409.GA18390@webde.de> References: <20080704064126.GA14847@webde.de> <20080704075941.GP16257@build-svl-1.agami.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080704075941.GP16257@build-svl-1.agami.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Barracuda-Connect: mailgate02.web.de[217.72.192.252] X-Barracuda-Start-Time: 1215417838 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0449 1.0000 -1.7321 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.73 X-Barracuda-Spam-Status: No, SCORE=-1.73 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.55370 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: 16767 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 On Fri, Jul 04, 2008 at 12:59:41AM -0700, Dave Chinner wrote: > On Fri, Jul 04, 2008 at 08:41:26AM +0200, Jens Beyer wrote: > > > > 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. > But then - why does the rate of ext3 does not decrease and stays at the higher value? Thanks, Jens From owner-xfs@oss.sgi.com Mon Jul 7 02:44:45 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Jul 2008 02: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.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 m679ihvx029797 for ; Mon, 7 Jul 2008 02:44:44 -0700 X-ASG-Debug-ID: 1215423947-6bbb02450000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.acc.umu.se (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id D479B2C0A4B for ; Mon, 7 Jul 2008 02:45:48 -0700 (PDT) Received: from mail.acc.umu.se (mail.acc.umu.se [130.239.18.156]) by cuda.sgi.com with ESMTP id mVPIVcpnGjegrNPD for ; Mon, 07 Jul 2008 02:45:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by amavisd-new (Postfix) with ESMTP id 95603F59; Mon, 7 Jul 2008 11:45:46 +0200 (MEST) 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 acc.umu.se Received: from shaka.acc.umu.se (shaka.acc.umu.se [130.239.18.148]) by mail.acc.umu.se (Postfix) with ESMTP id 4C836F58; Mon, 7 Jul 2008 11:45:45 +0200 (MEST) Received: by shaka.acc.umu.se (Postfix, from userid 23056) id 2126B35C; Mon, 7 Jul 2008 11:45:45 +0200 (MEST) Received: from localhost (localhost [127.0.0.1]) by shaka.acc.umu.se (Postfix) with ESMTP id 121F435B; Mon, 7 Jul 2008 11:45:45 +0200 (MEST) Date: Mon, 7 Jul 2008 11:45:44 +0200 (MEST) From: Mattias Wadenstein To: Justin Piszcz cc: Robert Hancock , 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Barracuda-Connect: mail.acc.umu.se[130.239.18.156] X-Barracuda-Start-Time: 1215423948 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.55376 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 16768 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: maswan@acc.umu.se 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. Looking at the sum wattage number is really misleading for this. You need to dig out the specs for how many amps it can provide on the different voltages (5 and 12 volts). In particular, many modern PSUs have several separate 12V rails, where one (or more, some have the 12V supply split into 3 or 4 parts!) is used for CPU and GFX card power and usually only one is available for disks. You can also have plenty of 12V left but run out of 5V, or the other way around. I've spent quite some time trying to find a PSU that would handle 18 disks without costing too much. The splitting of the 12V power into separate rails and a general lack of 5V compared to what the disks need according to their specs just made it difficult, and I ended up bonding two PSUs together (linking the ground together with some custom cabling) to get a stable machine again. /Mattias Wadenstein From owner-xfs@oss.sgi.com Mon Jul 7 02:56:19 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Jul 2008 02:56: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=-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 m679uJVs030929 for ; Mon, 7 Jul 2008 02:56:19 -0700 X-ASG-Debug-ID: 1215424643-260a01d30000-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 1650411E18B2 for ; Mon, 7 Jul 2008 02:57:23 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id 0K4iLmBazVSY5BZW for ; Mon, 07 Jul 2008 02:57:23 -0700 (PDT) Received: by lucidpixels.com (Postfix, from userid 1001) id 559225A56F; Mon, 7 Jul 2008 05:57:23 -0400 (EDT) Date: Mon, 7 Jul 2008 05:57:23 -0400 (EDT) From: Justin Piszcz To: Mattias Wadenstein cc: Robert Hancock , 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: 1215424644 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.55378 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: 16769 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 Mon, 7 Jul 2008, Mattias Wadenstein wrote: > 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. > > Looking at the sum wattage number is really misleading for this. You need to > dig out the specs for how many amps it can provide on the different voltages > (5 and 12 volts). In particular, many modern PSUs have several separate 12V > rails, where one (or more, some have the 12V supply split into 3 or 4 parts!) > is used for CPU and GFX card power and usually only one is available for > disks. > > You can also have plenty of 12V left but run out of 5V, or the other way > around. I've spent quite some time trying to find a PSU that would handle 18 > disks without costing too much. The splitting of the 12V power into separate > rails and a general lack of 5V compared to what the disks need according to > their specs just made it difficult, and I ended up bonding two PSUs together > (linking the ground together with some custom cabling) to get a stable > machine again. > > /Mattias Wadenstein > Good info here indeed but for my case it does not apply. I used to have Raptor150s (12 of them on the same host) the ONLY thing that changed was the drives themselves. And it used to use 150-250 watts (the 3.5" suck up a lot more power) the power cables are also exactly the same as they were on the Raptor 150s and I never had any issues. I have two hosts, pretty much idential, I use the Antec TruePower Trio 650 in each of them. http://www.antec.com/us/productDetails.php?ProdID=23650 Justin. From owner-xfs@oss.sgi.com Mon Jul 7 04:28:50 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Jul 2008 04:28:53 -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.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_64 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 m67BSjbC009809 for ; Mon, 7 Jul 2008 04:28:47 -0700 Received: from tim-shimmins-mac-mini.local (melb-sw-corp-251-5.corp.sgi.com [134.15.251.5]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id VAA23814; Mon, 7 Jul 2008 21:29:38 +1000 Message-ID: <4871FE21.9020609@sgi.com> Date: Mon, 07 Jul 2008 21:29:37 +1000 From: Tim 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 1/3] split out xfs value-add from xfs_setattr References: <20080627154553.GA31476@lst.de> In-Reply-To: <20080627154553.GA31476@lst.de> 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: 16770 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, I've gone thru this and it looks good to me. However, there is enough stuff which was extracted and duplicated from different places in xfs_setattr to easily miss something (IMHO) and so we would need to test this carefully I reckon. I'll have a look at the other 2 patches tomorrow. Below are my notes: * remove related code to quota, xflags, etc from xfs_setattr * duplicate support code from xfs_setattr * I need to compare old xfs_setattr() with xfs_ioctl_setattr() to check that the code is still doing the same thing for the relevant cases... * The "can't change extent size test" is duplicated as we split up the predicate of EXTSIZE and XFLAGS into two Okay * xfs_trans_log_inode doesn't need to be called in 2 spots now it can be done after the di_extsize and the set_diflags spot and no need for just after the projid one. Okay * And we just call xfs_ichgtime directly instead of noting a timeflag Okay * commit_flags are zero as are non-zero for AT_SIZE changes which we don't deal with here Okay * This code is different: + if (DM_EVENT_ENABLED(ip, DM_EVENT_ATTRIBUTE)) { + XFS_SEND_NAMESP(mp, DM_EVENT_ATTRIBUTE, ip, DM_RIGHT_NULL, + NULL, DM_RIGHT_NULL, NULL, NULL, 0, 0, + (mask & FSX_NONBLOCK) ? DM_FLAGS_NDELAY : 0); + } + + vn_revalidate(XFS_ITOV(ip)); /* update flags */ Q: What happened to the ATTR_DMI flag testing? A: We never set ATTR_DMI in the flags by the ioctls. Okay cool. Q: Why have you introduced the vn_revalidate? A: Because you took it out of the callers to xfs_ioctl_setattr. Okay * So XFS_AT_ALL and XFS_AT_STAT are not used currently Okay --Tim Christoph Hellwig wrote: > xfs_setattr currently doesn't just handle the attributes set through > ->setattr but also addition XFS-specific attributes: project id, inode > flags and extent size hint. Having these in a single function makes it > more complicated and forces to have us a bhv_vattr intermediate > structure eating up stackspace. > > This patch adds a new xfs_ioctl_setattr helper for the XFS ioctls that > set these attributes and remove the code to set them through > xfs_setattr. > > > Signed-off-by: Christoph Hellwig > > 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-06-15 16:41:09.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_ioctl.c 2008-06-15 16:42:18.000000000 +0200 > @@ -47,6 +47,8 @@ > #include "xfs_dfrag.h" > #include "xfs_fsops.h" > #include "xfs_vnodeops.h" > +#include "xfs_quota.h" > +#include "xfs_inode_item.h" > > #include > #include > @@ -875,6 +877,297 @@ xfs_ioc_fsgetxattr( > return 0; > } > > +STATIC void > +xfs_set_diflags( > + struct xfs_inode *ip, > + unsigned int xflags) > +{ > + unsigned int di_flags; > + > + /* can't set PREALLOC this way, just preserve it */ > + di_flags = (ip->i_d.di_flags & XFS_DIFLAG_PREALLOC); > + if (xflags & XFS_XFLAG_IMMUTABLE) > + di_flags |= XFS_DIFLAG_IMMUTABLE; > + if (xflags & XFS_XFLAG_APPEND) > + di_flags |= XFS_DIFLAG_APPEND; > + if (xflags & XFS_XFLAG_SYNC) > + di_flags |= XFS_DIFLAG_SYNC; > + if (xflags & XFS_XFLAG_NOATIME) > + di_flags |= XFS_DIFLAG_NOATIME; > + if (xflags & XFS_XFLAG_NODUMP) > + di_flags |= XFS_DIFLAG_NODUMP; > + if (xflags & XFS_XFLAG_PROJINHERIT) > + di_flags |= XFS_DIFLAG_PROJINHERIT; > + if (xflags & XFS_XFLAG_NODEFRAG) > + di_flags |= XFS_DIFLAG_NODEFRAG; > + if (xflags & XFS_XFLAG_FILESTREAM) > + di_flags |= XFS_DIFLAG_FILESTREAM; > + if ((ip->i_d.di_mode & S_IFMT) == S_IFDIR) { > + if (xflags & XFS_XFLAG_RTINHERIT) > + di_flags |= XFS_DIFLAG_RTINHERIT; > + if (xflags & XFS_XFLAG_NOSYMLINKS) > + di_flags |= XFS_DIFLAG_NOSYMLINKS; > + if (xflags & XFS_XFLAG_EXTSZINHERIT) > + di_flags |= XFS_DIFLAG_EXTSZINHERIT; > + } else if ((ip->i_d.di_mode & S_IFMT) == S_IFREG) { > + if (xflags & XFS_XFLAG_REALTIME) > + di_flags |= XFS_DIFLAG_REALTIME; > + if (xflags & XFS_XFLAG_EXTSIZE) > + di_flags |= XFS_DIFLAG_EXTSIZE; > + } > + > + ip->i_d.di_flags = di_flags; > +} > + > + > +#define FSX_PROJID 1 > +#define FSX_EXTSIZE 2 > +#define FSX_XFLAGS 4 > +#define FSX_NONBLOCK 8 > + > +STATIC int > +xfs_ioctl_setattr( > + xfs_inode_t *ip, > + struct fsxattr *fa, > + int mask) > +{ > + struct xfs_mount *mp = ip->i_mount; > + struct xfs_trans *tp; > + unsigned int lock_flags = 0; > + struct xfs_dquot *udqp = NULL, *gdqp = NULL; > + struct xfs_dquot *olddquot = NULL; > + int code; > + > + xfs_itrace_entry(ip); > + > + if (mp->m_flags & XFS_MOUNT_RDONLY) > + return XFS_ERROR(EROFS); > + if (XFS_FORCED_SHUTDOWN(mp)) > + return XFS_ERROR(EIO); > + > + /* > + * If disk quotas is on, we make sure that the dquots do exist on disk, > + * before we start any other transactions. Trying to do this later > + * is messy. We don't care to take a readlock to look at the ids > + * in inode here, because we can't hold it across the trans_reserve. > + * 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 & FSX_PROJID)) { > + code = XFS_QM_DQVOPALLOC(mp, ip, ip->i_d.di_uid, > + ip->i_d.di_gid, fa->fsx_projid, > + XFS_QMOPT_PQUOTA, &udqp, &gdqp); > + if (code) > + return code; > + } > + > + /* > + * For the other attributes, we acquire the inode lock and > + * first do an error checking pass. > + */ > + tp = xfs_trans_alloc(mp, XFS_TRANS_SETATTR_NOT_SIZE); > + code = xfs_trans_reserve(tp, 0, XFS_ICHANGE_LOG_RES(mp), 0, 0, 0); > + if (code) > + goto error_return; > + > + lock_flags = XFS_ILOCK_EXCL; > + xfs_ilock(ip, lock_flags); > + > + /* > + * CAP_FOWNER overrides the following restrictions: > + * > + * The user ID of the calling process must be equal > + * to the file owner ID, except in cases where the > + * CAP_FSETID capability is applicable. > + */ > + if (current->fsuid != ip->i_d.di_uid && !capable(CAP_FOWNER)) { > + code = XFS_ERROR(EPERM); > + goto error_return; > + } > + > + /* > + * Do a quota reservation only if projid is actually going to change. > + */ > + if (mask & FSX_PROJID) { > + if (XFS_IS_PQUOTA_ON(mp) && > + ip->i_d.di_projid != fa->fsx_projid) { > + ASSERT(tp); > + code = XFS_QM_DQVOPCHOWNRESV(mp, tp, ip, udqp, gdqp, > + capable(CAP_FOWNER) ? > + XFS_QMOPT_FORCE_RES : 0); > + if (code) /* out of quota */ > + goto error_return; > + } > + } > + > + if (mask & FSX_EXTSIZE) { > + /* > + * Can't change extent size if any extents are allocated. > + */ > + if (ip->i_d.di_nextents && > + ((ip->i_d.di_extsize << mp->m_sb.sb_blocklog) != > + fa->fsx_extsize)) { > + code = XFS_ERROR(EINVAL); /* EFBIG? */ > + goto error_return; > + } > + > + /* > + * Extent size must be a multiple of the appropriate block > + * size, if set at all. > + */ > + if (fa->fsx_extsize != 0) { > + xfs_extlen_t size; > + > + if (XFS_IS_REALTIME_INODE(ip) || > + ((mask & FSX_XFLAGS) && > + (fa->fsx_xflags & XFS_XFLAG_REALTIME))) { > + size = mp->m_sb.sb_rextsize << > + mp->m_sb.sb_blocklog; > + } else { > + size = mp->m_sb.sb_blocksize; > + } > + > + if (fa->fsx_extsize % size) { > + code = XFS_ERROR(EINVAL); > + goto error_return; > + } > + } > + } > + > + > + if (mask & FSX_XFLAGS) { > + /* > + * Can't change realtime flag if any extents are allocated. > + */ > + if ((ip->i_d.di_nextents || ip->i_delayed_blks) && > + (XFS_IS_REALTIME_INODE(ip)) != > + (fa->fsx_xflags & XFS_XFLAG_REALTIME)) { > + code = XFS_ERROR(EINVAL); /* EFBIG? */ > + goto error_return; > + } > + > + /* > + * If realtime flag is set then must have realtime data. > + */ > + if ((fa->fsx_xflags & XFS_XFLAG_REALTIME)) { > + if ((mp->m_sb.sb_rblocks == 0) || > + (mp->m_sb.sb_rextsize == 0) || > + (ip->i_d.di_extsize % mp->m_sb.sb_rextsize)) { > + code = XFS_ERROR(EINVAL); > + goto error_return; > + } > + } > + > + /* > + * Can't modify an immutable/append-only file unless > + * we have appropriate permission. > + */ > + if ((ip->i_d.di_flags & > + (XFS_DIFLAG_IMMUTABLE|XFS_DIFLAG_APPEND) || > + (fa->fsx_xflags & > + (XFS_XFLAG_IMMUTABLE | XFS_XFLAG_APPEND))) && > + !capable(CAP_LINUX_IMMUTABLE)) { > + code = XFS_ERROR(EPERM); > + goto error_return; > + } > + } > + > + xfs_trans_ijoin(tp, ip, lock_flags); > + xfs_trans_ihold(tp, ip); > + > + /* > + * Change file ownership. Must be the owner or privileged. > + * If the system was configured with the "restricted_chown" > + * option, the owner is not permitted to give away the file, > + * and can change the group id only to a group of which he > + * or she is a member. > + */ > + if (mask & FSX_PROJID) { > + /* > + * CAP_FSETID overrides the following restrictions: > + * > + * The set-user-ID and set-group-ID bits of a file will be > + * cleared upon successful return from chown() > + */ > + if ((ip->i_d.di_mode & (S_ISUID|S_ISGID)) && > + !capable(CAP_FSETID)) > + ip->i_d.di_mode &= ~(S_ISUID|S_ISGID); > + > + /* > + * Change the ownerships and register quota modifications > + * in the transaction. > + */ > + if (ip->i_d.di_projid != fa->fsx_projid) { > + if (XFS_IS_PQUOTA_ON(mp)) { > + olddquot = XFS_QM_DQVOPCHOWN(mp, tp, ip, > + &ip->i_gdquot, gdqp); > + } > + ip->i_d.di_projid = fa->fsx_projid; > + > + /* > + * We may have to rev the inode as well as > + * the superblock version number since projids didn't > + * exist before DINODE_VERSION_2 and SB_VERSION_NLINK. > + */ > + if (ip->i_d.di_version == XFS_DINODE_VERSION_1) > + xfs_bump_ino_vers2(tp, ip); > + } > + > + } > + > + if (mask & FSX_EXTSIZE) > + ip->i_d.di_extsize = fa->fsx_extsize >> mp->m_sb.sb_blocklog; > + if (mask & FSX_XFLAGS) > + xfs_set_diflags(ip, fa->fsx_xflags); > + > + xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); > + xfs_ichgtime(ip, XFS_ICHGTIME_CHG); > + > + XFS_STATS_INC(xs_ig_attrchg); > + > + /* > + * If this is a synchronous mount, make sure that the > + * transaction goes to disk before returning to the user. > + * This is slightly sub-optimal in that truncates require > + * two sync transactions instead of one for wsync filesystems. > + * One for the truncate and one for the timestamps since we > + * don't want to change the timestamps unless we're sure the > + * truncate worked. Truncates are less than 1% of the laddis > + * mix so this probably isn't worth the trouble to optimize. > + */ > + if (mp->m_flags & XFS_MOUNT_WSYNC) > + xfs_trans_set_sync(tp); > + code = xfs_trans_commit(tp, 0); > + xfs_iunlock(ip, lock_flags); > + > + /* > + * Release any dquot(s) the inode had kept before chown. > + */ > + XFS_QM_DQRELE(mp, olddquot); > + XFS_QM_DQRELE(mp, udqp); > + XFS_QM_DQRELE(mp, gdqp); > + > + if (code) > + return code; > + > + if (DM_EVENT_ENABLED(ip, DM_EVENT_ATTRIBUTE)) { > + XFS_SEND_NAMESP(mp, DM_EVENT_ATTRIBUTE, ip, DM_RIGHT_NULL, > + NULL, DM_RIGHT_NULL, NULL, NULL, 0, 0, > + (mask & FSX_NONBLOCK) ? DM_FLAGS_NDELAY : 0); > + } > + > + vn_revalidate(XFS_ITOV(ip)); /* update flags */ > + return 0; > + > + error_return: > + XFS_QM_DQRELE(mp, udqp); > + XFS_QM_DQRELE(mp, gdqp); > + xfs_trans_cancel(tp, 0); > + if (lock_flags) > + xfs_iunlock(ip, lock_flags); > + return code; > +} > + > STATIC int > xfs_ioc_fssetxattr( > xfs_inode_t *ip, > @@ -882,31 +1175,16 @@ xfs_ioc_fssetxattr( > void __user *arg) > { > struct fsxattr fa; > - struct bhv_vattr *vattr; > - int error; > - int attr_flags; > + unsigned int mask; > > if (copy_from_user(&fa, arg, sizeof(fa))) > return -EFAULT; > > - vattr = kmalloc(sizeof(*vattr), GFP_KERNEL); > - if (unlikely(!vattr)) > - return -ENOMEM; > - > - attr_flags = 0; > + mask = FSX_XFLAGS | FSX_EXTSIZE | FSX_PROJID; > if (filp->f_flags & (O_NDELAY|O_NONBLOCK)) > - attr_flags |= ATTR_NONBLOCK; > + mask |= FSX_NONBLOCK; > > - vattr->va_mask = XFS_AT_XFLAGS | XFS_AT_EXTSIZE | XFS_AT_PROJID; > - vattr->va_xflags = fa.fsx_xflags; > - vattr->va_extsize = fa.fsx_extsize; > - vattr->va_projid = fa.fsx_projid; > - > - error = -xfs_setattr(ip, vattr, attr_flags, NULL); > - if (!error) > - vn_revalidate(XFS_ITOV(ip)); /* update flags */ > - kfree(vattr); > - return 0; > + return -xfs_ioctl_setattr(ip, &fa, mask); > } > > STATIC int > @@ -928,10 +1206,9 @@ xfs_ioc_setxflags( > struct file *filp, > void __user *arg) > { > - struct bhv_vattr *vattr; > + struct fsxattr fa; > unsigned int flags; > - int attr_flags; > - int error; > + unsigned int mask; > > if (copy_from_user(&flags, arg, sizeof(flags))) > return -EFAULT; > @@ -941,22 +1218,12 @@ xfs_ioc_setxflags( > FS_SYNC_FL)) > return -EOPNOTSUPP; > > - vattr = kmalloc(sizeof(*vattr), GFP_KERNEL); > - if (unlikely(!vattr)) > - return -ENOMEM; > - > - attr_flags = 0; > + mask = FSX_XFLAGS; > if (filp->f_flags & (O_NDELAY|O_NONBLOCK)) > - attr_flags |= ATTR_NONBLOCK; > + mask |= FSX_NONBLOCK; > + fa.fsx_xflags = xfs_merge_ioc_xflags(flags, xfs_ip2xflags(ip)); > > - vattr->va_mask = XFS_AT_XFLAGS; > - vattr->va_xflags = xfs_merge_ioc_xflags(flags, xfs_ip2xflags(ip)); > - > - error = -xfs_setattr(ip, vattr, attr_flags, NULL); > - if (likely(!error)) > - vn_revalidate(XFS_ITOV(ip)); /* update flags */ > - kfree(vattr); > - return error; > + return -xfs_ioctl_setattr(ip, &fa, mask); > } > > STATIC int > 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-06-15 17:32:14.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_vnode.h 2008-06-15 17:35:44.000000000 +0200 > @@ -117,26 +117,11 @@ typedef struct bhv_vattr { > #define XFS_AT_ACL 0x00080000 > #define XFS_AT_CAP 0x00100000 > #define XFS_AT_INF 0x00200000 > -#define XFS_AT_XFLAGS 0x00400000 > -#define XFS_AT_EXTSIZE 0x00800000 > #define XFS_AT_NEXTENTS 0x01000000 > #define XFS_AT_ANEXTENTS 0x02000000 > -#define XFS_AT_PROJID 0x04000000 > #define XFS_AT_SIZE_NOPERM 0x08000000 > #define XFS_AT_GENCOUNT 0x10000000 > > -#define XFS_AT_ALL (XFS_AT_TYPE|XFS_AT_MODE|XFS_AT_UID|XFS_AT_GID|\ > - XFS_AT_FSID|XFS_AT_NODEID|XFS_AT_NLINK|XFS_AT_SIZE|\ > - XFS_AT_ATIME|XFS_AT_MTIME|XFS_AT_CTIME|XFS_AT_RDEV|\ > - XFS_AT_BLKSIZE|XFS_AT_NBLOCKS|XFS_AT_VCODE|XFS_AT_MAC|\ > - XFS_AT_ACL|XFS_AT_CAP|XFS_AT_INF|XFS_AT_XFLAGS|XFS_AT_EXTSIZE|\ > - XFS_AT_NEXTENTS|XFS_AT_ANEXTENTS|XFS_AT_PROJID|XFS_AT_GENCOUNT) > - > -#define XFS_AT_STAT (XFS_AT_TYPE|XFS_AT_MODE|XFS_AT_UID|XFS_AT_GID|\ > - XFS_AT_FSID|XFS_AT_NODEID|XFS_AT_NLINK|XFS_AT_SIZE|\ > - XFS_AT_ATIME|XFS_AT_MTIME|XFS_AT_CTIME|XFS_AT_RDEV|\ > - XFS_AT_BLKSIZE|XFS_AT_NBLOCKS|XFS_AT_PROJID) > - > #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) > Index: linux-2.6-xfs/fs/xfs/xfs_vnodeops.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_vnodeops.c 2008-06-15 17:32:42.000000000 +0200 > +++ linux-2.6-xfs/fs/xfs/xfs_vnodeops.c 2008-06-15 17:39:09.000000000 +0200 > @@ -94,7 +94,6 @@ xfs_setattr( > uid_t uid=0, iuid=0; > gid_t gid=0, igid=0; > int timeflags = 0; > - xfs_prid_t projid=0, iprojid=0; > struct xfs_dquot *udqp, *gdqp, *olddquot1, *olddquot2; > int file_owner; > int need_iolock = 1; > @@ -139,8 +138,7 @@ 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|XFS_AT_PROJID))) { > + if (XFS_IS_QUOTA_ON(mp) && (mask & (XFS_AT_UID|XFS_AT_GID))) { > uint qflags = 0; > > if ((mask & XFS_AT_UID) && XFS_IS_UQUOTA_ON(mp)) { > @@ -155,12 +153,7 @@ xfs_setattr( > } else { > gid = ip->i_d.di_gid; > } > - if ((mask & XFS_AT_PROJID) && XFS_IS_PQUOTA_ON(mp)) { > - projid = vap->va_projid; > - qflags |= XFS_QMOPT_PQUOTA; > - } else { > - projid = ip->i_d.di_projid; > - } > + > /* > * We take a reference when we initialize udqp and gdqp, > * so it is important that we never blindly double trip on > @@ -168,8 +161,8 @@ xfs_setattr( > */ > ASSERT(udqp == NULL); > ASSERT(gdqp == NULL); > - code = XFS_QM_DQVOPALLOC(mp, ip, uid, gid, projid, qflags, > - &udqp, &gdqp); > + code = XFS_QM_DQVOPALLOC(mp, ip, uid, gid, ip->i_d.di_projid, > + qflags, &udqp, &gdqp); > if (code) > return code; > } > @@ -219,9 +212,7 @@ xfs_setattr( > * Only the owner or users with CAP_FOWNER > * capability may do these things. > */ > - if (mask & > - (XFS_AT_MODE|XFS_AT_XFLAGS|XFS_AT_EXTSIZE|XFS_AT_UID| > - XFS_AT_GID|XFS_AT_PROJID)) { > + if (mask & (XFS_AT_MODE|XFS_AT_UID|XFS_AT_GID)) { > /* > * CAP_FOWNER overrides the following restrictions: > * > @@ -270,7 +261,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|XFS_AT_PROJID)) { > + if (mask & (XFS_AT_UID|XFS_AT_GID)) { > /* > * These IDs could have changed since we last looked at them. > * But, we're assured that if the ownership did change > @@ -278,12 +269,9 @@ xfs_setattr( > * would have changed also. > */ > iuid = ip->i_d.di_uid; > - iprojid = ip->i_d.di_projid; > igid = ip->i_d.di_gid; > gid = (mask & XFS_AT_GID) ? vap->va_gid : igid; > uid = (mask & XFS_AT_UID) ? vap->va_uid : iuid; > - projid = (mask & XFS_AT_PROJID) ? (xfs_prid_t)vap->va_projid : > - iprojid; > > /* > * CAP_CHOWN overrides the following restrictions: > @@ -303,11 +291,10 @@ xfs_setattr( > goto error_return; > } > /* > - * Do a quota reservation only if uid/projid/gid is actually > + * Do a quota reservation only if uid/gid is actually > * going to change. > */ > if ((XFS_IS_UQUOTA_ON(mp) && iuid != uid) || > - (XFS_IS_PQUOTA_ON(mp) && iprojid != projid) || > (XFS_IS_GQUOTA_ON(mp) && igid != gid)) { > ASSERT(tp); > code = XFS_QM_DQVOPCHOWNRESV(mp, tp, ip, udqp, gdqp, > @@ -361,78 +348,6 @@ xfs_setattr( > } > > /* > - * Change extent size or realtime flag. > - */ > - if (mask & (XFS_AT_EXTSIZE|XFS_AT_XFLAGS)) { > - /* > - * Can't change extent size if any extents are allocated. > - */ > - if (ip->i_d.di_nextents && (mask & XFS_AT_EXTSIZE) && > - ((ip->i_d.di_extsize << mp->m_sb.sb_blocklog) != > - vap->va_extsize) ) { > - code = XFS_ERROR(EINVAL); /* EFBIG? */ > - goto error_return; > - } > - > - /* > - * Can't change realtime flag if any extents are allocated. > - */ > - if ((ip->i_d.di_nextents || ip->i_delayed_blks) && > - (mask & XFS_AT_XFLAGS) && > - (XFS_IS_REALTIME_INODE(ip)) != > - (vap->va_xflags & XFS_XFLAG_REALTIME)) { > - code = XFS_ERROR(EINVAL); /* EFBIG? */ > - goto error_return; > - } > - /* > - * Extent size must be a multiple of the appropriate block > - * size, if set at all. > - */ > - if ((mask & XFS_AT_EXTSIZE) && vap->va_extsize != 0) { > - xfs_extlen_t size; > - > - if (XFS_IS_REALTIME_INODE(ip) || > - ((mask & XFS_AT_XFLAGS) && > - (vap->va_xflags & XFS_XFLAG_REALTIME))) { > - size = mp->m_sb.sb_rextsize << > - mp->m_sb.sb_blocklog; > - } else { > - size = mp->m_sb.sb_blocksize; > - } > - if (vap->va_extsize % size) { > - code = XFS_ERROR(EINVAL); > - goto error_return; > - } > - } > - /* > - * If realtime flag is set then must have realtime data. > - */ > - if ((mask & XFS_AT_XFLAGS) && > - (vap->va_xflags & XFS_XFLAG_REALTIME)) { > - if ((mp->m_sb.sb_rblocks == 0) || > - (mp->m_sb.sb_rextsize == 0) || > - (ip->i_d.di_extsize % mp->m_sb.sb_rextsize)) { > - code = XFS_ERROR(EINVAL); > - goto error_return; > - } > - } > - > - /* > - * Can't modify an immutable/append-only file unless > - * we have appropriate permission. > - */ > - if ((mask & XFS_AT_XFLAGS) && > - (ip->i_d.di_flags & > - (XFS_DIFLAG_IMMUTABLE|XFS_DIFLAG_APPEND) || > - (vap->va_xflags & > - (XFS_XFLAG_IMMUTABLE | XFS_XFLAG_APPEND))) && > - !capable(CAP_LINUX_IMMUTABLE)) { > - code = XFS_ERROR(EPERM); > - goto error_return; > - } > - } > - > - /* > * Now we can make the changes. Before we join the inode > * to the transaction, if XFS_AT_SIZE is set then take care of > * the part of the truncation that must be done without the > @@ -568,7 +483,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|XFS_AT_PROJID)) { > + if (mask & (XFS_AT_UID|XFS_AT_GID)) { > /* > * CAP_FSETID overrides the following restrictions: > * > @@ -603,23 +518,6 @@ xfs_setattr( > } > ip->i_d.di_gid = gid; > } > - if (iprojid != projid) { > - if (XFS_IS_PQUOTA_ON(mp)) { > - ASSERT(!XFS_IS_GQUOTA_ON(mp)); > - ASSERT(mask & XFS_AT_PROJID); > - ASSERT(gdqp); > - olddquot2 = XFS_QM_DQVOPCHOWN(mp, tp, ip, > - &ip->i_gdquot, gdqp); > - } > - ip->i_d.di_projid = projid; > - /* > - * We may have to rev the inode as well as > - * the superblock version number since projids didn't > - * exist before DINODE_VERSION_2 and SB_VERSION_NLINK. > - */ > - if (ip->i_d.di_version == XFS_DINODE_VERSION_1) > - xfs_bump_ino_vers2(tp, ip); > - } > > xfs_trans_log_inode (tp, ip, XFS_ILOG_CORE); > timeflags |= XFS_ICHGTIME_CHG; > @@ -647,57 +545,6 @@ xfs_setattr( > } > > /* > - * Change XFS-added attributes. > - */ > - if (mask & (XFS_AT_EXTSIZE|XFS_AT_XFLAGS)) { > - if (mask & XFS_AT_EXTSIZE) { > - /* > - * Converting bytes to fs blocks. > - */ > - ip->i_d.di_extsize = vap->va_extsize >> > - mp->m_sb.sb_blocklog; > - } > - if (mask & XFS_AT_XFLAGS) { > - uint di_flags; > - > - /* can't set PREALLOC this way, just preserve it */ > - di_flags = (ip->i_d.di_flags & XFS_DIFLAG_PREALLOC); > - if (vap->va_xflags & XFS_XFLAG_IMMUTABLE) > - di_flags |= XFS_DIFLAG_IMMUTABLE; > - if (vap->va_xflags & XFS_XFLAG_APPEND) > - di_flags |= XFS_DIFLAG_APPEND; > - if (vap->va_xflags & XFS_XFLAG_SYNC) > - di_flags |= XFS_DIFLAG_SYNC; > - if (vap->va_xflags & XFS_XFLAG_NOATIME) > - di_flags |= XFS_DIFLAG_NOATIME; > - if (vap->va_xflags & XFS_XFLAG_NODUMP) > - di_flags |= XFS_DIFLAG_NODUMP; > - if (vap->va_xflags & XFS_XFLAG_PROJINHERIT) > - di_flags |= XFS_DIFLAG_PROJINHERIT; > - if (vap->va_xflags & XFS_XFLAG_NODEFRAG) > - di_flags |= XFS_DIFLAG_NODEFRAG; > - if (vap->va_xflags & XFS_XFLAG_FILESTREAM) > - di_flags |= XFS_DIFLAG_FILESTREAM; > - if ((ip->i_d.di_mode & S_IFMT) == S_IFDIR) { > - if (vap->va_xflags & XFS_XFLAG_RTINHERIT) > - di_flags |= XFS_DIFLAG_RTINHERIT; > - if (vap->va_xflags & XFS_XFLAG_NOSYMLINKS) > - di_flags |= XFS_DIFLAG_NOSYMLINKS; > - if (vap->va_xflags & XFS_XFLAG_EXTSZINHERIT) > - di_flags |= XFS_DIFLAG_EXTSZINHERIT; > - } else if ((ip->i_d.di_mode & S_IFMT) == S_IFREG) { > - if (vap->va_xflags & XFS_XFLAG_REALTIME) > - di_flags |= XFS_DIFLAG_REALTIME; > - if (vap->va_xflags & XFS_XFLAG_EXTSIZE) > - di_flags |= XFS_DIFLAG_EXTSIZE; > - } > - ip->i_d.di_flags = di_flags; > - } > - xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); > - timeflags |= XFS_ICHGTIME_CHG; > - } > - > - /* > * Change file inode change time only if XFS_AT_CTIME set > * AND we have been called by a DMI function. > */ > From owner-xfs@oss.sgi.com Mon Jul 7 11:30:55 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Jul 2008 11:31:19 -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,J_CHICKENPOX_27 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 m67IUtIY013065 for ; Mon, 7 Jul 2008 11:30:55 -0700 X-ASG-Debug-ID: 1215455519-70a603190000-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 068782C3489 for ; Mon, 7 Jul 2008 11:31:59 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id Gt7spVsUoU5KWIuD for ; Mon, 07 Jul 2008 11:31:59 -0700 (PDT) Received: by lucidpixels.com (Postfix, from userid 1001) id 8B33B5A568; Mon, 7 Jul 2008 14:31:58 -0400 (EDT) Date: Mon, 7 Jul 2008 14:31:57 -0400 (EDT) From: Justin Piszcz To: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: 12 Veliciraptors again w/x4 card (~1gbyte/sec aggregate read)! Subject: 12 Veliciraptors again w/x4 card (~1gbyte/sec aggregate read)! 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: 1215455520 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.55412 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: 16771 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 Each PCI-e x1 card has 1 veliciraptor on it now. Got an x4 card wit 4 sata ports: Not quite the > 1 gbyte/sec I was hoping for in regards to the reads but pretty close! (For my RAID5) Previously my write was limited to 400-420MiB/s now I see an additional 120-125 MiB/s increase! jpiszcz@p34:/x/f$ dd if=/dev/zero of=bigfile bs=1M count=10240 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 20.7054 s, 519 MB/s jpiszcz@p34:/x/f$ sync jpiszcz@p34:/x/f$ dd if=/dev/zero of=bigfile.1 bs=1M count=10240 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 20.4973 s, 524 MB/s jpiszcz@p34:/x/f$ sync jpiszcz@p34:/x/f$ dd if=bigfile of=/dev/null bs=1M count=10240 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 11.3529 s, 946 MB/s jpiszcz@p34:/x/f$ sync jpiszcz@p34:/x/f$ dd if=bigfile.1 of=/dev/null bs=1M count=10240 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 11.2635 s, 953 MB/s jpiszcz@p34:/x/f$ -- For all disks: Something I noticed is the x1 PCI-e cards are doing around 68MiB/s each for 3 of them where the x4 has no issue pumping out 100MiB/s+ without a problem, however keep in mind the bus is probably already taxed from the 6 sata drives on the southbridge. vmstat output: procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu---- 1 VR 0 1 160 45220 341772 6480468 0 0 122112 0 584 2082 1 7 73 20 0 1 160 46592 455436 6362088 0 0 113664 0 495 1968 0 4 74 21 2 VR 1 1 160 45540 3027724 3720340 0 0 243216 0 1006 4030 0 9 74 17 0 2 160 44988 3262220 3480648 0 0 234480 0 1008 4134 0 8 73 19 3 VR 1 2 160 44816 6600068 50476 0 0 330248 16 1342 4126 0 12 70 18 0 3 160 45440 6599812 50264 0 0 316032 8 1296 3878 0 12 72 17 4 VR 0 4 160 44504 6602488 47644 0 0 495232 0 1992 6081 0 20 57 23 1 3 160 45500 6602796 45980 0 0 483968 0 1915 6207 0 20 54 26 5 VR 1 5 160 43932 6602972 45304 0 0 606080 0 2375 6622 0 25 56 19 1 4 160 45412 6601852 45160 0 0 618756 0 2431 6791 0 25 53 21 6 VR 0 6 160 45000 6602348 44512 0 0 683904 8 2746 7880 0 31 42 27 0 6 160 45248 6602028 44460 0 0 705792 0 2754 7564 0 31 45 24 7 VR 2 6 160 46744 6599020 44688 0 0 748204 17 3042 9084 0 34 40 26 3 6 160 46592 6598824 44372 0 0 747520 8 2975 9047 1 33 31 36 8 VR 2 7 160 46512 6598612 44580 0 0 761184 16 3089 9937 0 36 40 24 2 7 160 44528 6600392 44360 0 0 759720 8 2993 9522 0 36 36 28 9 VR 2 8 160 47152 6596824 44572 0 0 767016 0 3075 9730 1 37 39 24 2 7 160 46576 6597728 44688 0 0 771200 0 3032 9568 0 37 40 23 10 VR 0 10 160 45048 6598240 44428 0 0 889072 8 3599 11561 0 47 20 33 2 10 160 45232 6598116 44772 0 0 890112 0 3495 11547 0 46 23 31 11 VR 4 8 160 45536 6594716 44600 0 0 996352 0 3947 12134 1 62 13 25 2 9 160 45348 6594912 44096 0 0 1009152 0 3949 11949 0 63 10 28 12 VR 6 8 160 45092 6583136 47016 0 0 1063200 0 4187 12394 1 71 9 21 3 11 160 47080 6578492 47588 0 0 1058412 0 4224 12547 1 72 8 20 Just about 1 gigabyte per second total aggregate read for all drives on a 965 chipset! Justin. From owner-xfs@oss.sgi.com Mon Jul 7 11:36:28 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Jul 2008 11:36: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=-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 m67IaSCq013719 for ; Mon, 7 Jul 2008 11:36:28 -0700 X-ASG-Debug-ID: 1215455852-1b3300000000-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 56D77DB15FA for ; Mon, 7 Jul 2008 11:37:32 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id hDX17cvsb0T2wRsX for ; Mon, 07 Jul 2008 11:37:32 -0700 (PDT) Received: by lucidpixels.com (Postfix, from userid 1001) id 45FBC5A56A; Mon, 7 Jul 2008 14:37:32 -0400 (EDT) Date: Mon, 7 Jul 2008 14:37:31 -0400 (EDT) From: Justin Piszcz To: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: 12 Veliciraptors again w/x4 card (~1gbyte/sec aggregate read)! Subject: Re: 12 Veliciraptors again w/x4 card (~1gbyte/sec aggregate read)! In-Reply-To: Message-ID: References: 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: 1215455853 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.55412 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: 16772 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 Mon, 7 Jul 2008, Justin Piszcz wrote: > Each PCI-e x1 card has 1 veliciraptor on it now. > Got an x4 card wit 4 sata ports: > > Not quite the > 1 gbyte/sec I was hoping for in regards to the reads > but pretty close! Going to remove one of the drives from the x1 card and put it on the x4 card instead, then I will use all 4 SATA ports on the x4 and hopefully get better bw. If you look at 7,8,9 there is little improvement: (PCI-e x1) 7 VR 2 6 160 46744 6599020 44688 0 0 748204 17 3042 9084 0 34 40 26 3 6 160 46592 6598824 44372 0 0 747520 8 2975 9047 1 33 31 36 8 VR 2 7 160 46512 6598612 44580 0 0 761184 16 3089 9937 0 36 40 24 2 7 160 44528 6600392 44360 0 0 759720 8 2993 9522 0 36 36 28 9 VR 2 8 160 47152 6596824 44572 0 0 767016 0 3075 9730 1 37 39 24 2 7 160 46576 6597728 44688 0 0 771200 0 3032 9568 0 37 40 23 But once I hit the drives on the x4 card, vroom vroom! 10 VR 0 10 160 45048 6598240 44428 0 0 889072 8 3599 11561 0 47 20 33 2 10 160 45232 6598116 44772 0 0 890112 0 3495 11547 0 46 23 31 11 VR 4 8 160 45536 6594716 44600 0 0 996352 0 3947 12134 1 62 13 25 2 9 160 45348 6594912 44096 0 0 1009152 0 3949 11949 0 63 10 28 12 VR 6 8 160 45092 6583136 47016 0 0 1063200 0 4187 12394 1 71 9 21 3 11 160 47080 6578492 47588 0 0 1058412 0 4224 12547 1 72 8 20 Justin. From owner-xfs@oss.sgi.com Mon Jul 7 11:45:26 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Jul 2008 11:45: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=-1.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 m67IjPRh014564 for ; Mon, 7 Jul 2008 11:45:25 -0700 X-ASG-Debug-ID: 1215456389-68fc00a70000-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 78DCE188738B for ; Mon, 7 Jul 2008 11:46:29 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id zKX8fPDbbdWbNjbe for ; Mon, 07 Jul 2008 11:46:29 -0700 (PDT) Received: by lucidpixels.com (Postfix, from userid 1001) id 44E0E5A562; Mon, 7 Jul 2008 14:46:29 -0400 (EDT) Date: Mon, 7 Jul 2008 14:46:28 -0400 (EDT) From: Justin Piszcz To: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, xfs@oss.sgi.com cc: Alan Piszcz X-ASG-Orig-Subj: Re: 12 Veliciraptors again w/x4 card (1.1gbytes/sec aggregate read)! Subject: Re: 12 Veliciraptors again w/x4 card (1.1gbytes/sec aggregate read)! In-Reply-To: Message-ID: References: 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: 1215456390 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.55412 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: 16773 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 Mon, 7 Jul 2008, Justin Piszcz wrote: > > > On Mon, 7 Jul 2008, Justin Piszcz wrote: > >> Each PCI-e x1 card has 1 veliciraptor on it now. >> Got an x4 card wit 4 sata ports: >> >> Not quite the > 1 gbyte/sec I was hoping for in regards to the reads >> but pretty close! > > Going to remove one of the drives from the x1 card and put it on the x4 > card instead, then I will use all 4 SATA ports on the x4 and hopefully get > better bw. > Four drives on the x4 card, MAX bandwidth for every disk. p34:~# dd if=/dev/sdi of=/dev/null bs=1M & [1] 4720 p34:~# dd if=/dev/sdj of=/dev/null bs=1M & [2] 4721 p34:~# dd if=/dev/sdk of=/dev/null bs=1M & [3] 4722 p34:~# dd if=/dev/sdl of=/dev/null bs=1M & [4] 4723 p34:~# 120MiB/s per each one! Re-running dd test with all 12 disks: 1.1 gigabytes per second read! r b swpd free buff cache si so bi bo in cs us sy id wa 1 0 120 59104 6632220 52228 0 0 0 40 168 517 0 0 100 0 0 0 120 59104 6632220 52228 0 0 0 0 20 291 0 0 100 0 3 10 120 43516 6635576 51924 0 0 1051776 62 4221 12301 1 70 11 19 6 9 160 44420 6634720 51788 0 0 1117284 0 4435 12308 1 75 5 19 6 9 160 47436 6631100 51676 0 0 1110300 0 4449 11438 1 76 3 20 2 10 160 46740 6632048 51948 0 0 1137920 0 4447 12251 1 75 8 17 9 7 160 45248 6632056 52004 0 8 1127940 45 4559 13259 1 74 9 17 3 9 160 44152 6634780 49960 0 0 1132032 12 4471 12962 0 75 8 16 4 9 160 44160 6634960 49380 0 0 1129216 8 4430 12545 0 76 7 16 After: About the same for write: $ dd if=/dev/zero of=bigfile.1 bs=1M count=10240 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 20.4056 s, 526 MB/s 'nuff said for read :) $ dd if=bigfile.1 of=/dev/null bs=1M count=10240 10240+0 records in 10240+0 records out 10737418240 bytes (11 GB) copied, 10.2841 s, 1.0 GB/s Justin. From owner-xfs@oss.sgi.com Mon Jul 7 15:05:49 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Jul 2008 15:05:52 -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 m67M5lvV032661 for ; Mon, 7 Jul 2008 15:05:49 -0700 X-ASG-Debug-ID: 1215468411-726602890000-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 86403DB9CCD for ; Mon, 7 Jul 2008 15:06:51 -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 DegRA0AybAJWSdea for ; Mon, 07 Jul 2008 15:06:51 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALAvckh5LBzp/2dsb2JhbACxLA X-IronPort-AV: E=Sophos;i="4.30,318,1212330600"; d="scan'208";a="143919718" 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; 08 Jul 2008 07:36:49 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KFyr9-0006nX-W2; Tue, 08 Jul 2008 08:06:47 +1000 Date: Tue, 8 Jul 2008 08:06:47 +1000 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: <20080707220647.GN29319@disturbed> Mail-Followup-To: Jens Beyer , xfs@oss.sgi.com References: <20080704064126.GA14847@webde.de> <20080704075941.GP16257@build-svl-1.agami.com> <20080707080409.GA18390@webde.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080707080409.GA18390@webde.de> 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: 1215468412 X-Barracuda-Bayes: INNOCENT GLOBAL 0.4731 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.55424 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: 16774 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 Mon, Jul 07, 2008 at 10:04:09AM +0200, Jens Beyer wrote: > On Fri, Jul 04, 2008 at 12:59:41AM -0700, Dave Chinner wrote: > > On Fri, Jul 04, 2008 at 08:41:26AM +0200, Jens Beyer wrote: > > > > > > 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. > > But then - why does the rate of ext3 does not decrease and stays at the > higher value? Because XFS spreads the data and metadata across the entire filesystem, not just a small portion. It's one of the reasons XFS can make decent use of lots of disks effectively. Grab seekwatcher traces from your workload for the different filesystems and you'll see what I mean.... Cheers,, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Mon Jul 7 16:11:55 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Jul 2008 16:11:59 -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.0 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 m67NBtBP004521 for ; Mon, 7 Jul 2008 16:11:55 -0700 X-ASG-Debug-ID: 1215472379-2b2f03da0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from mail.ukfsn.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0FAF3DBA688 for ; Mon, 7 Jul 2008 16:12:59 -0700 (PDT) Received: from mail.ukfsn.org (mx1.ukfsn.org [77.75.108.10]) by cuda.sgi.com with ESMTP id hTz2Fs7pqYjB8SHY for ; Mon, 07 Jul 2008 16:12:59 -0700 (PDT) Received: from localhost (smtp-filter.ukfsn.org [192.168.54.205]) by mail.ukfsn.org (Postfix) with ESMTP id 98611DECED; Tue, 8 Jul 2008 00:22:42 +0100 (BST) Received: from mail.ukfsn.org ([192.168.54.25]) by localhost (smtp-filter.ukfsn.org [192.168.54.205]) (amavisd-new, port 10024) with ESMTP id EQtN1aZ+JHbj; Mon, 7 Jul 2008 23:05:59 +0100 (BST) Received: from elm.dgreaves.com (78-32-229-233.no-dns-yet.enta.net [78.32.229.233]) by mail.ukfsn.org (Postfix) with ESMTP id 609B0DECE6; Tue, 8 Jul 2008 00:22:41 +0100 (BST) Received: from ash.dgreaves.com ([10.0.0.90]) by elm.dgreaves.com with esmtp (Exim 4.62) (envelope-from ) id 1KFzt6-0007ji-VB; Tue, 08 Jul 2008 00:12:53 +0100 Message-ID: <4872A2F4.2010604@dgreaves.com> Date: Tue, 08 Jul 2008 00:12:52 +0100 From: David Greaves User-Agent: Mozilla-Thunderbird 2.0.0.14 (X11/20080509) MIME-Version: 1.0 To: Justin Piszcz CC: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: 12 Veliciraptors again w/x4 card (~1gbyte/sec aggregate read)! Subject: Re: 12 Veliciraptors again w/x4 card (~1gbyte/sec aggregate read)! References: In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Barracuda-Connect: mx1.ukfsn.org[77.75.108.10] X-Barracuda-Start-Time: 1215472380 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.55429 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: 16775 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: david@dgreaves.com Precedence: bulk X-list: xfs Justin Piszcz wrote: > Each PCI-e x1 card has 1 veliciraptor on it now. > Got an x4 card wit 4 sata ports: Useful - which card? David From owner-xfs@oss.sgi.com Mon Jul 7 19:54:28 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Jul 2008 19:54:32 -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 m682sSbr019949 for ; Mon, 7 Jul 2008 19:54:28 -0700 X-ASG-Debug-ID: 1215485732-7e8100910000-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 2C6832C6677 for ; Mon, 7 Jul 2008 19:55:32 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id bjH1qFW1L9za1c7O for ; Mon, 07 Jul 2008 19:55:32 -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 BDDC9AC3593 for ; Mon, 7 Jul 2008 21:55:31 -0500 (CDT) Message-ID: <4872D725.5070306@sandeen.net> Date: Mon, 07 Jul 2008 21:55:33 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: xfs mailing list X-ASG-Orig-Subj: Re: [PATCH] convert xfs to use ERR_CAST Subject: Re: [PATCH] convert xfs to use ERR_CAST References: <480FA737.5030001@sandeen.net> In-Reply-To: <480FA737.5030001@sandeen.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: 1215485733 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.55444 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: 16776 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 Eric Sandeen wrote: > Looks like somehow xfs got missed in the conversion that > took place in e231c2ee64eb1c5cd3c63c31da9dac7d888dcf7f, > "Convert ERR_PTR(PTR_ERR(p)) instances to ERR_CAST(p) " > > Signed-off-by: Eric Sandeen > --- ping. This one's really, really, really easy :) -Eric > ndex: linux-2.6-xfs/fs/xfs/linux-2.6/xfs_export.c > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/linux-2.6/xfs_export.c > +++ linux-2.6-xfs/fs/xfs/linux-2.6/xfs_export.c > @@ -167,7 +167,7 @@ xfs_fs_fh_to_dentry(struct super_block * > if (!inode) > return NULL; > if (IS_ERR(inode)) > - return ERR_PTR(PTR_ERR(inode)); > + return ERR_CAST(inode); > result = d_alloc_anon(inode); > if (!result) { > iput(inode); > @@ -198,7 +198,7 @@ xfs_fs_fh_to_parent(struct super_block * > if (!inode) > return NULL; > if (IS_ERR(inode)) > - return ERR_PTR(PTR_ERR(inode)); > + return ERR_CAST(inode); > result = d_alloc_anon(inode); > if (!result) { > iput(inode); > > > From owner-xfs@oss.sgi.com Mon Jul 7 20:04:08 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Jul 2008 20:04: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=-0.6 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, SUBJ_FRIEND 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 m68348n5020644 for ; Mon, 7 Jul 2008 20:04:08 -0700 X-ASG-Debug-ID: 1215486313-55e500f80000-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 6039918890B1 for ; Mon, 7 Jul 2008 20:05:13 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id YOMHEwJ0FnZO54v2 for ; Mon, 07 Jul 2008 20:05:13 -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 D9462AC3593 for ; Mon, 7 Jul 2008 22:05:12 -0500 (CDT) Message-ID: <4872D96A.7070703@sandeen.net> Date: Mon, 07 Jul 2008 22:05:14 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: xfs-oss X-ASG-Orig-Subj: Re: [PATCH] remove INT_GET and friends Subject: Re: [PATCH] remove INT_GET and friends References: <47FF794C.4020801@sandeen.net> In-Reply-To: <47FF794C.4020801@sandeen.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: 1215486313 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.55444 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: 16777 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 Eric Sandeen wrote: > Thanks to hch's endian work, INT_GET etc are no longer used, > and may as well be removed. INT_SET is still used in > the acl code, though. > > Signed-off-by: Eric Sandeen > --- > > xfs_arch.h | 68 --------------------------------- > 1 files changed, 68 deletions(-) > Ping? these are just unused macros. -Eric > > Index: linux-2.6-xfs/fs/xfs/xfs_arch.h > =================================================================== > --- linux-2.6-xfs.orig/fs/xfs/xfs_arch.h > +++ linux-2.6-xfs/fs/xfs/xfs_arch.h > @@ -92,16 +92,6 @@ > ((__u8*)(pointer))[1] = (((value) ) & 0xff); \ > } > > -/* define generic INT_ macros */ > - > -#define INT_GET(reference,arch) \ > - (((arch) == ARCH_NOCONVERT) \ > - ? \ > - (reference) \ > - : \ > - INT_SWAP((reference),(reference)) \ > - ) > - > /* does not return a value */ > #define INT_SET(reference,arch,valueref) \ > (__builtin_constant_p(valueref) ? \ > @@ -112,64 +102,6 @@ > ) \ > ) > > -/* does not return a value */ > -#define INT_MOD_EXPR(reference,arch,code) \ > - (((arch) == ARCH_NOCONVERT) \ > - ? \ > - (void)((reference) code) \ > - : \ > - (void)( \ > - (reference) = INT_GET((reference),arch) , \ > - ((reference) code), \ > - INT_SET(reference, arch, reference) \ > - ) \ > - ) > - > -/* does not return a value */ > -#define INT_MOD(reference,arch,delta) \ > - (void)( \ > - INT_MOD_EXPR(reference,arch,+=(delta)) \ > - ) > - > -/* > - * INT_COPY - copy a value between two locations with the > - * _same architecture_ but _potentially different sizes_ > - * > - * if the types of the two parameters are equal or they are > - * in native architecture, a simple copy is done > - * > - * otherwise, architecture conversions are done > - * > - */ > - > -/* does not return a value */ > -#define INT_COPY(dst,src,arch) \ > - ( \ > - ((sizeof(dst) == sizeof(src)) || ((arch) == ARCH_NOCONVERT)) \ > - ? \ > - (void)((dst) = (src)) \ > - : \ > - INT_SET(dst, arch, INT_GET(src, arch)) \ > - ) > - > -/* > - * INT_XLATE - copy a value in either direction between two locations > - * with different architectures > - * > - * dir < 0 - copy from memory to buffer (native to arch) > - * dir > 0 - copy from buffer to memory (arch to native) > - */ > - > -/* does not return a value */ > -#define INT_XLATE(buf,mem,dir,arch) {\ > - ASSERT(dir); \ > - if (dir>0) { \ > - (mem)=INT_GET(buf, arch); \ > - } else { \ > - INT_SET(buf, arch, mem); \ > - } \ > -} > - > static inline void be16_add(__be16 *a, __s16 b) > { > *a = cpu_to_be16(be16_to_cpu(*a) + b); > > > From owner-xfs@oss.sgi.com Mon Jul 7 20:07:57 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Jul 2008 20:07:59 -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 m6837uDv021065 for ; Mon, 7 Jul 2008 20:07:56 -0700 X-ASG-Debug-ID: 1215486541-56a803370000-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 A80CB2C6840 for ; Mon, 7 Jul 2008 20:09:01 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id yRCKbSk9acAwyN4D for ; Mon, 07 Jul 2008 20:09:01 -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 B9534AC3593; Mon, 7 Jul 2008 22:09:00 -0500 (CDT) Message-ID: <4872DA4E.3040405@sandeen.net> Date: Mon, 07 Jul 2008 22:09:02 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Christoph Hellwig CC: nscott@aconex.com, xfs-oss X-ASG-Orig-Subj: Re: [PATCH, RFC] - remove mountpoint UUID code Subject: Re: [PATCH, RFC] - remove mountpoint UUID code References: <47D20F78.7000103@sandeen.net> <1205196252.15982.69.camel@edge.scott.net.au> <47D5DE13.8030902@sandeen.net> <34665.192.168.3.1.1205266196.squirrel@mail.aconex.com> <20080312072259.GA26148@infradead.org> In-Reply-To: <20080312072259.GA26148@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: 1215486541 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=COMMA_SUBJECT X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.55444 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.60 COMMA_SUBJECT Subject is like 'Re: FDSDS, this is a subject' 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: 16778 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: > On Wed, Mar 12, 2008 at 07:09:56AM +1100, nscott@aconex.com wrote: >> I don't have any immediate plans. I can imagine it could be used to >> stitch parts of the namespace together in a filesystem that supports >> multiple devices (in a chunkfs kinda way) ... or maybe more simply >> just an in-filesystem auto-mounter. *shrug*. But its there, the tools >> support it (once again, I didn't see a userspace patch - hohum), so I >> would vote for leaving it in its current form so some enterprising, >> constructive young coder can try to make something useful from it >> at some point. :) > > That kind of automounter really doesn't belong into the low-level > filesystem. If we really wanted it it would go into the VFS, storing > the uuid or other identifier for the mountpoint in an xattr. This is > really just dead junk that should go away. Can I get a yea or nay on this from sgi, then? Thanks, -Eric From owner-xfs@oss.sgi.com Mon Jul 7 20:27:52 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Jul 2008 20:27: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_61, J_CHICKENPOX_64 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 m683RqHx026698 for ; Mon, 7 Jul 2008 20:27:52 -0700 X-ASG-Debug-ID: 1215487735-092901310000-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 D817A2C6098 for ; Mon, 7 Jul 2008 20:28:55 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id 2xb8or1kFH8UUaBx for ; Mon, 07 Jul 2008 20:28:55 -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 528B1AC3593 for ; Mon, 7 Jul 2008 22:28:55 -0500 (CDT) Message-ID: <4872DEF8.6060704@sandeen.net> Date: Mon, 07 Jul 2008 22:28:56 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: xfs-oss X-ASG-Orig-Subj: [PATCH] remove shouting-indirection macros from xfs_trans.h Subject: [PATCH] remove shouting-indirection macros from xfs_trans.h 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: 1215487736 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.55445 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: 16779 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 compile-tested, fairly easy to inspect with: quilt diff --diff="diff -iu" Signed-off-by: Eric Sandeen --- xfs_bmap.c | 6 ++--- xfs_trans.c | 12 +++++----- xfs_trans.h | 11 --------- xfs_trans_buf.c | 12 +++++----- xfs_trans_item.c | 66 +++++++++++++++++++++++++++---------------------------- xfsidbg.c | 6 ++--- 6 files changed, 51 insertions(+), 62 deletions(-) Index: linux/fs/xfs/xfs_bmap.c =================================================================== RCS file: /cvs/xfs-linux/xfs_bmap.c,v retrieving revision 1.394 diff -u -r1.394 xfs_bmap.c --- linux/fs/xfs/xfs_bmap.c 20 Jun 2008 16:19:53 -0000 1.394 +++ linux/fs/xfs/xfs_bmap.c 8 Jul 2008 03:24:32 -0000 @@ -6096,7 +6096,7 @@ tp = cur->bc_tp; licp = &tp->t_items; while (!bp && licp != NULL) { - if (XFS_LIC_ARE_ALL_FREE(licp)) { + if (xfs_lic_are_all_free(licp)) { licp = licp->lic_next; continue; } @@ -6106,11 +6106,11 @@ xfs_buf_log_item_t *bip; xfs_buf_t *lbp; - if (XFS_LIC_ISFREE(licp, i)) { + if (xfs_lic_isfree(licp, i)) { continue; } - lidp = XFS_LIC_SLOT(licp, i); + lidp = xfs_lic_slot(licp, i); lip = lidp->lid_item; if (lip->li_type != XFS_LI_BUF) continue; Index: linux/fs/xfs/xfs_trans.c =================================================================== RCS file: /cvs/xfs-linux/xfs_trans.c,v retrieving revision 1.185 diff -u -r1.185 xfs_trans.c --- linux/fs/xfs/xfs_trans.c 9 May 2008 04:27:47 -0000 1.185 +++ linux/fs/xfs/xfs_trans.c 8 Jul 2008 03:24:32 -0000 @@ -253,7 +253,7 @@ tp->t_mountp = mp; tp->t_items_free = XFS_LIC_NUM_SLOTS; tp->t_busy_free = XFS_LBC_NUM_SLOTS; - XFS_LIC_INIT(&(tp->t_items)); + xfs_lic_init(&(tp->t_items)); XFS_LBC_INIT(&(tp->t_busy)); return tp; } @@ -282,7 +282,7 @@ ntp->t_mountp = tp->t_mountp; ntp->t_items_free = XFS_LIC_NUM_SLOTS; ntp->t_busy_free = XFS_LBC_NUM_SLOTS; - XFS_LIC_INIT(&(ntp->t_items)); + xfs_lic_init(&(ntp->t_items)); XFS_LBC_INIT(&(ntp->t_busy)); ASSERT(tp->t_flags & XFS_TRANS_PERM_LOG_RES); @@ -1169,7 +1169,7 @@ while (licp != NULL) { lidp = licp->lic_descs; for (i = 0; i < licp->lic_unused; i++, lidp++) { - if (XFS_LIC_ISFREE(licp, i)) { + if (xfs_lic_isfree(licp, i)) { continue; } @@ -1253,7 +1253,7 @@ * Special case the chunk embedded in the transaction. */ licp = &(tp->t_items); - if (!(XFS_LIC_ARE_ALL_FREE(licp))) { + if (!(xfs_lic_are_all_free(licp))) { xfs_trans_chunk_committed(licp, tp->t_lsn, abortflag); } @@ -1262,7 +1262,7 @@ */ licp = licp->lic_next; while (licp != NULL) { - ASSERT(!XFS_LIC_ARE_ALL_FREE(licp)); + ASSERT(!xfs_lic_are_all_free(licp)); xfs_trans_chunk_committed(licp, tp->t_lsn, abortflag); next_licp = licp->lic_next; kmem_free(licp); @@ -1325,7 +1325,7 @@ lidp = licp->lic_descs; for (i = 0; i < licp->lic_unused; i++, lidp++) { - if (XFS_LIC_ISFREE(licp, i)) { + if (xfs_lic_isfree(licp, i)) { continue; } Index: linux/fs/xfs/xfs_trans.h =================================================================== RCS file: /cvs/xfs-linux/xfs_trans.h,v retrieving revision 1.149 diff -u -r1.149 xfs_trans.h --- linux/fs/xfs/xfs_trans.h 11 Mar 2008 15:02:32 -0000 1.149 +++ linux/fs/xfs/xfs_trans.h 8 Jul 2008 03:24:33 -0000 @@ -210,62 +210,52 @@ * lic_unused to the right value (0 matches all free). The * lic_descs.lid_index values are set up as each desc is allocated. */ -#define XFS_LIC_INIT(cp) xfs_lic_init(cp) static inline void xfs_lic_init(xfs_log_item_chunk_t *cp) { cp->lic_free = XFS_LIC_FREEMASK; } -#define XFS_LIC_INIT_SLOT(cp,slot) xfs_lic_init_slot(cp, slot) static inline void xfs_lic_init_slot(xfs_log_item_chunk_t *cp, int slot) { cp->lic_descs[slot].lid_index = (unsigned char)(slot); } -#define XFS_LIC_VACANCY(cp) xfs_lic_vacancy(cp) static inline int xfs_lic_vacancy(xfs_log_item_chunk_t *cp) { return cp->lic_free & XFS_LIC_FREEMASK; } -#define XFS_LIC_ALL_FREE(cp) xfs_lic_all_free(cp) static inline void xfs_lic_all_free(xfs_log_item_chunk_t *cp) { cp->lic_free = XFS_LIC_FREEMASK; } -#define XFS_LIC_ARE_ALL_FREE(cp) xfs_lic_are_all_free(cp) static inline int xfs_lic_are_all_free(xfs_log_item_chunk_t *cp) { return ((cp->lic_free & XFS_LIC_FREEMASK) == XFS_LIC_FREEMASK); } -#define XFS_LIC_ISFREE(cp,slot) xfs_lic_isfree(cp,slot) static inline int xfs_lic_isfree(xfs_log_item_chunk_t *cp, int slot) { return (cp->lic_free & (1 << slot)); } -#define XFS_LIC_CLAIM(cp,slot) xfs_lic_claim(cp,slot) static inline void xfs_lic_claim(xfs_log_item_chunk_t *cp, int slot) { cp->lic_free &= ~(1 << slot); } -#define XFS_LIC_RELSE(cp,slot) xfs_lic_relse(cp,slot) static inline void xfs_lic_relse(xfs_log_item_chunk_t *cp, int slot) { cp->lic_free |= 1 << slot; } -#define XFS_LIC_SLOT(cp,slot) xfs_lic_slot(cp,slot) static inline xfs_log_item_desc_t * xfs_lic_slot(xfs_log_item_chunk_t *cp, int slot) { return &(cp->lic_descs[slot]); } -#define XFS_LIC_DESC_TO_SLOT(dp) xfs_lic_desc_to_slot(dp) static inline int xfs_lic_desc_to_slot(xfs_log_item_desc_t *dp) { return (uint)dp->lid_index; @@ -278,7 +268,6 @@ * All of this yields the address of the chunk, which is * cast to a chunk pointer. */ -#define XFS_LIC_DESC_TO_CHUNK(dp) xfs_lic_desc_to_chunk(dp) static inline xfs_log_item_chunk_t * xfs_lic_desc_to_chunk(xfs_log_item_desc_t *dp) { Index: linux/fs/xfs/xfs_trans_buf.c =================================================================== RCS file: /cvs/xfs-linux/xfs_trans_buf.c,v retrieving revision 1.130 diff -u -r1.130 xfs_trans_buf.c --- linux/fs/xfs/xfs_trans_buf.c 10 Apr 2008 04:25:55 -0000 1.130 +++ linux/fs/xfs/xfs_trans_buf.c 8 Jul 2008 03:24:33 -0000 @@ -1021,16 +1021,16 @@ bp = NULL; len = BBTOB(len); licp = &tp->t_items; - if (!XFS_LIC_ARE_ALL_FREE(licp)) { + if (!xfs_lic_are_all_free(licp)) { for (i = 0; i < licp->lic_unused; i++) { /* * Skip unoccupied slots. */ - if (XFS_LIC_ISFREE(licp, i)) { + if (xfs_lic_isfree(licp, i)) { continue; } - lidp = XFS_LIC_SLOT(licp, i); + lidp = xfs_lic_slot(licp, i); blip = (xfs_buf_log_item_t *)lidp->lid_item; if (blip->bli_item.li_type != XFS_LI_BUF) { continue; @@ -1074,7 +1074,7 @@ bp = NULL; len = BBTOB(len); for (licp = &tp->t_items; licp != NULL; licp = licp->lic_next) { - if (XFS_LIC_ARE_ALL_FREE(licp)) { + if (xfs_lic_are_all_free(licp)) { ASSERT(licp == &tp->t_items); ASSERT(licp->lic_next == NULL); return NULL; @@ -1083,11 +1083,11 @@ /* * Skip unoccupied slots. */ - if (XFS_LIC_ISFREE(licp, i)) { + if (xfs_lic_isfree(licp, i)) { continue; } - lidp = XFS_LIC_SLOT(licp, i); + lidp = xfs_lic_slot(licp, i); blip = (xfs_buf_log_item_t *)lidp->lid_item; if (blip->bli_item.li_type != XFS_LI_BUF) { continue; Index: linux/fs/xfs/xfs_trans_item.c =================================================================== RCS file: /cvs/xfs-linux/xfs_trans_item.c,v retrieving revision 1.47 diff -u -r1.47 xfs_trans_item.c --- linux/fs/xfs/xfs_trans_item.c 9 May 2008 04:27:47 -0000 1.47 +++ linux/fs/xfs/xfs_trans_item.c 8 Jul 2008 03:24:33 -0000 @@ -53,11 +53,11 @@ * Initialize the chunk, and then * claim the first slot in the newly allocated chunk. */ - XFS_LIC_INIT(licp); - XFS_LIC_CLAIM(licp, 0); + xfs_lic_init(licp); + xfs_lic_claim(licp, 0); licp->lic_unused = 1; - XFS_LIC_INIT_SLOT(licp, 0); - lidp = XFS_LIC_SLOT(licp, 0); + xfs_lic_init_slot(licp, 0); + lidp = xfs_lic_slot(licp, 0); /* * Link in the new chunk and update the free count. @@ -88,14 +88,14 @@ */ licp = &tp->t_items; while (licp != NULL) { - if (XFS_LIC_VACANCY(licp)) { + if (xfs_lic_vacancy(licp)) { if (licp->lic_unused <= XFS_LIC_MAX_SLOT) { i = licp->lic_unused; - ASSERT(XFS_LIC_ISFREE(licp, i)); + ASSERT(xfs_lic_isfree(licp, i)); break; } for (i = 0; i <= XFS_LIC_MAX_SLOT; i++) { - if (XFS_LIC_ISFREE(licp, i)) + if (xfs_lic_isfree(licp, i)) break; } ASSERT(i <= XFS_LIC_MAX_SLOT); @@ -108,12 +108,12 @@ * If we find a free descriptor, claim it, * initialize it, and return it. */ - XFS_LIC_CLAIM(licp, i); + xfs_lic_claim(licp, i); if (licp->lic_unused <= i) { licp->lic_unused = i + 1; - XFS_LIC_INIT_SLOT(licp, i); + xfs_lic_init_slot(licp, i); } - lidp = XFS_LIC_SLOT(licp, i); + lidp = xfs_lic_slot(licp, i); tp->t_items_free--; lidp->lid_item = lip; lidp->lid_flags = 0; @@ -136,9 +136,9 @@ xfs_log_item_chunk_t *licp; xfs_log_item_chunk_t **licpp; - slot = XFS_LIC_DESC_TO_SLOT(lidp); - licp = XFS_LIC_DESC_TO_CHUNK(lidp); - XFS_LIC_RELSE(licp, slot); + slot = xfs_lic_desc_to_slot(lidp); + licp = xfs_lic_desc_to_chunk(lidp); + xfs_lic_relse(licp, slot); lidp->lid_item->li_desc = NULL; tp->t_items_free++; @@ -154,7 +154,7 @@ * Also decrement the transaction structure's count of free items * by the number in a chunk since we are freeing an empty chunk. */ - if (XFS_LIC_ARE_ALL_FREE(licp) && (licp != &(tp->t_items))) { + if (xfs_lic_are_all_free(licp) && (licp != &(tp->t_items))) { licpp = &(tp->t_items.lic_next); while (*licpp != licp) { ASSERT(*licpp != NULL); @@ -207,20 +207,20 @@ /* * If it's not in the first chunk, skip to the second. */ - if (XFS_LIC_ARE_ALL_FREE(licp)) { + if (xfs_lic_are_all_free(licp)) { licp = licp->lic_next; } /* * Return the first non-free descriptor in the chunk. */ - ASSERT(!XFS_LIC_ARE_ALL_FREE(licp)); + ASSERT(!xfs_lic_are_all_free(licp)); for (i = 0; i < licp->lic_unused; i++) { - if (XFS_LIC_ISFREE(licp, i)) { + if (xfs_lic_isfree(licp, i)) { continue; } - return XFS_LIC_SLOT(licp, i); + return xfs_lic_slot(licp, i); } cmn_err(CE_WARN, "xfs_trans_first_item() -- no first item"); return NULL; @@ -242,18 +242,18 @@ xfs_log_item_chunk_t *licp; int i; - licp = XFS_LIC_DESC_TO_CHUNK(lidp); + licp = xfs_lic_desc_to_chunk(lidp); /* * First search the rest of the chunk. The for loop keeps us * from referencing things beyond the end of the chunk. */ - for (i = (int)XFS_LIC_DESC_TO_SLOT(lidp) + 1; i < licp->lic_unused; i++) { - if (XFS_LIC_ISFREE(licp, i)) { + for (i = (int)xfs_lic_desc_to_slot(lidp) + 1; i < licp->lic_unused; i++) { + if (xfs_lic_isfree(licp, i)) { continue; } - return XFS_LIC_SLOT(licp, i); + return xfs_lic_slot(licp, i); } /* @@ -266,13 +266,13 @@ } licp = licp->lic_next; - ASSERT(!XFS_LIC_ARE_ALL_FREE(licp)); + ASSERT(!xfs_lic_are_all_free(licp)); for (i = 0; i < licp->lic_unused; i++) { - if (XFS_LIC_ISFREE(licp, i)) { + if (xfs_lic_isfree(licp, i)) { continue; } - return XFS_LIC_SLOT(licp, i); + return xfs_lic_slot(licp, i); } ASSERT(0); /* NOTREACHED */ @@ -300,9 +300,9 @@ /* * Special case the embedded chunk so we don't free it below. */ - if (!XFS_LIC_ARE_ALL_FREE(licp)) { + if (!xfs_lic_are_all_free(licp)) { (void) xfs_trans_unlock_chunk(licp, 1, abort, NULLCOMMITLSN); - XFS_LIC_ALL_FREE(licp); + xfs_lic_all_free(licp); licp->lic_unused = 0; } licp = licp->lic_next; @@ -311,7 +311,7 @@ * Unlock each item in each chunk and free the chunks. */ while (licp != NULL) { - ASSERT(!XFS_LIC_ARE_ALL_FREE(licp)); + ASSERT(!xfs_lic_are_all_free(licp)); (void) xfs_trans_unlock_chunk(licp, 1, abort, NULLCOMMITLSN); next_licp = licp->lic_next; kmem_free(licp); @@ -347,7 +347,7 @@ /* * Special case the embedded chunk so we don't free. */ - if (!XFS_LIC_ARE_ALL_FREE(licp)) { + if (!xfs_lic_are_all_free(licp)) { freed = xfs_trans_unlock_chunk(licp, 0, 0, commit_lsn); } licpp = &(tp->t_items.lic_next); @@ -358,10 +358,10 @@ * and free empty chunks. */ while (licp != NULL) { - ASSERT(!XFS_LIC_ARE_ALL_FREE(licp)); + ASSERT(!xfs_lic_are_all_free(licp)); freed += xfs_trans_unlock_chunk(licp, 0, 0, commit_lsn); next_licp = licp->lic_next; - if (XFS_LIC_ARE_ALL_FREE(licp)) { + if (xfs_lic_are_all_free(licp)) { *licpp = next_licp; kmem_free(licp); freed -= XFS_LIC_NUM_SLOTS; @@ -402,7 +402,7 @@ freed = 0; lidp = licp->lic_descs; for (i = 0; i < licp->lic_unused; i++, lidp++) { - if (XFS_LIC_ISFREE(licp, i)) { + if (xfs_lic_isfree(licp, i)) { continue; } lip = lidp->lid_item; @@ -421,7 +421,7 @@ */ if (!(freeing_chunk) && (!(lidp->lid_flags & XFS_LID_DIRTY) || abort)) { - XFS_LIC_RELSE(licp, i); + xfs_lic_relse(licp, i); freed++; } } Index: linux/fs/xfs/xfsidbg.c =================================================================== RCS file: /cvs/xfs-linux/xfsidbg.c,v retrieving revision 1.353 diff -u -r1.353 xfsidbg.c --- linux/fs/xfs/xfsidbg.c 25 Jun 2008 16:26:57 -0000 1.353 +++ linux/fs/xfs/linux/fs/xfs/xfsidbg.c 8 Jul 2008 03:24:35 -0000 @@ -6951,17 +6951,17 @@ licp = &tp->t_items; chunk = 0; while (licp != NULL) { - if (XFS_LIC_ARE_ALL_FREE(licp)) { + if (xfs_lic_are_all_free(licp)) { licp = licp->lic_next; chunk++; continue; } for (i = 0; i < licp->lic_unused; i++) { - if (XFS_LIC_ISFREE(licp, i)) { + if (xfs_lic_isfree(licp, i)) { continue; } - lidp = XFS_LIC_SLOT(licp, i); + lidp = xfs_lic_slot(licp, i); kdb_printf("\n"); kdb_printf("chunk %d index %d item 0x%p size %d\n", chunk, i, lidp->lid_item, lidp->lid_size); From owner-xfs@oss.sgi.com Mon Jul 7 21:40:51 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Jul 2008 21:40:56 -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_61, 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 m684eoLr028855 for ; Mon, 7 Jul 2008 21:40:50 -0700 X-ASG-Debug-ID: 1215492112-165002d50000-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 D8598DBB563 for ; Mon, 7 Jul 2008 21:41:53 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id 9ytjZ0les93QX9Ot for ; Mon, 07 Jul 2008 21:41:53 -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 418B2AC3593 for ; Mon, 7 Jul 2008 23:41:52 -0500 (CDT) Message-ID: <4872F011.70902@sandeen.net> Date: Mon, 07 Jul 2008 23:41:53 -0500 From: Eric Sandeen User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: xfs-oss X-ASG-Orig-Subj: [PATCH (fixed)] remove shouting-indirection macros from xfs_trans.h Subject: [PATCH (fixed)] remove shouting-indirection macros from xfs_trans.h References: <4872DEF8.6060704@sandeen.net> In-Reply-To: <4872DEF8.6060704@sandeen.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: 1215492114 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.55450 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: 16780 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 (sorry, stuffed up the patch format just a bit) compile-tested, fairly easy to inspect with: quilt diff --diff="diff -iu" etc. Signed-off-by: Eric Sandeen --- xfs_bmap.c | 6 ++--- xfs_trans.c | 12 +++++----- xfs_trans.h | 11 --------- xfs_trans_buf.c | 12 +++++----- xfs_trans_item.c | 66 +++++++++++++++++++++++++++---------------------------- xfsidbg.c | 6 ++--- 6 files changed, 51 insertions(+), 62 deletions(-) Index: linux-2.6-xfs/fs/xfs/xfs_bmap.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_bmap.c +++ linux-2.6-xfs/fs/xfs/xfs_bmap.c @@ -6096,7 +6096,7 @@ xfs_bmap_get_bp( tp = cur->bc_tp; licp = &tp->t_items; while (!bp && licp != NULL) { - if (XFS_LIC_ARE_ALL_FREE(licp)) { + if (xfs_lic_are_all_free(licp)) { licp = licp->lic_next; continue; } @@ -6106,11 +6106,11 @@ xfs_bmap_get_bp( xfs_buf_log_item_t *bip; xfs_buf_t *lbp; - if (XFS_LIC_ISFREE(licp, i)) { + if (xfs_lic_isfree(licp, i)) { continue; } - lidp = XFS_LIC_SLOT(licp, i); + lidp = xfs_lic_slot(licp, i); lip = lidp->lid_item; if (lip->li_type != XFS_LI_BUF) continue; Index: linux-2.6-xfs/fs/xfs/xfs_trans.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_trans.c +++ linux-2.6-xfs/fs/xfs/xfs_trans.c @@ -253,7 +253,7 @@ _xfs_trans_alloc( tp->t_mountp = mp; tp->t_items_free = XFS_LIC_NUM_SLOTS; tp->t_busy_free = XFS_LBC_NUM_SLOTS; - XFS_LIC_INIT(&(tp->t_items)); + xfs_lic_init(&(tp->t_items)); XFS_LBC_INIT(&(tp->t_busy)); return tp; } @@ -282,7 +282,7 @@ xfs_trans_dup( ntp->t_mountp = tp->t_mountp; ntp->t_items_free = XFS_LIC_NUM_SLOTS; ntp->t_busy_free = XFS_LBC_NUM_SLOTS; - XFS_LIC_INIT(&(ntp->t_items)); + xfs_lic_init(&(ntp->t_items)); XFS_LBC_INIT(&(ntp->t_busy)); ASSERT(tp->t_flags & XFS_TRANS_PERM_LOG_RES); @@ -1169,7 +1169,7 @@ xfs_trans_cancel( while (licp != NULL) { lidp = licp->lic_descs; for (i = 0; i < licp->lic_unused; i++, lidp++) { - if (XFS_LIC_ISFREE(licp, i)) { + if (xfs_lic_isfree(licp, i)) { continue; } @@ -1253,7 +1253,7 @@ xfs_trans_committed( * Special case the chunk embedded in the transaction. */ licp = &(tp->t_items); - if (!(XFS_LIC_ARE_ALL_FREE(licp))) { + if (!(xfs_lic_are_all_free(licp))) { xfs_trans_chunk_committed(licp, tp->t_lsn, abortflag); } @@ -1262,7 +1262,7 @@ xfs_trans_committed( */ licp = licp->lic_next; while (licp != NULL) { - ASSERT(!XFS_LIC_ARE_ALL_FREE(licp)); + ASSERT(!xfs_lic_are_all_free(licp)); xfs_trans_chunk_committed(licp, tp->t_lsn, abortflag); next_licp = licp->lic_next; kmem_free(licp); @@ -1325,7 +1325,7 @@ xfs_trans_chunk_committed( lidp = licp->lic_descs; for (i = 0; i < licp->lic_unused; i++, lidp++) { - if (XFS_LIC_ISFREE(licp, i)) { + if (xfs_lic_isfree(licp, i)) { continue; } Index: linux-2.6-xfs/fs/xfs/xfs_trans.h =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_trans.h +++ linux-2.6-xfs/fs/xfs/xfs_trans.h @@ -210,62 +210,52 @@ typedef struct xfs_log_item_chunk { * lic_unused to the right value (0 matches all free). The * lic_descs.lid_index values are set up as each desc is allocated. */ -#define XFS_LIC_INIT(cp) xfs_lic_init(cp) static inline void xfs_lic_init(xfs_log_item_chunk_t *cp) { cp->lic_free = XFS_LIC_FREEMASK; } -#define XFS_LIC_INIT_SLOT(cp,slot) xfs_lic_init_slot(cp, slot) static inline void xfs_lic_init_slot(xfs_log_item_chunk_t *cp, int slot) { cp->lic_descs[slot].lid_index = (unsigned char)(slot); } -#define XFS_LIC_VACANCY(cp) xfs_lic_vacancy(cp) static inline int xfs_lic_vacancy(xfs_log_item_chunk_t *cp) { return cp->lic_free & XFS_LIC_FREEMASK; } -#define XFS_LIC_ALL_FREE(cp) xfs_lic_all_free(cp) static inline void xfs_lic_all_free(xfs_log_item_chunk_t *cp) { cp->lic_free = XFS_LIC_FREEMASK; } -#define XFS_LIC_ARE_ALL_FREE(cp) xfs_lic_are_all_free(cp) static inline int xfs_lic_are_all_free(xfs_log_item_chunk_t *cp) { return ((cp->lic_free & XFS_LIC_FREEMASK) == XFS_LIC_FREEMASK); } -#define XFS_LIC_ISFREE(cp,slot) xfs_lic_isfree(cp,slot) static inline int xfs_lic_isfree(xfs_log_item_chunk_t *cp, int slot) { return (cp->lic_free & (1 << slot)); } -#define XFS_LIC_CLAIM(cp,slot) xfs_lic_claim(cp,slot) static inline void xfs_lic_claim(xfs_log_item_chunk_t *cp, int slot) { cp->lic_free &= ~(1 << slot); } -#define XFS_LIC_RELSE(cp,slot) xfs_lic_relse(cp,slot) static inline void xfs_lic_relse(xfs_log_item_chunk_t *cp, int slot) { cp->lic_free |= 1 << slot; } -#define XFS_LIC_SLOT(cp,slot) xfs_lic_slot(cp,slot) static inline xfs_log_item_desc_t * xfs_lic_slot(xfs_log_item_chunk_t *cp, int slot) { return &(cp->lic_descs[slot]); } -#define XFS_LIC_DESC_TO_SLOT(dp) xfs_lic_desc_to_slot(dp) static inline int xfs_lic_desc_to_slot(xfs_log_item_desc_t *dp) { return (uint)dp->lid_index; @@ -278,7 +268,6 @@ static inline int xfs_lic_desc_to_slot(x * All of this yields the address of the chunk, which is * cast to a chunk pointer. */ -#define XFS_LIC_DESC_TO_CHUNK(dp) xfs_lic_desc_to_chunk(dp) static inline xfs_log_item_chunk_t * xfs_lic_desc_to_chunk(xfs_log_item_desc_t *dp) { Index: linux-2.6-xfs/fs/xfs/xfs_trans_buf.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_trans_buf.c +++ linux-2.6-xfs/fs/xfs/xfs_trans_buf.c @@ -1021,16 +1021,16 @@ xfs_trans_buf_item_match( bp = NULL; len = BBTOB(len); licp = &tp->t_items; - if (!XFS_LIC_ARE_ALL_FREE(licp)) { + if (!xfs_lic_are_all_free(licp)) { for (i = 0; i < licp->lic_unused; i++) { /* * Skip unoccupied slots. */ - if (XFS_LIC_ISFREE(licp, i)) { + if (xfs_lic_isfree(licp, i)) { continue; } - lidp = XFS_LIC_SLOT(licp, i); + lidp = xfs_lic_slot(licp, i); blip = (xfs_buf_log_item_t *)lidp->lid_item; if (blip->bli_item.li_type != XFS_LI_BUF) { continue; @@ -1074,7 +1074,7 @@ xfs_trans_buf_item_match_all( bp = NULL; len = BBTOB(len); for (licp = &tp->t_items; licp != NULL; licp = licp->lic_next) { - if (XFS_LIC_ARE_ALL_FREE(licp)) { + if (xfs_lic_are_all_free(licp)) { ASSERT(licp == &tp->t_items); ASSERT(licp->lic_next == NULL); return NULL; @@ -1083,11 +1083,11 @@ xfs_trans_buf_item_match_all( /* * Skip unoccupied slots. */ - if (XFS_LIC_ISFREE(licp, i)) { + if (xfs_lic_isfree(licp, i)) { continue; } - lidp = XFS_LIC_SLOT(licp, i); + lidp = xfs_lic_slot(licp, i); blip = (xfs_buf_log_item_t *)lidp->lid_item; if (blip->bli_item.li_type != XFS_LI_BUF) { continue; Index: linux-2.6-xfs/fs/xfs/xfs_trans_item.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfs_trans_item.c +++ linux-2.6-xfs/fs/xfs/xfs_trans_item.c @@ -53,11 +53,11 @@ xfs_trans_add_item(xfs_trans_t *tp, xfs_ * Initialize the chunk, and then * claim the first slot in the newly allocated chunk. */ - XFS_LIC_INIT(licp); - XFS_LIC_CLAIM(licp, 0); + xfs_lic_init(licp); + xfs_lic_claim(licp, 0); licp->lic_unused = 1; - XFS_LIC_INIT_SLOT(licp, 0); - lidp = XFS_LIC_SLOT(licp, 0); + xfs_lic_init_slot(licp, 0); + lidp = xfs_lic_slot(licp, 0); /* * Link in the new chunk and update the free count. @@ -88,14 +88,14 @@ xfs_trans_add_item(xfs_trans_t *tp, xfs_ */ licp = &tp->t_items; while (licp != NULL) { - if (XFS_LIC_VACANCY(licp)) { + if (xfs_lic_vacancy(licp)) { if (licp->lic_unused <= XFS_LIC_MAX_SLOT) { i = licp->lic_unused; - ASSERT(XFS_LIC_ISFREE(licp, i)); + ASSERT(xfs_lic_isfree(licp, i)); break; } for (i = 0; i <= XFS_LIC_MAX_SLOT; i++) { - if (XFS_LIC_ISFREE(licp, i)) + if (xfs_lic_isfree(licp, i)) break; } ASSERT(i <= XFS_LIC_MAX_SLOT); @@ -108,12 +108,12 @@ xfs_trans_add_item(xfs_trans_t *tp, xfs_ * If we find a free descriptor, claim it, * initialize it, and return it. */ - XFS_LIC_CLAIM(licp, i); + xfs_lic_claim(licp, i); if (licp->lic_unused <= i) { licp->lic_unused = i + 1; - XFS_LIC_INIT_SLOT(licp, i); + xfs_lic_init_slot(licp, i); } - lidp = XFS_LIC_SLOT(licp, i); + lidp = xfs_lic_slot(licp, i); tp->t_items_free--; lidp->lid_item = lip; lidp->lid_flags = 0; @@ -136,9 +136,9 @@ xfs_trans_free_item(xfs_trans_t *tp, xfs xfs_log_item_chunk_t *licp; xfs_log_item_chunk_t **licpp; - slot = XFS_LIC_DESC_TO_SLOT(lidp); - licp = XFS_LIC_DESC_TO_CHUNK(lidp); - XFS_LIC_RELSE(licp, slot); + slot = xfs_lic_desc_to_slot(lidp); + licp = xfs_lic_desc_to_chunk(lidp); + xfs_lic_relse(licp, slot); lidp->lid_item->li_desc = NULL; tp->t_items_free++; @@ -154,7 +154,7 @@ xfs_trans_free_item(xfs_trans_t *tp, xfs * Also decrement the transaction structure's count of free items * by the number in a chunk since we are freeing an empty chunk. */ - if (XFS_LIC_ARE_ALL_FREE(licp) && (licp != &(tp->t_items))) { + if (xfs_lic_are_all_free(licp) && (licp != &(tp->t_items))) { licpp = &(tp->t_items.lic_next); while (*licpp != licp) { ASSERT(*licpp != NULL); @@ -207,20 +207,20 @@ xfs_trans_first_item(xfs_trans_t *tp) /* * If it's not in the first chunk, skip to the second. */ - if (XFS_LIC_ARE_ALL_FREE(licp)) { + if (xfs_lic_are_all_free(licp)) { licp = licp->lic_next; } /* * Return the first non-free descriptor in the chunk. */ - ASSERT(!XFS_LIC_ARE_ALL_FREE(licp)); + ASSERT(!xfs_lic_are_all_free(licp)); for (i = 0; i < licp->lic_unused; i++) { - if (XFS_LIC_ISFREE(licp, i)) { + if (xfs_lic_isfree(licp, i)) { continue; } - return XFS_LIC_SLOT(licp, i); + return xfs_lic_slot(licp, i); } cmn_err(CE_WARN, "xfs_trans_first_item() -- no first item"); return NULL; @@ -242,18 +242,18 @@ xfs_trans_next_item(xfs_trans_t *tp, xfs xfs_log_item_chunk_t *licp; int i; - licp = XFS_LIC_DESC_TO_CHUNK(lidp); + licp = xfs_lic_desc_to_chunk(lidp); /* * First search the rest of the chunk. The for loop keeps us * from referencing things beyond the end of the chunk. */ - for (i = (int)XFS_LIC_DESC_TO_SLOT(lidp) + 1; i < licp->lic_unused; i++) { - if (XFS_LIC_ISFREE(licp, i)) { + for (i = (int)xfs_lic_desc_to_slot(lidp) + 1; i < licp->lic_unused; i++) { + if (xfs_lic_isfree(licp, i)) { continue; } - return XFS_LIC_SLOT(licp, i); + return xfs_lic_slot(licp, i); } /* @@ -266,13 +266,13 @@ xfs_trans_next_item(xfs_trans_t *tp, xfs } licp = licp->lic_next; - ASSERT(!XFS_LIC_ARE_ALL_FREE(licp)); + ASSERT(!xfs_lic_are_all_free(licp)); for (i = 0; i < licp->lic_unused; i++) { - if (XFS_LIC_ISFREE(licp, i)) { + if (xfs_lic_isfree(licp, i)) { continue; } - return XFS_LIC_SLOT(licp, i); + return xfs_lic_slot(licp, i); } ASSERT(0); /* NOTREACHED */ @@ -300,9 +300,9 @@ xfs_trans_free_items( /* * Special case the embedded chunk so we don't free it below. */ - if (!XFS_LIC_ARE_ALL_FREE(licp)) { + if (!xfs_lic_are_all_free(licp)) { (void) xfs_trans_unlock_chunk(licp, 1, abort, NULLCOMMITLSN); - XFS_LIC_ALL_FREE(licp); + xfs_lic_all_free(licp); licp->lic_unused = 0; } licp = licp->lic_next; @@ -311,7 +311,7 @@ xfs_trans_free_items( * Unlock each item in each chunk and free the chunks. */ while (licp != NULL) { - ASSERT(!XFS_LIC_ARE_ALL_FREE(licp)); + ASSERT(!xfs_lic_are_all_free(licp)); (void) xfs_trans_unlock_chunk(licp, 1, abort, NULLCOMMITLSN); next_licp = licp->lic_next; kmem_free(licp); @@ -347,7 +347,7 @@ xfs_trans_unlock_items(xfs_trans_t *tp, /* * Special case the embedded chunk so we don't free. */ - if (!XFS_LIC_ARE_ALL_FREE(licp)) { + if (!xfs_lic_are_all_free(licp)) { freed = xfs_trans_unlock_chunk(licp, 0, 0, commit_lsn); } licpp = &(tp->t_items.lic_next); @@ -358,10 +358,10 @@ xfs_trans_unlock_items(xfs_trans_t *tp, * and free empty chunks. */ while (licp != NULL) { - ASSERT(!XFS_LIC_ARE_ALL_FREE(licp)); + ASSERT(!xfs_lic_are_all_free(licp)); freed += xfs_trans_unlock_chunk(licp, 0, 0, commit_lsn); next_licp = licp->lic_next; - if (XFS_LIC_ARE_ALL_FREE(licp)) { + if (xfs_lic_are_all_free(licp)) { *licpp = next_licp; kmem_free(licp); freed -= XFS_LIC_NUM_SLOTS; @@ -402,7 +402,7 @@ xfs_trans_unlock_chunk( freed = 0; lidp = licp->lic_descs; for (i = 0; i < licp->lic_unused; i++, lidp++) { - if (XFS_LIC_ISFREE(licp, i)) { + if (xfs_lic_isfree(licp, i)) { continue; } lip = lidp->lid_item; @@ -421,7 +421,7 @@ xfs_trans_unlock_chunk( */ if (!(freeing_chunk) && (!(lidp->lid_flags & XFS_LID_DIRTY) || abort)) { - XFS_LIC_RELSE(licp, i); + xfs_lic_relse(licp, i); freed++; } } Index: linux-2.6-xfs/fs/xfs/xfsidbg.c =================================================================== --- linux-2.6-xfs.orig/fs/xfs/xfsidbg.c +++ linux-2.6-xfs/fs/xfs/xfsidbg.c @@ -6951,17 +6951,17 @@ xfsidbg_xtp(xfs_trans_t *tp) licp = &tp->t_items; chunk = 0; while (licp != NULL) { - if (XFS_LIC_ARE_ALL_FREE(licp)) { + if (xfs_lic_are_all_free(licp)) { licp = licp->lic_next; chunk++; continue; } for (i = 0; i < licp->lic_unused; i++) { - if (XFS_LIC_ISFREE(licp, i)) { + if (xfs_lic_isfree(licp, i)) { continue; } - lidp = XFS_LIC_SLOT(licp, i); + lidp = xfs_lic_slot(licp, i); kdb_printf("\n"); kdb_printf("chunk %d index %d item 0x%p size %d\n", chunk, i, lidp->lid_item, lidp->lid_size); From owner-xfs@oss.sgi.com Mon Jul 7 22:02:01 2008 Received: with ECARTIS (v1.0.0; list xfs); Mon, 07 Jul 2008 22:02: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.0 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 m6851vnr029780 for ; Mon, 7 Jul 2008 22:02:01 -0700 X-ASG-Debug-ID: 1215493380-3b6402ff0000-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 963E32C6A39 for ; Mon, 7 Jul 2008 22:03:01 -0700 (PDT) Received: from bby1mta02.pmc-sierra.bc.ca (bby1mta02.pmc-sierra.com [216.241.235.117]) by cuda.sgi.com with ESMTP id V7TKKGdoH1on58ym for ; Mon, 07 Jul 2008 22:03:01 -0700 (PDT) Received: from bby1mta02.pmc-sierra.bc.ca (localhost.pmc-sierra.bc.ca [127.0.0.1]) by localhost (Postfix) with SMTP id C0B4C8E00B4; Mon, 7 Jul 2008 22:05:47 -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 A8DF88E008E; Mon, 7 Jul 2008 22:05:47 -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); Mon, 7 Jul 2008 22:03:39 -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: Mon, 7 Jul 2008 22:03:38 -0700 Message-ID: <340C71CD25A7EB49BFA81AE8C839266701323C3C@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> In-Reply-To: <4872E33E.3090107@sandeen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Xfs Access to block zero exception and system crash Thread-Index: AcjgrWReJLSDlJRQSj6EZpV6D5oEvQACBGJg References: <4872E0BC.6070400@pmc-sierra.com> <4872E33E.3090107@sandeen.net> From: "Sagar Borikar" To: "Eric Sandeen" Cc: "Raj Palani" , X-OriginalArrivalTime: 08 Jul 2008 05:03:39.0458 (UTC) FILETIME=[FC2E2A20:01C8E0B7] X-Barracuda-Connect: bby1mta02.pmc-sierra.com[216.241.235.117] X-Barracuda-Start-Time: 1215493381 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0014 1.0000 -2.0119 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.55451 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 m68521nr029782 X-archive-position: 16781 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 Sure Eric, I'll keep you posted with the results w/o loop back file. When you say that the deadlock could be due to vm, is it due to lack of memory? I checked meminfo and I found that sufficient buffers and committed_as were persent when xfs is stalled. Thanks Sagar Sagar Borikar wrote: > That's right Eric but I am still surprised that why should we get a > dead lock in this scenario as it is a plain copy of file in multiple > directories. Our customer is reporting similar kind of lockup in our > platform. ok, I guess I had missed that, sorry. > I do understand that we are chasing the access to block zero exception > and XFS forced shutdown which I mentioned earlier. But we also see > quite a few smbd processes which are writing data to XFS are in > uninterruptible sleep state and the system locks up too. Ok; then the next step is probably to do sysrq-t and see where things are stuck. It might be better to see if you can reproduce w/o the loopback file, too, since that's just another layer to go through that might be changing things. > So I thought > the test which I am running could be pointing to similar issue which > we are observing on our platform. But does this indicate that the > problem lies with x86 XFS too ? or maybe the vm ... > Also I presume in enterprise market such kind of simultaneous write > situation may happen. Has anybody reported similar issues to you? As > you observed it over x86 and 2.6.24 kernel, could you say what would > be root cause of this? Haven't really seen it before that I recall, and at this point can't say for sure what it might be. -Eric > Sorry for lots of questions at same time :) But I am happy that > you were able to see the deadlock in x86 on your setup with 2.6.24 > > Thanks > Sagar > > > Eric Sandeen wrote: >> Sagar Borikar wrote: >> >>> Hi Eric, >>> >>> Did you see any issues in your test? >>> >> I got a deadlock but that's it; I don't think that's the bug you want >> to chase... >> >> >> -Eric >> >> >>> Thanks >>> Sagar >>> >>> >>> Sagar Borikar wrote: >>> >>>> Eric Sandeen wrote: >>>> >>>>> Sagar Borikar wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> Could you kindly try with my test? I presume you should see >>>>>> failure soon. I tried this on >>>>>> 2 different x86 systems 2 times ( after rebooting the system ) >>>>>> and I saw it every time. >>>>>> >>>>>> >>>>> Sure. Is there a reason you're doing this on a loopback file? >>>>> That probably stresses the vm a bit more, and might get even >>>>> trickier if the loopback file is sparse... >>>>> >>>>> >>>> Initially I thought to do that since I didn't want to have a strict >>>> allocation limit but allowing allocations to grow as needed until >>>> the backing filesystem runs out of free space due to type of the >>>> test case I had. But then I dropped the plan and created a >>>> non-sparse loopback device. There was no specific reason to create >>>> loopback but as it was simplest option to do it. >>>> >>>>> But anyway, on an x86_64 machine with 2G of memory and a >>>>> non-sparse 10G loopback file on 2.6.24.7-92.fc8, your test runs >>>>> w/o problems for me, though the system does get sluggish. I let >>>>> it run a bit then ran repair and it found no problems, I'll run it >>>>> overnight to see if anything else turns up. >>>>> >>>>> >>>> That will be great. Thanks indeed. >>>> Sagar >>>> >>>> >>>>> -Eric >>>>> >>>>> >> > From owner-xfs@oss.sgi.com Tue Jul 8 01:01:45 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 08 Jul 2008 01:02: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=-1.0 required=5.0 tests=AWL,BAYES_00,RDNS_NONE, SUBJ_FRIEND 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 m6881htK009670 for ; Tue, 8 Jul 2008 01:01:45 -0700 X-ASG-Debug-ID: 1215504167-3abf03c00000-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 C3BFD1889C32 for ; Tue, 8 Jul 2008 01:02:47 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id J2CqmH622pIkqeUh for ; Tue, 08 Jul 2008 01:02:47 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1KG89v-0000pA-CN; Tue, 08 Jul 2008 08:02:47 +0000 Date: Tue, 8 Jul 2008 04:02:47 -0400 From: Christoph Hellwig To: Eric Sandeen Cc: xfs-oss X-ASG-Orig-Subj: Re: [PATCH] remove INT_GET and friends Subject: Re: [PATCH] remove INT_GET and friends Message-ID: <20080708080247.GA13762@infradead.org> References: <47FF794C.4020801@sandeen.net> <4872D96A.7070703@sandeen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4872D96A.7070703@sandeen.net> 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: 1215504167 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.55460 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: 16782 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 Mon, Jul 07, 2008 at 10:05:14PM -0500, Eric Sandeen wrote: > Eric Sandeen wrote: > > Thanks to hch's endian work, INT_GET etc are no longer used, > > and may as well be removed. INT_SET is still used in > > the acl code, though. > > > > Signed-off-by: Eric Sandeen > > --- > > > > xfs_arch.h | 68 --------------------------------- > > 1 files changed, 68 deletions(-) > > > > Ping? these are just unused macros. You might want to wait until the generic ACL code goes in, because then we can kill the remaining macros, too. Or just put this in now, I don't really care :) From owner-xfs@oss.sgi.com Tue Jul 8 01:28:54 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 08 Jul 2008 01:28:56 -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,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 m688SrYO011287 for ; Tue, 8 Jul 2008 01:28:54 -0700 X-ASG-Debug-ID: 1215505797-6b3702860000-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 BF7B61889D47 for ; Tue, 8 Jul 2008 01:29:58 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id E5DIoXB3uj18B5Po for ; Tue, 08 Jul 2008 01:29:58 -0700 (PDT) Received: by lucidpixels.com (Postfix, from userid 1001) id AB97E5A567; Tue, 8 Jul 2008 04:29:57 -0400 (EDT) Date: Tue, 8 Jul 2008 04:29:57 -0400 (EDT) From: Justin Piszcz To: David Greaves cc: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: 12 Veliciraptors again w/x4 card (~1gbyte/sec aggregate read)! Subject: Re: 12 Veliciraptors again w/x4 card (~1gbyte/sec aggregate read)! In-Reply-To: <4872A2F4.2010604@dgreaves.com> Message-ID: References: <4872A2F4.2010604@dgreaves.com> 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: 1215505798 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.55462 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: 16783 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 Tue, 8 Jul 2008, David Greaves wrote: > Justin Piszcz wrote: >> Each PCI-e x1 card has 1 veliciraptor on it now. >> Got an x4 card wit 4 sata ports: > > Useful - which card? > > David > > StarTech 4 Port PCI Express x4 SATA II Card Model PEXSATA24E Justin. From owner-xfs@oss.sgi.com Tue Jul 8 01:38:30 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 08 Jul 2008 01:38: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=-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 m688cU1k012142 for ; Tue, 8 Jul 2008 01:38:30 -0700 X-ASG-Debug-ID: 1215506374-699702250000-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 AE5542C7411 for ; Tue, 8 Jul 2008 01:39:35 -0700 (PDT) Received: from lucidpixels.com (lucidpixels.com [75.144.35.66]) by cuda.sgi.com with ESMTP id yLPPKBtiWZMIg74P for ; Tue, 08 Jul 2008 01:39:35 -0700 (PDT) Received: by lucidpixels.com (Postfix, from userid 1001) id 8E495126FF; Tue, 8 Jul 2008 04:39:34 -0400 (EDT) Date: Tue, 8 Jul 2008 04:39:34 -0400 (EDT) From: Justin Piszcz To: David Greaves cc: linux-kernel@vger.kernel.org, linux-raid@vger.kernel.org, xfs@oss.sgi.com X-ASG-Orig-Subj: Re: 12 Veliciraptors again w/x4 card (~1gbyte/sec aggregate read)! Subject: Re: 12 Veliciraptors again w/x4 card (~1gbyte/sec aggregate read)! In-Reply-To: Message-ID: References: <4872A2F4.2010604@dgreaves.com> 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: 1215506375 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.55460 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: 16784 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 Tue, 8 Jul 2008, Justin Piszcz wrote: > > > On Tue, 8 Jul 2008, David Greaves wrote: > >> Justin Piszcz wrote: >>> Each PCI-e x1 card has 1 veliciraptor on it now. >>> Got an x4 card wit 4 sata ports: >> >> Useful - which card? >> >> David >> >> > > StarTech 4 Port PCI Express x4 SATA II Card Model PEXSATA24E > > Justin. > > > Chipset: Marvell 88SX7042 SATA Connectivity: Use four internal ports at the same time or two internal and two external ports Which is fully supported in the latest kernels (didn't try an old kernel): linux-2.6.25.10/drivers/ata/sata_mv.c /* Marvell 7042 support */ { PCI_VDEVICE(MARVELL, 0x7042), chip_7042 }, From owner-xfs@oss.sgi.com Tue Jul 8 06:37:22 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 08 Jul 2008 06:37:31 -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.0 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_24_48 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 m68DbMDl003746 for ; Tue, 8 Jul 2008 06:37:22 -0700 X-ASG-Debug-ID: 1215524290-2b4803b50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from spitz.ucw.cz (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 001A02C8987 for ; Tue, 8 Jul 2008 06:38:16 -0700 (PDT) Received: from spitz.ucw.cz (gprs189-60.eurotel.cz [160.218.189.60]) by cuda.sgi.com with ESMTP id vyHGEJIEo7eq4HgI for ; Tue, 08 Jul 2008 06:38:16 -0700 (PDT) Received: by spitz.ucw.cz (Postfix, from userid 0) id 5D55F2787C; Mon, 7 Jul 2008 11:07:31 +0000 (UTC) Date: Mon, 7 Jul 2008 13:07:31 +0200 From: Pavel Machek To: Christoph Hellwig Cc: Takashi Sato , 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: <20080707110730.GG5643@ucw.cz> 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.5.9i X-Barracuda-Connect: gprs189-60.eurotel.cz[160.218.189.60] X-Barracuda-Start-Time: 1215524305 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.22 X-Barracuda-Spam-Status: No, SCORE=-1.22 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=DATE_IN_PAST_24_48 X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.55481 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.81 DATE_IN_PAST_24_48 Date: is 24 to 48 hours before Received: date 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: 16785 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pavel@suse.cz Precedence: bulk X-list: xfs Hi! > 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 What happens when someone dirties so much data that vm swaps out whatever process that frozen the filesystem? I though that was why the timeout was there... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html From owner-xfs@oss.sgi.com Tue Jul 8 16:09:29 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 08 Jul 2008 16:09:38 -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 (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 m68N9Sv7010767 for ; Tue, 8 Jul 2008 16:09:29 -0700 X-ASG-Debug-ID: 1215558630-06dd03920000-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 376772CBA3B for ; Tue, 8 Jul 2008 16:10:31 -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 RlLskAlZCcxGzkOz for ; Tue, 08 Jul 2008 16:10:31 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAePc0h5LFxA/2dsb2JhbACyEg X-IronPort-AV: E=Sophos;i="4.30,326,1212330600"; d="scan'208";a="144725750" Received: from ppp121-44-92-64.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.92.64]) by ipmail01.adl6.internode.on.net with ESMTP; 09 Jul 2008 08:40:28 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KGMKJ-00074K-2m; Wed, 09 Jul 2008 09:10:27 +1000 Date: Wed, 9 Jul 2008 09:10:27 +1000 From: Dave Chinner To: Pavel Machek Cc: Christoph Hellwig , Takashi Sato , 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: <20080708231026.GP11558@disturbed> Mail-Followup-To: Pavel Machek , Christoph Hellwig , Takashi Sato , 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 References: <20080630212450t-sato@mail.jp.nec.com> <20080701081026.GB16691@infradead.org> <20080707110730.GG5643@ucw.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20080707110730.GG5643@ucw.cz> 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: 1215558633 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.55519 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: 16786 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 Mon, Jul 07, 2008 at 01:07:31PM +0200, Pavel Machek wrote: > Hi! > > > 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 > > What happens when someone dirties so much data that vm swaps out > whatever process that frozen the filesystem? a) you can't dirty a frozen filesystem - by definition a frozen filesystem is a *clean filesystem* and *cannot be dirtied*. b) Swap doesn't write through the filesystem c) you can still read from a frozen filesystem to page your executableѕ in. d) if dirtying another unfrozen filesystem swaps out your application so it can't run, then there's a major VM bug. Regardless, until the app completes it is relying on the filesystem being frozen, so it better remain frozen.... > I though that was why the timeout was there... Not that I know of. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Tue Jul 8 16:18:36 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 08 Jul 2008 16:18:38 -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 m68NIZEu011773 for ; Tue, 8 Jul 2008 16:18:36 -0700 X-ASG-Debug-ID: 1215559176-11e102b30000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from gprs189-60.eurotel.cz (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2F8A518939C0 for ; Tue, 8 Jul 2008 16:19:37 -0700 (PDT) Received: from gprs189-60.eurotel.cz (gprs189-60.eurotel.cz [160.218.189.60]) by cuda.sgi.com with ESMTP id vrB7FnmjaDKjPjwK for ; Tue, 08 Jul 2008 16:19:37 -0700 (PDT) Received: by gprs189-60.eurotel.cz (Postfix, from userid 1000) id 83CDE506; Wed, 9 Jul 2008 01:20:31 +0200 (CEST) Date: Wed, 9 Jul 2008 01:20:31 +0200 From: Pavel Machek To: Christoph Hellwig , Takashi Sato , 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: <20080708232031.GE18195@elf.ucw.cz> References: <20080630212450t-sato@mail.jp.nec.com> <20080701081026.GB16691@infradead.org> <20080707110730.GG5643@ucw.cz> <20080708231026.GP11558@disturbed> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080708231026.GP11558@disturbed> X-Warning: Reading this can be dangerous to your mental health. User-Agent: Mutt/1.5.17 (2007-11-01) X-Barracuda-Connect: gprs189-60.eurotel.cz[160.218.189.60] X-Barracuda-Start-Time: 1215559179 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.55521 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: 16787 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pavel@suse.cz Precedence: bulk X-list: xfs On Wed 2008-07-09 09:10:27, Dave Chinner wrote: > On Mon, Jul 07, 2008 at 01:07:31PM +0200, Pavel Machek wrote: > > Hi! > > > > > 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 > > > > What happens when someone dirties so much data that vm swaps out > > whatever process that frozen the filesystem? > > a) you can't dirty a frozen filesystem - by definition a frozen > filesystem is a *clean filesystem* and *cannot be dirtied*. Can you stop me? mmap("/some/huge_file", MAP_SHARED); then write to memory mapping? > b) Swap doesn't write through the filesystem > c) you can still read from a frozen filesystem to page your > executable?? in. atime modification should mean dirty data, right? And dirty data mean memory pressure, right? > d) if dirtying another unfrozen filesystem swaps out your ~~~~~~~ > application so it can't run, then there's a major VM bug. > Regardless, until the app completes it is relying on the > filesystem being frozen, so it better remain frozen.... Agreed. With emphasis on "another". > > I though that was why the timeout was there... > > Not that I know of. Ok, lets see how you deal with mmap. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html From owner-xfs@oss.sgi.com Tue Jul 8 17:51:54 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 08 Jul 2008 17:52: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.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 m690prDL022137 for ; Tue, 8 Jul 2008 17:51:54 -0700 X-ASG-Debug-ID: 1215564777-328702750000-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 ED6D92CBF71 for ; Tue, 8 Jul 2008 17:52:58 -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 RS5k1zKf9f0E2Mmu for ; Tue, 08 Jul 2008 17:52:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABioc0h5LFxA/2dsb2JhbACxKQ X-IronPort-AV: E=Sophos;i="4.30,327,1212330600"; d="scan'208";a="144800286" Received: from ppp121-44-92-64.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.92.64]) by ipmail01.adl6.internode.on.net with ESMTP; 09 Jul 2008 10:22:56 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KGNvS-0000qa-IC; Wed, 09 Jul 2008 10:52:54 +1000 Date: Wed, 9 Jul 2008 10:52:54 +1000 From: Dave Chinner To: Pavel Machek Cc: Christoph Hellwig , Takashi Sato , 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: <20080709005254.GQ11558@disturbed> Mail-Followup-To: Pavel Machek , Christoph Hellwig , Takashi Sato , 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 References: <20080630212450t-sato@mail.jp.nec.com> <20080701081026.GB16691@infradead.org> <20080707110730.GG5643@ucw.cz> <20080708231026.GP11558@disturbed> <20080708232031.GE18195@elf.ucw.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080708232031.GE18195@elf.ucw.cz> 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: 1215564778 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.55525 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: 16788 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 09, 2008 at 01:20:31AM +0200, Pavel Machek wrote: > On Wed 2008-07-09 09:10:27, Dave Chinner wrote: > > On Mon, Jul 07, 2008 at 01:07:31PM +0200, Pavel Machek wrote: > > > Hi! > > > > > > > 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 > > > > > > What happens when someone dirties so much data that vm swaps out > > > whatever process that frozen the filesystem? > > > > a) you can't dirty a frozen filesystem - by definition a frozen > > filesystem is a *clean filesystem* and *cannot be dirtied*. > > Can you stop me? > > mmap("/some/huge_file", MAP_SHARED); > > then write to memory mapping? Sure - we can put a hook in ->page_mkwrite() to prevent it. We don't right now because nobody in the real world really cares if one half of a concurrent user data change is in the old snapshot or the new one...... > > b) Swap doesn't write through the filesystem > > c) you can still read from a frozen filesystem to page your > > executable?? in. > > atime modification should mean dirty data, right? Metadata, not data. If that's really a problem (and it never has been for XFS because we always allow in memory changes to atime) then touch_atime could be easily changed to avoid this... > And dirty data mean > memory pressure, right? If you walk enough inodes while the filesystem is frozen, it theoretically could happen. Typically a filesystem is only for a few seconds at a time so in the real world this has never, ever been a problem. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Tue Jul 8 18:10:58 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 08 Jul 2008 18:11: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=-1.2 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 m691Awkn023535 for ; Tue, 8 Jul 2008 18:10:58 -0700 X-ASG-Debug-ID: 1215565922-75b600630000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from thunker.thunk.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 49F4F1894633 for ; Tue, 8 Jul 2008 18:12:02 -0700 (PDT) Received: from thunker.thunk.org (www.church-of-our-saviour.org [69.25.196.31]) by cuda.sgi.com with ESMTP id H9MydiP32djqWzZM for ; Tue, 08 Jul 2008 18:12:02 -0700 (PDT) Received: from root (helo=closure.thunk.org) by thunker.thunk.org with local-esmtp (Exim 4.50 #1 (Debian)) id 1KGOBQ-00066K-8m; Tue, 08 Jul 2008 21:09:24 -0400 Received: from tytso by closure.thunk.org with local (Exim 4.69) (envelope-from ) id 1KGOBO-0004AW-Ld; Tue, 08 Jul 2008 21:09:22 -0400 Date: Tue, 8 Jul 2008 21:09:22 -0400 From: Theodore Tso To: Pavel Machek , Christoph Hellwig , Takashi Sato , 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: <20080709010922.GE9957@mit.edu> Mail-Followup-To: Theodore Tso , Pavel Machek , Christoph Hellwig , Takashi Sato , 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 References: <20080630212450t-sato@mail.jp.nec.com> <20080701081026.GB16691@infradead.org> <20080707110730.GG5643@ucw.cz> <20080708231026.GP11558@disturbed> <20080708232031.GE18195@elf.ucw.cz> <20080709005254.GQ11558@disturbed> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080709005254.GQ11558@disturbed> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@mit.edu X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false X-Barracuda-Connect: www.church-of-our-saviour.org[69.25.196.31] X-Barracuda-Start-Time: 1215565923 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.55525 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: 16789 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tytso@mit.edu Precedence: bulk X-list: xfs On Wed, Jul 09, 2008 at 10:52:54AM +1000, Dave Chinner wrote: > If you walk enough inodes while the filesystem is frozen, it > theoretically could happen. Typically a filesystem is only for a > few seconds at a time so in the real world this has never, ever been > a problem. I had argued for the timeout (and so it's mostly my fault that Takashi-San included it as a feature) mainly because I was (and still amm) deeply paranoid about the competence of the application programers who might use this feature. I could see them screwing up leaving it locked forever --- perhaps when their program core dumps or when the user types ^C and they forgot to install a signal handler, leaving the filesystem frozen forever. In the meantime, user applications that try to create files on that filesystem, or write to files already opened when the filesystem are frozen will accumulate dirty pages in the page cache, until the system finally falls over. Think about some of the evil perpetrated by hal and the userspace suspend-resume scripts (and how much complexity with random XML fragments getting parsed by various dbus plugins), and tell me with a straight face that you would trust these modern-day desktop application writers with this interface. Because they *will* find some interesting way to (ab)use it..... Also, I didn't think the extra code complexity to implements timeouts was *that* bad --- it seemed fairly small for the functionality. Best regards, - Ted From owner-xfs@oss.sgi.com Tue Jul 8 22:49:52 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 08 Jul 2008 22:50: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=-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 m695now5013508 for ; Tue, 8 Jul 2008 22:49:52 -0700 X-ASG-Debug-ID: 1215582655-563901580000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from cynthia.pants.nu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C3B2869A21E for ; Tue, 8 Jul 2008 22:50:55 -0700 (PDT) Received: from cynthia.pants.nu ([76.245.85.235]) by cuda.sgi.com with ESMTP id mgWNdIqug0HxaF4v for ; Tue, 08 Jul 2008 22:50:55 -0700 (PDT) Received: from flar by cynthia.pants.nu with local (Exim 4.50) id 1KGRBb-0007Cc-RG; Tue, 08 Jul 2008 21:21:47 -0700 Date: Tue, 8 Jul 2008 21:21:47 -0700 From: Brad Boyer To: Theodore Tso , Pavel Machek , Christoph Hellwig , Takashi Sato , 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: <20080709042147.GB20695@cynthia.pants.nu> References: <20080630212450t-sato@mail.jp.nec.com> <20080701081026.GB16691@infradead.org> <20080707110730.GG5643@ucw.cz> <20080708231026.GP11558@disturbed> <20080708232031.GE18195@elf.ucw.cz> <20080709005254.GQ11558@disturbed> <20080709010922.GE9957@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080709010922.GE9957@mit.edu> User-Agent: Mutt/1.5.9i X-Barracuda-Connect: UNKNOWN[76.245.85.235] X-Barracuda-Start-Time: 1215582655 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -1.92 X-Barracuda-Spam-Status: No, SCORE=-1.92 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=RDNS_NONE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.55542 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.10 RDNS_NONE Delivered to trusted network by a host with no rDNS 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: 16790 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: flar@allandria.com Precedence: bulk X-list: xfs On Tue, Jul 08, 2008 at 09:09:22PM -0400, Theodore Tso wrote: > I had argued for the timeout (and so it's mostly my fault that > Takashi-San included it as a feature) mainly because I was (and still > amm) deeply paranoid about the competence of the application > programers who might use this feature. I could see them screwing up > leaving it locked forever --- perhaps when their program core dumps or > when the user types ^C and they forgot to install a signal handler, > leaving the filesystem frozen forever. > > In the meantime, user applications that try to create files on that > filesystem, or write to files already opened when the filesystem are > frozen will accumulate dirty pages in the page cache, until the system > finally falls over. > > Think about some of the evil perpetrated by hal and the userspace > suspend-resume scripts (and how much complexity with random XML > fragments getting parsed by various dbus plugins), and tell me with a > straight face that you would trust these modern-day desktop > application writers with this interface. Because they *will* find > some interesting way to (ab)use it..... > > Also, I didn't think the extra code complexity to implements timeouts > was *that* bad --- it seemed fairly small for the functionality. Just as an extra point of reference, VxFS supports a freeze/thaw by ioctl very similar to this including a timeout in seconds. This means someone else thought it was a useful feature. http://sfdoccentral.symantec.com/sf/5.0/linux/manpages/vxfs/vxfsio_7.html Brad Boyer flar@allandria.com From owner-xfs@oss.sgi.com Tue Jul 8 23:12:50 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 08 Jul 2008 23:12:53 -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 m696ClCO015387 for ; Tue, 8 Jul 2008 23:12:50 -0700 X-ASG-Debug-ID: 1215584031-3d4d00040000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pomaz-ex.szeredi.hu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3D3BD1895704 for ; Tue, 8 Jul 2008 23:13:52 -0700 (PDT) Received: from pomaz-ex.szeredi.hu (fxip-0047f.externet.hu [88.209.222.127]) by cuda.sgi.com with ESMTP id jKmeAoP2O8F4UDTV for ; Tue, 08 Jul 2008 23:13:52 -0700 (PDT) Received: from miko by pomaz-ex.szeredi.hu with local (Exim 4.63) (envelope-from ) id 1KGSvZ-0006dB-53; Wed, 09 Jul 2008 08:13:21 +0200 To: tytso@mit.edu CC: pavel@suse.cz, hch@infradead.org, t-sato@yk.jp.nec.com, 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 In-reply-to: <20080709010922.GE9957@mit.edu> (message from Theodore Tso on Tue, 8 Jul 2008 21:09:22 -0400) X-ASG-Orig-Subj: Re: [PATCH 3/3] Add timeout feature Subject: Re: [PATCH 3/3] Add timeout feature References: <20080630212450t-sato@mail.jp.nec.com> <20080701081026.GB16691@infradead.org> <20080707110730.GG5643@ucw.cz> <20080708231026.GP11558@disturbed> <20080708232031.GE18195@elf.ucw.cz> <20080709005254.GQ11558@disturbed> <20080709010922.GE9957@mit.edu> Message-Id: From: Miklos Szeredi Date: Wed, 09 Jul 2008 08:13:21 +0200 X-Barracuda-Connect: fxip-0047f.externet.hu[88.209.222.127] X-Barracuda-Start-Time: 1215584033 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.55543 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: 16791 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: miklos@szeredi.hu Precedence: bulk X-list: xfs On Tue, 8 Jul 2008, Theodore Tso wrote: > On Wed, Jul 09, 2008 at 10:52:54AM +1000, Dave Chinner wrote: > > If you walk enough inodes while the filesystem is frozen, it > > theoretically could happen. Typically a filesystem is only for a > > few seconds at a time so in the real world this has never, ever been > > a problem. > > I had argued for the timeout (and so it's mostly my fault that > Takashi-San included it as a feature) mainly because I was (and still > amm) deeply paranoid about the competence of the application > programers who might use this feature. I could see them screwing up > leaving it locked forever --- perhaps when their program core dumps or > when the user types ^C and they forgot to install a signal handler, > leaving the filesystem frozen forever. A much better way to deal with that would be to limit the freeze to the lifetime of the process somehow. E.g. the freeze ioctl sets a bit in struct file (I'm sure we have some available) and release on the file checks this bit and thaws the filesystem. This would mean that freeze and thaw will have to be done on the same file descriptor, but this isn't unreasonable to expect, is it? Miklos From owner-xfs@oss.sgi.com Tue Jul 8 23:15:35 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 08 Jul 2008 23:15: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,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 m696FYbP016152 for ; Tue, 8 Jul 2008 23:15:35 -0700 X-ASG-Debug-ID: 1215584199-3de0001f0000-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 DA0AD1895742 for ; Tue, 8 Jul 2008 23:16:39 -0700 (PDT) Received: from bombadil.infradead.org (bombadil.infradead.org [18.85.46.34]) by cuda.sgi.com with ESMTP id hSF2YTKC78u1HGEY for ; Tue, 08 Jul 2008 23:16:39 -0700 (PDT) Received: from hch by bombadil.infradead.org with local (Exim 4.68 #1 (Red Hat Linux)) id 1KGSyT-0003x4-Hf; Wed, 09 Jul 2008 06:16:21 +0000 Date: Wed, 9 Jul 2008 02:16:21 -0400 From: Christoph Hellwig To: Miklos Szeredi Cc: tytso@mit.edu, pavel@suse.cz, hch@infradead.org, t-sato@yk.jp.nec.com, 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: <20080709061621.GA5260@infradead.org> References: <20080630212450t-sato@mail.jp.nec.com> <20080701081026.GB16691@infradead.org> <20080707110730.GG5643@ucw.cz> <20080708231026.GP11558@disturbed> <20080708232031.GE18195@elf.ucw.cz> <20080709005254.GQ11558@disturbed> <20080709010922.GE9957@mit.edu> 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: 1215584199 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.55543 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: 16792 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 Wed, Jul 09, 2008 at 08:13:21AM +0200, Miklos Szeredi wrote: > This would mean that freeze and thaw will have to be done on the same > file descriptor, but this isn't unreasonable to expect, is it? It is certainly not the current use case, where you run one command to freeze the filesystem and another one to unfreeze it. From owner-xfs@oss.sgi.com Tue Jul 8 23:22:09 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 08 Jul 2008 23:22: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=-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 m696M93M016873 for ; Tue, 8 Jul 2008 23:22:09 -0700 X-ASG-Debug-ID: 1215584593-3de1008d0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pomaz-ex.szeredi.hu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 61E3D18954FF for ; Tue, 8 Jul 2008 23:23:14 -0700 (PDT) Received: from pomaz-ex.szeredi.hu (fxip-0047f.externet.hu [88.209.222.127]) by cuda.sgi.com with ESMTP id NHdLvy7xCqQrv2hV for ; Tue, 08 Jul 2008 23:23:14 -0700 (PDT) Received: from miko by pomaz-ex.szeredi.hu with local (Exim 4.63) (envelope-from ) id 1KGT4q-0006fD-Jb; Wed, 09 Jul 2008 08:22:56 +0200 To: hch@infradead.org CC: miklos@szeredi.hu, tytso@mit.edu, pavel@suse.cz, hch@infradead.org, t-sato@yk.jp.nec.com, 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 In-reply-to: <20080709061621.GA5260@infradead.org> (message from Christoph Hellwig on Wed, 9 Jul 2008 02:16:21 -0400) X-ASG-Orig-Subj: Re: [PATCH 3/3] Add timeout feature Subject: Re: [PATCH 3/3] Add timeout feature References: <20080630212450t-sato@mail.jp.nec.com> <20080701081026.GB16691@infradead.org> <20080707110730.GG5643@ucw.cz> <20080708231026.GP11558@disturbed> <20080708232031.GE18195@elf.ucw.cz> <20080709005254.GQ11558@disturbed> <20080709010922.GE9957@mit.edu> <20080709061621.GA5260@infradead.org> Message-Id: From: Miklos Szeredi Date: Wed, 09 Jul 2008 08:22:56 +0200 X-Barracuda-Connect: fxip-0047f.externet.hu[88.209.222.127] X-Barracuda-Start-Time: 1215584594 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.55545 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: 16793 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: miklos@szeredi.hu Precedence: bulk X-list: xfs On Wed, 9 Jul 2008, Christoph Hellwig wrote: > On Wed, Jul 09, 2008 at 08:13:21AM +0200, Miklos Szeredi wrote: > > This would mean that freeze and thaw will have to be done on the same > > file descriptor, but this isn't unreasonable to expect, is it? > > It is certainly not the current use case, where you run one command > to freeze the filesystem and another one to unfreeze it. So instead of freeze_fs mountpoint backup-command unfreeze_fs mountpoint the user would have do to run_freezed mountpoint backup-command I find the second one nicer, regardless of any reliability issues. Miklos From owner-xfs@oss.sgi.com Tue Jul 8 23:41:13 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 08 Jul 2008 23:41: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.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 m696fCgg018235 for ; Tue, 8 Jul 2008 23:41:12 -0700 X-ASG-Debug-ID: 1215585736-3de001910000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from casper.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id B418D18955AB for ; Tue, 8 Jul 2008 23:42:16 -0700 (PDT) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) by cuda.sgi.com with ESMTP id Z9CVRXgRLVRWfmvP for ; Tue, 08 Jul 2008 23:42:16 -0700 (PDT) Received: from c-71-193-193-226.hsd1.or.comcast.net ([71.193.193.226] helo=localhost.localdomain) by casper.infradead.org with esmtpsa (Exim 4.69 #1 (Red Hat Linux)) id 1KGTMu-0004hQ-SQ; Wed, 09 Jul 2008 06:41:39 +0000 Date: Tue, 8 Jul 2008 23:41:20 -0700 From: Arjan van de Ven To: Miklos Szeredi Cc: hch@infradead.org, miklos@szeredi.hu, tytso@mit.edu, pavel@suse.cz, t-sato@yk.jp.nec.com, 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: <20080708234120.5072111f@infradead.org> In-Reply-To: References: <20080630212450t-sato@mail.jp.nec.com> <20080701081026.GB16691@infradead.org> <20080707110730.GG5643@ucw.cz> <20080708231026.GP11558@disturbed> <20080708232031.GE18195@elf.ucw.cz> <20080709005254.GQ11558@disturbed> <20080709010922.GE9957@mit.edu> <20080709061621.GA5260@infradead.org> Organization: Intel X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: casper.infradead.org[85.118.1.10] X-Barracuda-Start-Time: 1215585736 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.55545 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: 16794 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: arjan@infradead.org Precedence: bulk X-list: xfs On Wed, 09 Jul 2008 08:22:56 +0200 Miklos Szeredi wrote: > On Wed, 9 Jul 2008, Christoph Hellwig wrote: > > On Wed, Jul 09, 2008 at 08:13:21AM +0200, Miklos Szeredi wrote: > > > This would mean that freeze and thaw will have to be done on the > > > same file descriptor, but this isn't unreasonable to expect, is > > > it? > > > > It is certainly not the current use case, where you run one command > > to freeze the filesystem and another one to unfreeze it. > > So instead of > > freeze_fs mountpoint > backup-command > unfreeze_fs mountpoint > > the user would have do to > > run_freezed mountpoint backup-command > > I find the second one nicer, regardless of any reliability issues. nah he needs to do make_snapshot ; backup-command ; unref_snapshot. freezing isn't the right solution for the backup problem ;) -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org From owner-xfs@oss.sgi.com Tue Jul 8 23:48:05 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 08 Jul 2008 23:48: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.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 m696m4Qi018870 for ; Tue, 8 Jul 2008 23:48:05 -0700 X-ASG-Debug-ID: 1215586149-1b8e004b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pomaz-ex.szeredi.hu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 6A4CD114C40C for ; Tue, 8 Jul 2008 23:49:09 -0700 (PDT) Received: from pomaz-ex.szeredi.hu (fxip-0047f.externet.hu [88.209.222.127]) by cuda.sgi.com with ESMTP id P9z6l9n5ACyhL8hd for ; Tue, 08 Jul 2008 23:49:09 -0700 (PDT) Received: from miko by pomaz-ex.szeredi.hu with local (Exim 4.63) (envelope-from ) id 1KGTTm-0006ke-Jh; Wed, 09 Jul 2008 08:48:42 +0200 To: arjan@infradead.org CC: miklos@szeredi.hu, hch@infradead.org, miklos@szeredi.hu, tytso@mit.edu, pavel@suse.cz, t-sato@yk.jp.nec.com, 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 In-reply-to: <20080708234120.5072111f@infradead.org> (message from Arjan van de Ven on Tue, 8 Jul 2008 23:41:20 -0700) X-ASG-Orig-Subj: Re: [PATCH 3/3] Add timeout feature Subject: Re: [PATCH 3/3] Add timeout feature References: <20080630212450t-sato@mail.jp.nec.com> <20080701081026.GB16691@infradead.org> <20080707110730.GG5643@ucw.cz> <20080708231026.GP11558@disturbed> <20080708232031.GE18195@elf.ucw.cz> <20080709005254.GQ11558@disturbed> <20080709010922.GE9957@mit.edu> <20080709061621.GA5260@infradead.org> <20080708234120.5072111f@infradead.org> Message-Id: From: Miklos Szeredi Date: Wed, 09 Jul 2008 08:48:42 +0200 X-Barracuda-Connect: fxip-0047f.externet.hu[88.209.222.127] X-Barracuda-Start-Time: 1215586150 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.55545 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: 16795 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: miklos@szeredi.hu Precedence: bulk X-list: xfs On Tue, 8 Jul 2008, Arjan van de Ven wrote: > nah he needs to do > > make_snapshot ; backup-command ; unref_snapshot. > > freezing isn't the right solution for the backup problem ;) Confused, what's freezing _is_ for then? Patch description says: 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. Miklos From owner-xfs@oss.sgi.com Tue Jul 8 23:55:29 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 08 Jul 2008 23:55:31 -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 m696tTXe019474 for ; Tue, 8 Jul 2008 23:55:29 -0700 X-ASG-Debug-ID: 1215586593-7a9602610000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from casper.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 9D39911E4F0A for ; Tue, 8 Jul 2008 23:56:34 -0700 (PDT) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) by cuda.sgi.com with ESMTP id 28QTYqtNYaaF45Eu for ; Tue, 08 Jul 2008 23:56:34 -0700 (PDT) Received: from c-71-193-193-226.hsd1.or.comcast.net ([71.193.193.226] helo=localhost.localdomain) by casper.infradead.org with esmtpsa (Exim 4.69 #1 (Red Hat Linux)) id 1KGTaU-0004rB-V5; Wed, 09 Jul 2008 06:55:42 +0000 Date: Tue, 8 Jul 2008 23:55:02 -0700 From: Arjan van de Ven To: Miklos Szeredi Cc: miklos@szeredi.hu, hch@infradead.org, tytso@mit.edu, pavel@suse.cz, t-sato@yk.jp.nec.com, 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: <20080708235502.1c52a586@infradead.org> In-Reply-To: References: <20080630212450t-sato@mail.jp.nec.com> <20080701081026.GB16691@infradead.org> <20080707110730.GG5643@ucw.cz> <20080708231026.GP11558@disturbed> <20080708232031.GE18195@elf.ucw.cz> <20080709005254.GQ11558@disturbed> <20080709010922.GE9957@mit.edu> <20080709061621.GA5260@infradead.org> <20080708234120.5072111f@infradead.org> Organization: Intel X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: casper.infradead.org[85.118.1.10] X-Barracuda-Start-Time: 1215586594 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.55545 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: 16796 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: arjan@infradead.org Precedence: bulk X-list: xfs On Wed, 09 Jul 2008 08:48:42 +0200 Miklos Szeredi wrote: > On Tue, 8 Jul 2008, Arjan van de Ven wrote: > > nah he needs to do > > > > make_snapshot ; backup-command ; unref_snapshot. > > > > freezing isn't the right solution for the backup problem ;) > > Confused, what's freezing _is_ for then? Patch description says: > > 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. I tihnk the idea there is freeze . do the snapshot op . unfreeze . make backup of snapshot one can argue about the need of doing the first 3 steps via a userland loop; it sure sounds like one needs to be really careful to not do any writes to the fs from the app that does snapshots (and that includes doing any syscalls in the kernel that allocate memory.. just because that already could cause unrelated data to be written from inside the app. Not fun.) -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org From owner-xfs@oss.sgi.com Tue Jul 8 23:58:54 2008 Received: with ECARTIS (v1.0.0; list xfs); Tue, 08 Jul 2008 23:58:59 -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 (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 m696wsJS020013 for ; Tue, 8 Jul 2008 23:58:54 -0700 X-ASG-Debug-ID: 1215586798-798a010f0000-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 C016F2CCC83 for ; Tue, 8 Jul 2008 23:59:58 -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 ss6UxDx18WfqtSiz for ; Tue, 08 Jul 2008 23:59:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHz8c0h5LFxA/2dsb2JhbACweg X-IronPort-AV: E=Sophos;i="4.30,330,1212330600"; d="scan'208";a="145060804" Received: from ppp121-44-92-64.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.92.64]) by ipmail01.adl6.internode.on.net with ESMTP; 09 Jul 2008 16:29:52 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KGTeY-0000Ci-El; Wed, 09 Jul 2008 16:59:50 +1000 Date: Wed, 9 Jul 2008 16:59:50 +1000 From: Dave Chinner To: Arjan van de Ven Cc: Miklos Szeredi , hch@infradead.org, tytso@mit.edu, pavel@suse.cz, t-sato@yk.jp.nec.com, 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: <20080709065950.GR11558@disturbed> Mail-Followup-To: Arjan van de Ven , Miklos Szeredi , hch@infradead.org, tytso@mit.edu, pavel@suse.cz, t-sato@yk.jp.nec.com, 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 References: <20080701081026.GB16691@infradead.org> <20080707110730.GG5643@ucw.cz> <20080708231026.GP11558@disturbed> <20080708232031.GE18195@elf.ucw.cz> <20080709005254.GQ11558@disturbed> <20080709010922.GE9957@mit.edu> <20080709061621.GA5260@infradead.org> <20080708234120.5072111f@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080708234120.5072111f@infradead.org> 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: 1215586799 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.55546 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: 16797 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 Tue, Jul 08, 2008 at 11:41:20PM -0700, Arjan van de Ven wrote: > On Wed, 09 Jul 2008 08:22:56 +0200 > Miklos Szeredi wrote: > > > On Wed, Jul 09, 2008 at 08:13:21AM +0200, Miklos Szeredi wrote: > > > > This would mean that freeze and thaw will have to be done on the > > > > same file descriptor, but this isn't unreasonable to expect, is > > > > it? > > > > > > It is certainly not the current use case, where you run one command > > > to freeze the filesystem and another one to unfreeze it. > > > > So instead of > > > > freeze_fs mountpoint > > backup-command > > unfreeze_fs mountpoint > > > > the user would have do to > > > > run_freezed mountpoint backup-command > > > > I find the second one nicer, regardless of any reliability issues. > > nah he needs to do > > make_snapshot ; backup-command ; unref_snapshot. > > freezing isn't the right solution for the backup problem ;) You're forgetting that to take a snapshot you generally need to freeze the filesystem. ;) i.e: freeze; make_snapshot; unfreeze backup-command unref_snapshot Yes, dm_snapshot does the freeze/snapshot/unfreeze for you, but the point is there is a freeze in the example you gave. The argument against Miklos' version is that there may be multiple commands to execute while the fs is frozen. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Wed Jul 9 00:07:22 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Jul 2008 00:07:27 -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 (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 m6977Me7023293 for ; Wed, 9 Jul 2008 00:07:22 -0700 X-ASG-Debug-ID: 1215587306-797f017b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pomaz-ex.szeredi.hu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id A32402CCDE6 for ; Wed, 9 Jul 2008 00:08:26 -0700 (PDT) Received: from pomaz-ex.szeredi.hu (fxip-0047f.externet.hu [88.209.222.127]) by cuda.sgi.com with ESMTP id MacgYVg355Tsnhbj for ; Wed, 09 Jul 2008 00:08:26 -0700 (PDT) Received: from miko by pomaz-ex.szeredi.hu with local (Exim 4.63) (envelope-from ) id 1KGTmZ-0006oz-Qi; Wed, 09 Jul 2008 09:08:07 +0200 To: arjan@infradead.org CC: miklos@szeredi.hu, miklos@szeredi.hu, hch@infradead.org, tytso@mit.edu, pavel@suse.cz, t-sato@yk.jp.nec.com, 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 In-reply-to: <20080708235502.1c52a586@infradead.org> (message from Arjan van de Ven on Tue, 8 Jul 2008 23:55:02 -0700) X-ASG-Orig-Subj: Re: [PATCH 3/3] Add timeout feature Subject: Re: [PATCH 3/3] Add timeout feature References: <20080630212450t-sato@mail.jp.nec.com> <20080701081026.GB16691@infradead.org> <20080707110730.GG5643@ucw.cz> <20080708231026.GP11558@disturbed> <20080708232031.GE18195@elf.ucw.cz> <20080709005254.GQ11558@disturbed> <20080709010922.GE9957@mit.edu> <20080709061621.GA5260@infradead.org> <20080708234120.5072111f@infradead.org> <20080708235502.1c52a586@infradead.org> Message-Id: From: Miklos Szeredi Date: Wed, 09 Jul 2008 09:08:07 +0200 X-Barracuda-Connect: fxip-0047f.externet.hu[88.209.222.127] X-Barracuda-Start-Time: 1215587307 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.55546 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: 16798 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: miklos@szeredi.hu Precedence: bulk X-list: xfs On Tue, 8 Jul 2008, Arjan van de Ven wrote: > I tihnk the idea there is > > freeze . do the snapshot op . unfreeze . make backup of snapshot Ah, so then my proposal would become run_frozen mountpoint do-snapshot do-backup release-snapshot and if they are afraid of deadlocks they can just implement the timeout in userspace: run_frozen -t timeout mountpoint do-snapshot 'run_frozen' can be a trivial 30 line app, that can be guaranteed not to deadlock. > one can argue about the need of doing the first 3 steps via a userland > loop; it sure sounds like one needs to be really careful to not do any > writes to the fs from the app that does snapshots (and that includes > doing any syscalls in the kernel that allocate memory.. just because > that already could cause unrelated data to be written from inside the > app. Not fun.) Userland always has to be careful when messing with raw devices. That alone is not a reason to put the snapshotting facility in kernel IMO. Miklos From owner-xfs@oss.sgi.com Wed Jul 9 00:12:47 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Jul 2008 00:12:49 -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 m697Cki6024019 for ; Wed, 9 Jul 2008 00:12:47 -0700 X-ASG-Debug-ID: 1215587630-3de003420000-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 7FB7A1895C07 for ; Wed, 9 Jul 2008 00:13:50 -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 xlNqlC7GTwPId4lW for ; Wed, 09 Jul 2008 00:13:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMr/c0h5LFxA/2dsb2JhbACweQ X-IronPort-AV: E=Sophos;i="4.30,330,1212330600"; d="scan'208";a="145069926" Received: from ppp121-44-92-64.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.92.64]) by ipmail01.adl6.internode.on.net with ESMTP; 09 Jul 2008 16:43:48 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KGTs2-0000VO-FF; Wed, 09 Jul 2008 17:13:46 +1000 Date: Wed, 9 Jul 2008 17:13:46 +1000 From: Dave Chinner To: Arjan van de Ven Cc: Miklos Szeredi , hch@infradead.org, tytso@mit.edu, pavel@suse.cz, t-sato@yk.jp.nec.com, 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: <20080709071346.GS11558@disturbed> Mail-Followup-To: Arjan van de Ven , Miklos Szeredi , hch@infradead.org, tytso@mit.edu, pavel@suse.cz, t-sato@yk.jp.nec.com, 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 References: <20080708231026.GP11558@disturbed> <20080708232031.GE18195@elf.ucw.cz> <20080709005254.GQ11558@disturbed> <20080709010922.GE9957@mit.edu> <20080709061621.GA5260@infradead.org> <20080708234120.5072111f@infradead.org> <20080708235502.1c52a586@infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080708235502.1c52a586@infradead.org> 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: 1215587631 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.55546 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: 16799 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 Tue, Jul 08, 2008 at 11:55:02PM -0700, Arjan van de Ven wrote: > On Wed, 09 Jul 2008 08:48:42 +0200 > Miklos Szeredi wrote: > > > On Tue, 8 Jul 2008, Arjan van de Ven wrote: > > > nah he needs to do > > > > > > make_snapshot ; backup-command ; unref_snapshot. > > > > > > freezing isn't the right solution for the backup problem ;) > > > > Confused, what's freezing _is_ for then? Patch description says: > > > > 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. > > I tihnk the idea there is > > freeze . do the snapshot op . unfreeze . make backup of snapshot > > one can argue about the need of doing the first 3 steps via a userland > loop; it sure sounds like one needs to be really careful to not do any > writes to the fs from the app that does snapshots (and that includes > doing any syscalls in the kernel that allocate memory.. just because > that already could cause unrelated data to be written from inside the > app. Not fun.) Bloody hell! Doesn't *anyone* understand that a frozen filesystem is *clean*? That the process of freezing it ensures all dirty data and metadata is written out before the freeze completes? And that once frozen, it can't be dirtied until unfrozen? That's 3 (or is it 4 - maybe 5 now that I think about it) different ppl in 24 hours that have made this same broken argument about being unable to write back dirty data on a frozen filesystem...... Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Wed Jul 9 00:13:04 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Jul 2008 00:13: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 m697D3aZ024158 for ; Wed, 9 Jul 2008 00:13:04 -0700 X-ASG-Debug-ID: 1215587647-4dd102b50000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pomaz-ex.szeredi.hu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 7F2461895C27 for ; Wed, 9 Jul 2008 00:14:08 -0700 (PDT) Received: from pomaz-ex.szeredi.hu (fxip-0047f.externet.hu [88.209.222.127]) by cuda.sgi.com with ESMTP id IGlmGKjfwvKGAsNE for ; Wed, 09 Jul 2008 00:14:08 -0700 (PDT) Received: from miko by pomaz-ex.szeredi.hu with local (Exim 4.63) (envelope-from ) id 1KGTrq-0006qj-1u; Wed, 09 Jul 2008 09:13:34 +0200 To: david@fromorbit.com CC: arjan@infradead.org, miklos@szeredi.hu, hch@infradead.org, tytso@mit.edu, pavel@suse.cz, t-sato@yk.jp.nec.com, 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 In-reply-to: <20080709065950.GR11558@disturbed> (message from Dave Chinner on Wed, 9 Jul 2008 16:59:50 +1000) X-ASG-Orig-Subj: Re: [PATCH 3/3] Add timeout feature Subject: Re: [PATCH 3/3] Add timeout feature References: <20080701081026.GB16691@infradead.org> <20080707110730.GG5643@ucw.cz> <20080708231026.GP11558@disturbed> <20080708232031.GE18195@elf.ucw.cz> <20080709005254.GQ11558@disturbed> <20080709010922.GE9957@mit.edu> <20080709061621.GA5260@infradead.org> <20080708234120.5072111f@infradead.org> <20080709065950.GR11558@disturbed> Message-Id: From: Miklos Szeredi Date: Wed, 09 Jul 2008 09:13:34 +0200 X-Barracuda-Connect: fxip-0047f.externet.hu[88.209.222.127] X-Barracuda-Start-Time: 1215587648 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.55546 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: 16800 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: miklos@szeredi.hu Precedence: bulk X-list: xfs On Wed, 9 Jul 2008, Dave Chinner wrote: > The argument against Miklos' version is that there may be multiple > commands to execute while the fs is frozen. Which is what a shell is for ;) Miklos From owner-xfs@oss.sgi.com Wed Jul 9 00:32:59 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Jul 2008 00:33: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.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_21, J_CHICKENPOX_46 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 m697Wxo4031601 for ; Wed, 9 Jul 2008 00:32:59 -0700 X-ASG-Debug-ID: 1215588843-4aa700110000-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 72237DD1B6D for ; Wed, 9 Jul 2008 00:34:03 -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 H9xWhGySNu0A3cSw for ; Wed, 09 Jul 2008 00:34:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAUHdEh5LFxA/2dsb2JhbACwcg X-IronPort-AV: E=Sophos;i="4.30,330,1212330600"; d="scan'208";a="145083240" Received: from ppp121-44-92-64.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.92.64]) by ipmail01.adl6.internode.on.net with ESMTP; 09 Jul 2008 17:04:00 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KGUBa-0000xD-UB; Wed, 09 Jul 2008 17:33:58 +1000 Date: Wed, 9 Jul 2008 17:33:58 +1000 From: Dave Chinner To: Miklos Szeredi Cc: arjan@infradead.org, hch@infradead.org, tytso@mit.edu, pavel@suse.cz, t-sato@yk.jp.nec.com, 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: <20080709073358.GT11558@disturbed> Mail-Followup-To: Miklos Szeredi , arjan@infradead.org, hch@infradead.org, tytso@mit.edu, pavel@suse.cz, t-sato@yk.jp.nec.com, 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 References: <20080708231026.GP11558@disturbed> <20080708232031.GE18195@elf.ucw.cz> <20080709005254.GQ11558@disturbed> <20080709010922.GE9957@mit.edu> <20080709061621.GA5260@infradead.org> <20080708234120.5072111f@infradead.org> <20080709065950.GR11558@disturbed> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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: 1215588844 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.55547 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: 16801 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 09, 2008 at 09:13:34AM +0200, Miklos Szeredi wrote: > On Wed, 9 Jul 2008, Dave Chinner wrote: > > The argument against Miklos' version is that there may be multiple > > commands to execute while the fs is frozen. > > Which is what a shell is for ;) Yeah, weÄŗl, with your method I ca't tell a user to: # xfs_freeze -f /mntpt # xfs_db -r -c 'sb 0' -c 'p rootino' /dev/foo 128 # xfs_db -r -c 'ino 128' -c 'p core.format' /dev/foo core.format = 2 (extents) # xfs_db ..... ..... # xfs_freeze -u /mntpt i.e. using the freeze to force all metadata to disk and prevent it from changing while doing interactive debugging of some problem. Yes, a one-shot freeze/unfreeze mechanism works for some use cases. The point is that it does not work for them all..... Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Wed Jul 9 01:10:18 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Jul 2008 01:10: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,J_CHICKENPOX_21, J_CHICKENPOX_46 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 m698AI67001386 for ; Wed, 9 Jul 2008 01:10:18 -0700 X-ASG-Debug-ID: 1215591083-60f4009b0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from pomaz-ex.szeredi.hu (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0139ADD1D0A for ; Wed, 9 Jul 2008 01:11:23 -0700 (PDT) Received: from pomaz-ex.szeredi.hu (fxip-0047f.externet.hu [88.209.222.127]) by cuda.sgi.com with ESMTP id 5nczH8YF61fTiAPW for ; Wed, 09 Jul 2008 01:11:23 -0700 (PDT) Received: from miko by pomaz-ex.szeredi.hu with local (Exim 4.63) (envelope-from ) id 1KGUlR-0006zH-FT; Wed, 09 Jul 2008 10:11:01 +0200 To: david@fromorbit.com CC: miklos@szeredi.hu, arjan@infradead.org, hch@infradead.org, tytso@mit.edu, pavel@suse.cz, t-sato@yk.jp.nec.com, 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 In-reply-to: <20080709073358.GT11558@disturbed> (message from Dave Chinner on Wed, 9 Jul 2008 17:33:58 +1000) X-ASG-Orig-Subj: Re: [PATCH 3/3] Add timeout feature Subject: Re: [PATCH 3/3] Add timeout feature References: <20080708231026.GP11558@disturbed> <20080708232031.GE18195@elf.ucw.cz> <20080709005254.GQ11558@disturbed> <20080709010922.GE9957@mit.edu> <20080709061621.GA5260@infradead.org> <20080708234120.5072111f@infradead.org> <20080709065950.GR11558@disturbed> <20080709073358.GT11558@disturbed> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Message-Id: From: Miklos Szeredi Date: Wed, 09 Jul 2008 10:11:01 +0200 X-Barracuda-Connect: fxip-0047f.externet.hu[88.209.222.127] X-Barracuda-Start-Time: 1215591084 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.55551 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: 16802 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: miklos@szeredi.hu Precedence: bulk X-list: xfs On Wed, 9 Jul 2008, Dave Chinner wrote: > On Wed, Jul 09, 2008 at 09:13:34AM +0200, Miklos Szeredi wrote: > > On Wed, 9 Jul 2008, Dave Chinner wrote: > > > The argument against Miklos' version is that there may be multiple > > > commands to execute while the fs is frozen. > > > > Which is what a shell is for ;) > > Yeah, weÄŗl, with your method I ca't tell a user to: > > # xfs_freeze -f /mntpt > # xfs_db -r -c 'sb 0' -c 'p rootino' /dev/foo > 128 > # xfs_db -r -c 'ino 128' -c 'p core.format' /dev/foo > core.format = 2 (extents) > # xfs_db ..... > ..... > # xfs_freeze -u /mntpt > > i.e. using the freeze to force all metadata to disk and > prevent it from changing while doing interactive debugging > of some problem. # run_freeze /mntpt /bin/bash # ... # ^D It's the same, no? Miklos From owner-xfs@oss.sgi.com Wed Jul 9 01:57:31 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Jul 2008 01:57:35 -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.0 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_38, J_CHICKENPOX_62,J_CHICKENPOX_64 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 m698vQEb004104 for ; Wed, 9 Jul 2008 01:57:28 -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 SAA16183; Wed, 9 Jul 2008 18:58:22 +1000 Message-ID: <48747DAD.7060501@sgi.com> Date: Wed, 09 Jul 2008 18:58:21 +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 2/3] simplify xfs_setattr References: <20080627154557.GB31476@lst.de> <20080705172021.GA7177@lst.de> In-Reply-To: <20080705172021.GA7177@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: 16803 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 Looks reasonable to me :) (odd notes below) --Tim Christoph Hellwig wrote: > 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: > > o stop using bhv_vattr_t and move over to struct iattr. where va_mask -> ia_valid > 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 */ Looks good. > 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; > } > So just need to keep the changes to the inode, don't need to set vattr as we are just passing thru iattr into xfs_setattr now. Fine. > - 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 > - So this code looks different. We are now dropping the flags. Why is that? Presumably because we were mapping ia_valid's: ATTR_MTIME_SET or ATTR_ATIME_SET --> ATTR_UTIME ATTR_NO_BLOCK -> ATTR_NONBLOCK But now we pass ATTR_?TIME_SET and ATTR_NO_BLOCK straight thru. So previously we didn't map them onto va_mask bits but as separate flags instead. > - error = xfs_setattr(XFS_I(inode), &vattr, flags, NULL); > + error = xfs_setattr(XFS_I(inode), iattr, 0, NULL); So no flags here now. > 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); > } > Fine. > 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) > Cool. Get rid of a whole bunch of stuff. > 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 */ > So where do these go now? Looking ahead: xfs_vnodeops.h: DMI,NONBLOCK,NOLOCK And UTIME, LAZY and NOSIZETOK are gone. LAZY doesn't seem to be used anywhere. NOSIZETOK is presumably for cxfs. UTIME is done by ATTR_MTIME_SET or ATTR_ATIME_SET now (passed straight thru). > /* > * 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); > - } > - So we get rid of the test for XFS_AT_NOSET. where: #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) I can't see anywhere we set any of these. Presumably out of the xattr calls. Some left over from IRIX I guess. > 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; > - } > - #define XFS_AT_UPDATIME 0x00010000 #define XFS_AT_UPDMTIME 0x00020000 #define XFS_AT_UPDCTIME 0x00040000 3 more not supported by vfs ATTR_* macros. I can't see where we set any of these. So no loss there I guess. Presumably they were just for IRIX. > 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) { Yeah, so we no longer support ATTR_NOSIZETOK (presumably for cxfs). > /* > * 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 */ > + So we don't bring thru: ATTR_UTIME, ATTR_LAZY, ATTR_NOSIZETOK > 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 Wed Jul 9 04:09:01 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Jul 2008 04:09: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=-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 m69B91eo021861 for ; Wed, 9 Jul 2008 04:09:01 -0700 X-ASG-Debug-ID: 1215601804-6ac003af0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from thunker.thunk.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 3BD602CDD30 for ; Wed, 9 Jul 2008 04:10:04 -0700 (PDT) Received: from thunker.thunk.org (www.church-of-our-saviour.org [69.25.196.31]) by cuda.sgi.com with ESMTP id CpSTwGGgqfjsrihu for ; Wed, 09 Jul 2008 04:10:04 -0700 (PDT) Received: from root (helo=closure.thunk.org) by thunker.thunk.org with local-esmtp (Exim 4.50 #1 (Debian)) id 1KGXXh-0007Y4-6j; Wed, 09 Jul 2008 07:09:01 -0400 Received: from tytso by closure.thunk.org with local (Exim 4.69) (envelope-from ) id 1KGXXg-0003LO-71; Wed, 09 Jul 2008 07:09:00 -0400 Date: Wed, 9 Jul 2008 07:09:00 -0400 From: Theodore Tso To: Arjan van de Ven , Miklos Szeredi , hch@infradead.org, pavel@suse.cz, t-sato@yk.jp.nec.com, 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: <20080709110900.GI9957@mit.edu> Mail-Followup-To: Theodore Tso , Arjan van de Ven , Miklos Szeredi , hch@infradead.org, pavel@suse.cz, t-sato@yk.jp.nec.com, 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 References: <20080708232031.GE18195@elf.ucw.cz> <20080709005254.GQ11558@disturbed> <20080709010922.GE9957@mit.edu> <20080709061621.GA5260@infradead.org> <20080708234120.5072111f@infradead.org> <20080708235502.1c52a586@infradead.org> <20080709071346.GS11558@disturbed> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080709071346.GS11558@disturbed> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@mit.edu X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false X-Barracuda-Connect: www.church-of-our-saviour.org[69.25.196.31] X-Barracuda-Start-Time: 1215601806 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.55561 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: 16804 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tytso@mit.edu Precedence: bulk X-list: xfs > > Bloody hell! Doesn't *anyone* understand that a frozen filesystem is > *clean*? That the process of freezing it ensures all dirty data and > metadata is written out before the freeze completes? And that once > frozen, it can't be dirtied until unfrozen? What do you mean by "it can't be diritied until unfrozen". What happens if I have a kernel compilation happening on a filesystem which I am trying to freeze? Does (a) the freeze fail (because the checks equivalent to what happens when you remount a filesystem read-only happen)? (b) The process gets a kill -9 when it tries to write a file on the frozen filesystem? (c) The process gets a kill -STOP when it tries to write to a file on the frozen filesystem? (d) The process won't fail, but just continue to run, filling the page cache with dirty pages that can't be written out because the filesystem is frozen? If the answer is (b) or (c), and if you don't have a timeout, and the backup process which has frozen the filesystem tries to write to the filesystem, hilarity will ensue.... > That's 3 (or is it 4 - maybe 5 now that I think about it) different > ppl in 24 hours that have made this same broken argument about > being unable to write back dirty data on a frozen filesystem...... It's not a question of writing back dirty data, it's the fact that you *can't*, leading to the page cache filling up wirth dirty data, leading eventually to the OOM killer running --- and since the last time I tried suggesting that if the process holding the file descriptor freezing the filesystem, that idea got shot down (I see it's been suggested again), if that happens, there is going to be no other recovery path other than the Big Red Button. - Ted From owner-xfs@oss.sgi.com Wed Jul 9 04:14:31 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Jul 2008 04:14: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.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_21, J_CHICKENPOX_46,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 m69BEUEJ022660 for ; Wed, 9 Jul 2008 04:14:31 -0700 X-ASG-Debug-ID: 1215602134-618d036f0000-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 4F0D3189CA5D for ; Wed, 9 Jul 2008 04:15:35 -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 031Y17RuvIApZfE5 for ; Wed, 09 Jul 2008 04:15:35 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAAA4dEh5LFxA/2dsb2JhbACwCg X-IronPort-AV: E=Sophos;i="4.30,331,1212330600"; d="scan'208";a="145208332" Received: from ppp121-44-92-64.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.92.64]) by ipmail01.adl6.internode.on.net with ESMTP; 09 Jul 2008 20:45:32 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KGXdu-0005jw-G0; Wed, 09 Jul 2008 21:15:26 +1000 Date: Wed, 9 Jul 2008 21:15:26 +1000 From: Dave Chinner To: Miklos Szeredi Cc: arjan@infradead.org, hch@infradead.org, tytso@mit.edu, pavel@suse.cz, t-sato@yk.jp.nec.com, 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: <20080709111526.GU11558@disturbed> Mail-Followup-To: Miklos Szeredi , arjan@infradead.org, hch@infradead.org, tytso@mit.edu, pavel@suse.cz, t-sato@yk.jp.nec.com, 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 References: <20080709005254.GQ11558@disturbed> <20080709010922.GE9957@mit.edu> <20080709061621.GA5260@infradead.org> <20080708234120.5072111f@infradead.org> <20080709065950.GR11558@disturbed> <20080709073358.GT11558@disturbed> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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: 1215602136 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.55561 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: 16805 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 09, 2008 at 10:11:01AM +0200, Miklos Szeredi wrote: > On Wed, 9 Jul 2008, Dave Chinner wrote: > > On Wed, Jul 09, 2008 at 09:13:34AM +0200, Miklos Szeredi wrote: > > > On Wed, 9 Jul 2008, Dave Chinner wrote: > > > > The argument against Miklos' version is that there may be multiple > > > > commands to execute while the fs is frozen. > > > > > > Which is what a shell is for ;) > > > > Yeah, weÄŗl, with your method I ca't tell a user to: > > > > # xfs_freeze -f /mntpt > > # xfs_db -r -c 'sb 0' -c 'p rootino' /dev/foo > > 128 > > # xfs_db -r -c 'ino 128' -c 'p core.format' /dev/foo > > core.format = 2 (extents) > > # xfs_db ..... > > ..... > > # xfs_freeze -u /mntpt > > > > i.e. using the freeze to force all metadata to disk and > > prevent it from changing while doing interactive debugging > > of some problem. > > # run_freeze /mntpt /bin/bash > # ... > # ^D > > It's the same, no? For that case, yeah. But it's a horrible hack - if that's the best we can come up with for this freeze/unfreeze then we've already lost. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Wed Jul 9 04:48:58 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Jul 2008 04:49: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.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 m69BmvXR000817 for ; Wed, 9 Jul 2008 04:48:58 -0700 X-ASG-Debug-ID: 1215604201-31c602a90000-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 3C7592CDC81 for ; Wed, 9 Jul 2008 04:50:02 -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 IZiavC6JSiK1pWVM for ; Wed, 09 Jul 2008 04:50:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMdCdEh5LFxA/2dsb2JhbACwCw X-IronPort-AV: E=Sophos;i="4.30,331,1212330600"; d="scan'208";a="145222754" Received: from ppp121-44-92-64.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.92.64]) by ipmail01.adl6.internode.on.net with ESMTP; 09 Jul 2008 21:20:00 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KGYBK-0006W4-SQ; Wed, 09 Jul 2008 21:49:58 +1000 Date: Wed, 9 Jul 2008 21:49:58 +1000 From: Dave Chinner To: Theodore Tso , Arjan van de Ven , Miklos Szeredi , hch@infradead.org, pavel@suse.cz, t-sato@yk.jp.nec.com, 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: <20080709114958.GV11558@disturbed> Mail-Followup-To: Theodore Tso , Arjan van de Ven , Miklos Szeredi , hch@infradead.org, pavel@suse.cz, t-sato@yk.jp.nec.com, 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 References: <20080709005254.GQ11558@disturbed> <20080709010922.GE9957@mit.edu> <20080709061621.GA5260@infradead.org> <20080708234120.5072111f@infradead.org> <20080708235502.1c52a586@infradead.org> <20080709071346.GS11558@disturbed> <20080709110900.GI9957@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080709110900.GI9957@mit.edu> 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: 1215604203 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.55566 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: 16806 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 09, 2008 at 07:09:00AM -0400, Theodore Tso wrote: > > > > Bloody hell! Doesn't *anyone* understand that a frozen filesystem is > > *clean*? That the process of freezing it ensures all dirty data and > > metadata is written out before the freeze completes? And that once > > frozen, it can't be dirtied until unfrozen? > > What do you mean by "it can't be diritied until unfrozen". What > happens if I have a kernel compilation happening on a filesystem which > I am trying to freeze? Does > (a) the freeze fail (because the checks equivalent to what happens > when you remount a filesystem read-only happen)? > > (b) The process gets a kill -9 when it tries to write a file on the > frozen filesystem? > > (c) The process gets a kill -STOP when it tries to write > to a file on the frozen filesystem? > > (d) The process won't fail, but just continue to run, filling the page > cache with dirty pages that can't be written out because the > filesystem is frozen? (e) none of the above. The kernel compilation will appear to pause until the filesystem is unfrozen. No other visible effect should occur. It will get blocked in a write or filesystem transaction because the fs is frozen. Look at vfs_check_frozen() - any call to that will block if the filesystem is frozen or being frozen. The generic hook is in __generic_file_aio_write_nolock() and various other filesystems have calls in their specific write paths (fuse, ntfs, ocfs2, xfs, xip) to do this. For all other modifications, filesystem specific methods of blocking transactions are used. XFS uses vfs_check_frozen() in xfs_trans_alloc(), ext3 (and probably ocfs2) do it via their ->write_super_lockfs method calling journal_lock_updates(), ext4 via jbd2_lock_updates() and so on.... When the filesystem is unfrozen the journal is unlocked and anything sleeping on the vfs_check_frozen() waitqueue is woken..... Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Wed Jul 9 05:23:38 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Jul 2008 05:23: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=-1.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 m69CNb9T003374 for ; Wed, 9 Jul 2008 05:23:38 -0700 X-ASG-Debug-ID: 1215606281-404d02b10000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from thunker.thunk.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 35E75189D13C for ; Wed, 9 Jul 2008 05:24:42 -0700 (PDT) Received: from thunker.thunk.org (www.church-of-our-saviour.org [69.25.196.31]) by cuda.sgi.com with ESMTP id sVn7BuULP3bwOIVC for ; Wed, 09 Jul 2008 05:24:42 -0700 (PDT) Received: from root (helo=closure.thunk.org) by thunker.thunk.org with local-esmtp (Exim 4.50 #1 (Debian)) id 1KGYiS-0007lp-SL; Wed, 09 Jul 2008 08:24:12 -0400 Received: from tytso by closure.thunk.org with local (Exim 4.69) (envelope-from ) id 1KGYiH-0007hJ-NM; Wed, 09 Jul 2008 08:24:01 -0400 Date: Wed, 9 Jul 2008 08:24:01 -0400 From: Theodore Tso To: Arjan van de Ven , Miklos Szeredi , hch@infradead.org, pavel@suse.cz, t-sato@yk.jp.nec.com, 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: <20080709122401.GK9957@mit.edu> Mail-Followup-To: Theodore Tso , Arjan van de Ven , Miklos Szeredi , hch@infradead.org, pavel@suse.cz, t-sato@yk.jp.nec.com, 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 References: <20080709010922.GE9957@mit.edu> <20080709061621.GA5260@infradead.org> <20080708234120.5072111f@infradead.org> <20080708235502.1c52a586@infradead.org> <20080709071346.GS11558@disturbed> <20080709110900.GI9957@mit.edu> <20080709114958.GV11558@disturbed> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080709114958.GV11558@disturbed> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@mit.edu X-SA-Exim-Scanned: No (on thunker.thunk.org); SAEximRunCond expanded to false X-Barracuda-Connect: www.church-of-our-saviour.org[69.25.196.31] X-Barracuda-Start-Time: 1215606283 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.55568 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: 16807 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: tytso@mit.edu Precedence: bulk X-list: xfs On Wed, Jul 09, 2008 at 09:49:58PM +1000, Dave Chinner wrote: > (e) none of the above. The kernel compilation will appear to pause > until the filesystem is unfrozen. No other visible effect should > occur. It will get blocked in a write or filesystem transaction > because the fs is frozen. So if the process which froze the filesystem accidentally tries writing to a log file (or database file containing the backup information, or whatever) that happens to be on the filesystem that is frozen, that process will get blocked and you end up in a deadlock; did I get that right? - Ted From owner-xfs@oss.sgi.com Wed Jul 9 05:59:25 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Jul 2008 05:59: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.2 required=5.0 tests=AWL,BAYES_00,MIME_8BIT_HEADER, 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 m69CxO0C009561 for ; Wed, 9 Jul 2008 05:59:25 -0700 X-ASG-Debug-ID: 1215608428-446c00cf0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from orchid.cbk.poznan.pl (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 0F8BD1BB390A for ; Wed, 9 Jul 2008 06:00:28 -0700 (PDT) Received: from orchid.cbk.poznan.pl (orchid.cbk.poznan.pl [150.254.183.30]) by cuda.sgi.com with ESMTP id j7pQjhL1hNYdw3KZ for ; Wed, 09 Jul 2008 06:00:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by orchid.cbk.poznan.pl (Postfix) with ESMTP id B139EE4996B; Wed, 9 Jul 2008 15:00:26 +0200 (CEST) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: by amavisd-new at cbk.poznan.pl Received: from orchid.cbk.poznan.pl ([127.0.0.1]) by localhost (orchid.cbk.poznan.pl [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ul2fXHigh4Sa; Wed, 9 Jul 2008 15:00:24 +0200 (CEST) Received: from venus.local.navi.pl (ip-83-238-212-180.netia.com.pl [83.238.212.180]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by orchid.cbk.poznan.pl (Postfix) with ESMTP id 5103AE498ED; Wed, 9 Jul 2008 15:00:24 +0200 (CEST) X-ASG-Orig-Subj: Re: [PATCH 3/3] Add timeout feature Subject: Re: [PATCH 3/3] Add timeout feature From: Olaf =?iso-8859-2?Q?Fr=B1czyk?= To: Theodore Tso Cc: Arjan van de Ven , Miklos Szeredi , hch@infradead.org, pavel@suse.cz, t-sato@yk.jp.nec.com, 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 In-Reply-To: <20080709122401.GK9957@mit.edu> References: <20080709010922.GE9957@mit.edu> <20080709061621.GA5260@infradead.org> <20080708234120.5072111f@infradead.org> <20080708235502.1c52a586@infradead.org> <20080709071346.GS11558@disturbed> <20080709110900.GI9957@mit.edu> <20080709114958.GV11558@disturbed> <20080709122401.GK9957@mit.edu> Content-Type: text/plain; charset=UTF-8 Date: Wed, 09 Jul 2008 14:59:20 +0200 Message-Id: <1215608360.20914.14.camel@venus.local.navi.pl> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-3) Content-Transfer-Encoding: 8bit X-Barracuda-Connect: orchid.cbk.poznan.pl[150.254.183.30] X-Barracuda-Start-Time: 1215608430 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.55570 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- X-Virus-Status: Clean X-archive-position: 16808 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: olaf@cbk.poznan.pl Precedence: bulk X-list: xfs On Wed, 2008-07-09 at 08:24 -0400, Theodore Tso wrote: > On Wed, Jul 09, 2008 at 09:49:58PM +1000, Dave Chinner wrote: > > (e) none of the above. The kernel compilation will appear to pause > > until the filesystem is unfrozen. No other visible effect should > > occur. It will get blocked in a write or filesystem transaction > > because the fs is frozen. > > So if the process which froze the filesystem accidentally tries > writing to a log file (or database file containing the backup > information, or whatever) that happens to be on the filesystem that is > frozen, that process will get blocked and you end up in a deadlock; > did I get that right? Where do you see the deadlock? The process doesn't have a lock on filesystem or something. You can always unfreeze from another process. Regards, Olaf -- Olaf Frączyk From owner-xfs@oss.sgi.com Wed Jul 9 06:53:27 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Jul 2008 06:53: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.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 m69DrPbG014188 for ; Wed, 9 Jul 2008 06:53:27 -0700 X-ASG-Debug-ID: 1215611668-7d38027c0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from casper.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C0E30123B8F7 for ; Wed, 9 Jul 2008 06:54:28 -0700 (PDT) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) by cuda.sgi.com with ESMTP id SrwCghbCY2qy79ko for ; Wed, 09 Jul 2008 06:54:28 -0700 (PDT) Received: from c-71-193-193-226.hsd1.or.comcast.net ([71.193.193.226] helo=localhost.localdomain) by casper.infradead.org with esmtpsa (Exim 4.69 #1 (Red Hat Linux)) id 1KGa6v-0001NP-BE; Wed, 09 Jul 2008 13:53:33 +0000 Date: Wed, 9 Jul 2008 06:53:36 -0700 From: Arjan van de Ven To: Dave Chinner Cc: Miklos Szeredi , hch@infradead.org, tytso@mit.edu, pavel@suse.cz, t-sato@yk.jp.nec.com, 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: <20080709065336.1e5e4d74@infradead.org> In-Reply-To: <20080709071346.GS11558@disturbed> References: <20080708231026.GP11558@disturbed> <20080708232031.GE18195@elf.ucw.cz> <20080709005254.GQ11558@disturbed> <20080709010922.GE9957@mit.edu> <20080709061621.GA5260@infradead.org> <20080708234120.5072111f@infradead.org> <20080708235502.1c52a586@infradead.org> <20080709071346.GS11558@disturbed> Organization: Intel X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: casper.infradead.org[85.118.1.10] X-Barracuda-Start-Time: 1215611670 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.55573 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: 16809 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: arjan@infradead.org Precedence: bulk X-list: xfs On Wed, 9 Jul 2008 17:13:46 +1000 Dave Chinner wrote: > > one can argue about the need of doing the first 3 steps via a > > userland loop; it sure sounds like one needs to be really careful > > to not do any writes to the fs from the app that does snapshots > > (and that includes doing any syscalls in the kernel that allocate > > memory.. just because that already could cause unrelated data to be > > written from inside the app. Not fun.) > > Bloody hell! Doesn't *anyone* understand that a frozen filesystem is > *clean*? That the process of freezing it ensures all dirty data and > metadata is written out before the freeze completes? And that once > frozen, it can't be dirtied until unfrozen? > > That's 3 (or is it 4 - maybe 5 now that I think about it) different > ppl in 24 hours that have made this same broken argument about > being unable to write back dirty data on a frozen filesystem...... unless you also freeze the system as a whole (in a 'refrigerator suspend' way).. the "clean" part is just about a nanosecond long. After that stuff gets dirty again (you're doing that sendfile to receive more packets from the FTP upload etc etc). Sure you can pause those. But there's a real risk that you end up pausing the app that you want to unfreeze the fs (via the memory allocation->direct reclaim path). And no, mlock doesn't help. Especially with delayed allocation, where data writes will cause metadata activity, this is not just theory. -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org From owner-xfs@oss.sgi.com Wed Jul 9 06:55:04 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Jul 2008 06:55: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.6 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 m69Dt2xn014620 for ; Wed, 9 Jul 2008 06:55:04 -0700 X-ASG-Debug-ID: 1215611764-473a03cb0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from casper.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 2CC802CE915 for ; Wed, 9 Jul 2008 06:56:05 -0700 (PDT) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) by cuda.sgi.com with ESMTP id jQxmJ2otFpFsA7On for ; Wed, 09 Jul 2008 06:56:05 -0700 (PDT) Received: from c-71-193-193-226.hsd1.or.comcast.net ([71.193.193.226] helo=localhost.localdomain) by casper.infradead.org with esmtpsa (Exim 4.69 #1 (Red Hat Linux)) id 1KGa8h-0001PC-PI; Wed, 09 Jul 2008 13:55:24 +0000 Date: Wed, 9 Jul 2008 06:55:40 -0700 From: Arjan van de Ven To: Dave Chinner Cc: Theodore Tso , Miklos Szeredi , hch@infradead.org, pavel@suse.cz, t-sato@yk.jp.nec.com, 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: <20080709065540.57305d91@infradead.org> In-Reply-To: <20080709114958.GV11558@disturbed> References: <20080709005254.GQ11558@disturbed> <20080709010922.GE9957@mit.edu> <20080709061621.GA5260@infradead.org> <20080708234120.5072111f@infradead.org> <20080708235502.1c52a586@infradead.org> <20080709071346.GS11558@disturbed> <20080709110900.GI9957@mit.edu> <20080709114958.GV11558@disturbed> Organization: Intel X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: casper.infradead.org[85.118.1.10] X-Barracuda-Start-Time: 1215611767 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.55574 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: 16810 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: arjan@infradead.org Precedence: bulk X-list: xfs On Wed, 9 Jul 2008 21:49:58 +1000 Dave Chinner wrote: > > (e) none of the above. The kernel compilation will appear to pause > until the filesystem is unfrozen. No other visible effect should > occur. It will get blocked in a write or filesystem transaction > because the fs is frozen. > > Look at vfs_check_frozen() - any call to that will block if the > filesystem is frozen or being frozen. The generic hook is in > __generic_file_aio_write_nolock() and various other filesystems have > calls in their specific write paths (fuse, ntfs, ocfs2, xfs, xip) to > do this. yeah and mmap doesn't happen > > For all other modifications, filesystem specific methods of > blocking transactions are used. XFS uses vfs_check_frozen() in > xfs_trans_alloc(), ext3 (and probably ocfs2) do it via > their ->write_super_lockfs method calling journal_lock_updates(), > ext4 via jbd2_lock_updates() and so on.... and what if it's the process that you need to unfreeze the fs later? Good luck. -- If you want to reach me at my work email, use arjan@linux.intel.com For development, discussion and tips for power savings, visit http://www.lesswatts.org From owner-xfs@oss.sgi.com Wed Jul 9 06:57:07 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Jul 2008 06:57: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.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 m69Dv5Lu015342 for ; Wed, 9 Jul 2008 06:57:07 -0700 X-ASG-Debug-ID: 1215611891-79a802b60000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from g5t0006.atlanta.hp.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 98571C605FD for ; Wed, 9 Jul 2008 06:58:11 -0700 (PDT) Received: from g5t0006.atlanta.hp.com (g5t0006.atlanta.hp.com [15.192.0.43]) by cuda.sgi.com with ESMTP id CsUYH0tVEOBCaGvD for ; Wed, 09 Jul 2008 06:58:11 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from g4t0009.houston.hp.com (g4t0009.houston.hp.com [16.234.32.26]) by g5t0006.atlanta.hp.com (Postfix) with ESMTP id C7013CB42; Wed, 9 Jul 2008 13:58:09 +0000 (UTC) Received: from ldl.fc.hp.com (ldl.fc.hp.com [15.11.146.30]) by g4t0009.houston.hp.com (Postfix) with ESMTP id 991677C488; Wed, 9 Jul 2008 13:58:06 +0000 (UTC) Received: from localhost (ldl.fc.hp.com [127.0.0.1]) by ldl.fc.hp.com (Postfix) with ESMTP id 9D63E39C00D; Wed, 9 Jul 2008 07:58:06 -0600 (MDT) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: Debian amavisd-new at ldl.fc.hp.com Received: from ldl.fc.hp.com ([127.0.0.1]) by localhost (ldl.fc.hp.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B6H-VsiHETl7; Wed, 9 Jul 2008 07:58:02 -0600 (MDT) Received: from [16.116.96.85] (wizofoz.zko.hp.com [16.116.96.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ldl.fc.hp.com (Postfix) with ESMTP id 32C8439C017; Wed, 9 Jul 2008 07:58:01 -0600 (MDT) Message-ID: <4874C3E8.20804@hp.com> Date: Wed, 09 Jul 2008 09:58:00 -0400 From: jim owens User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:1.7.13) Gecko/20060421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-fsdevel@vger.kernel.org CC: Dave Chinner , Theodore Tso , Arjan van de Ven , Miklos Szeredi , hch@infradead.org, pavel@suse.cz, t-sato@yk.jp.nec.com, akpm@linux-foundation.org, viro@ZenIV.linux.org.uk, linux-ext4@vger.kernel.org, xfs@oss.sgi.com, dm-devel@redhat.com, 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 References: <20080709005254.GQ11558@disturbed> <20080709010922.GE9957@mit.edu> <20080709061621.GA5260@infradead.org> <20080708234120.5072111f@infradead.org> <20080708235502.1c52a586@infradead.org> <20080709071346.GS11558@disturbed> <20080709110900.GI9957@mit.edu> <20080709114958.GV11558@disturbed> In-Reply-To: <20080709114958.GV11558@disturbed> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Barracuda-Connect: g5t0006.atlanta.hp.com[15.192.0.43] X-Barracuda-Start-Time: 1215611891 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Status: Clean X-archive-position: 16811 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jowens@hp.com Precedence: bulk X-list: xfs Jumping into the battle... Advfs implemented freezefs and thawfs in 2001 so here is the design rational from a commercial unix view. Note - We already had built-in snapshots for local disk consistent backups so some choices might be different on Linux. NEED - provide way for SAN and hardware raid storage to do its snapshot/copy function while the system was in-use and get an image that could mount cleanly. Without freeze, at a minimum we usually needed filesystem metadata recovery to run, worst case is completely unusable snapshits :) freezefs() is single-level: ENOTSUPPOTED - by any other fs EOK - done EINPROGRESS EALREADY As implemented, freezefs only ensures the metadata is consistent so the filesystem copy can mount anywhere. This means ONLY SOME metadata (or no metadata) is flushed and then all metadata updates are stopped. User/kernel writes to already allocated file pages WILL go to a frozen disk. It also means writers that need storage allocation (not delaloc or existing) and things that semantically must force on-disk updates will hang during the freeze. These semantics meet the need and has the advantage of the best perfomance. The design specification for freezefs provided flags on the api to add more consistency options later if they were desired: - flush all dirty metadata - flush all existing dirty file data - prevent new dirty file data to disk but they would all add to the "kill the system" problem. freezefs has the timeout argument and the default timeout is a system config parameter: > 0 specifies the timeout value = 0 uses the default timeout < 0 disable timeout A program could call the freezefs/thawfs api, but the only current use is the separate commands # freezefs # [do your hardware raid stuff] # thawfs This is either operator driven or script/cron driven because hardware raid providers (especially our own) are really unfriendly and not helpful. NUMBER ONE RULE - freeze must not hang/crash the system because that defeats the customer reason for wanting it. WHY A TIMEOUT - need a way for operator to abort the freeze because with a frozen filesystem they may not even be able to do a login to thaw it! Users get pissed when the system is hung for a long time and our experience with SAN devices is that their response to commands is often unreasonably long. In addition to the user controllable timeout mechanism, we internally implement AUTO-THAW in the filesystem whenever necessary to prevent a kernel hang/crash. If an AUTO-THAW occurs, we post to the log and an event manager so the user knows the snapshot is bad. jim From owner-xfs@oss.sgi.com Wed Jul 9 06:57:12 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Jul 2008 06:57:14 -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,MIME_8BIT_HEADER 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 m69DvCI9015394 for ; Wed, 9 Jul 2008 06:57:12 -0700 X-ASG-Debug-ID: 1215611896-4b9e03230000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from casper.infradead.org (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id AE7F02CECAB for ; Wed, 9 Jul 2008 06:58:17 -0700 (PDT) Received: from casper.infradead.org (casper.infradead.org [85.118.1.10]) by cuda.sgi.com with ESMTP id 3964NAHjdeMj42KM for ; Wed, 09 Jul 2008 06:58:17 -0700 (PDT) Received: from c-71-193-193-226.hsd1.or.comcast.net ([71.193.193.226] helo=localhost.localdomain) by casper.infradead.org with esmtpsa (Exim 4.69 #1 (Red Hat Linux)) id 1KGaAt-0001RH-Kw; Wed, 09 Jul 2008 13:57:40 +0000 Date: Wed, 9 Jul 2008 06:57:58 -0700 From: Arjan van de Ven To: Olaf =?UTF-8?B?RnLEhWN6eWs=?= Cc: Theodore Tso , Miklos Szeredi , hch@infradead.org, pavel@suse.cz, t-sato@yk.jp.nec.com, 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: <20080709065758.4ac6b3c5@infradead.org> In-Reply-To: <1215608360.20914.14.camel@venus.local.navi.pl> References: <20080709010922.GE9957@mit.edu> <20080709061621.GA5260@infradead.org> <20080708234120.5072111f@infradead.org> <20080708235502.1c52a586@infradead.org> <20080709071346.GS11558@disturbed> <20080709110900.GI9957@mit.edu> <20080709114958.GV11558@disturbed> <20080709122401.GK9957@mit.edu> <1215608360.20914.14.camel@venus.local.navi.pl> Organization: Intel X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.10; i386-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-SRS-Rewrite: SMTP reverse-path rewritten from by casper.infradead.org See http://www.infradead.org/rpr.html X-Barracuda-Connect: casper.infradead.org[85.118.1.10] X-Barracuda-Start-Time: 1215611897 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.55574 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 m69DvCI9015401 X-archive-position: 16812 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: arjan@infradead.org Precedence: bulk X-list: xfs On Wed, 09 Jul 2008 14:59:20 +0200 Olaf Frączyk wrote: > On Wed, 2008-07-09 at 08:24 -0400, Theodore Tso wrote: > > On Wed, Jul 09, 2008 at 09:49:58PM +1000, Dave Chinner wrote: > > > (e) none of the above. The kernel compilation will appear to > > > pause until the filesystem is unfrozen. No other visible effect > > > should occur. It will get blocked in a write or filesystem > > > transaction because the fs is frozen. > > > > So if the process which froze the filesystem accidentally tries > > writing to a log file (or database file containing the backup > > information, or whatever) that happens to be on the filesystem that > > is frozen, that process will get blocked and you end up in a > > deadlock; did I get that right? > Where do you see the deadlock? > The process doesn't have a lock on filesystem or something. You can > always unfreeze from another process. > if it's one of your main filesystems... good luck starting a shell without writing a single thing to disk... FAIL. From owner-xfs@oss.sgi.com Wed Jul 9 07:12:25 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Jul 2008 07:12: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 m69ECO8C018009 for ; Wed, 9 Jul 2008 07:12:25 -0700 X-ASG-Debug-ID: 1215612809-469d005f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from g1t0026.austin.hp.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 74C28189F0D4 for ; Wed, 9 Jul 2008 07:13:30 -0700 (PDT) Received: from g1t0026.austin.hp.com (g1t0026.austin.hp.com [15.216.28.33]) by cuda.sgi.com with ESMTP id 6Rx0OgoKQBhIWye2 for ; Wed, 09 Jul 2008 07:13:30 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from g1t0038.austin.hp.com (g1t0038.austin.hp.com [16.236.32.44]) by g1t0026.austin.hp.com (Postfix) with ESMTP id 85ED2CBD3; Wed, 9 Jul 2008 14:13:27 +0000 (UTC) Received: from ldl.fc.hp.com (ldl.fc.hp.com [15.11.146.30]) by g1t0038.austin.hp.com (Postfix) with ESMTP id 9C6A33000D; Wed, 9 Jul 2008 14:13:26 +0000 (UTC) Received: from localhost (ldl.fc.hp.com [127.0.0.1]) by ldl.fc.hp.com (Postfix) with ESMTP id 8F64839C06E; Wed, 9 Jul 2008 08:13:25 -0600 (MDT) X-Virus-Scanned: ClamAV 0.91.2/6021/Wed Feb 27 15:55:48 2008 on oss.sgi.com X-Virus-Scanned: Debian amavisd-new at ldl.fc.hp.com Received: from ldl.fc.hp.com ([127.0.0.1]) by localhost (ldl.fc.hp.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piTInnJ1aX2K; Wed, 9 Jul 2008 08:13:21 -0600 (MDT) Received: from [16.116.96.85] (wizofoz.zko.hp.com [16.116.96.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ldl.fc.hp.com (Postfix) with ESMTP id 3407639C00D; Wed, 9 Jul 2008 08:13:20 -0600 (MDT) Message-ID: <4874C77F.7070602@hp.com> Date: Wed, 09 Jul 2008 10:13:19 -0400 From: jim owens User-Agent: Mozilla/5.0 (X11; U; OSF1 alpha; en-US; rv:1.7.13) Gecko/20060421 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-fsdevel@vger.kernel.org CC: Dave Chinner , Theodore Tso , Arjan van de Ven , Miklos Szeredi , hch@infradead.org, pavel@suse.cz, t-sato@yk.jp.nec.com, akpm@linux-foundation.org, viro@ZenIV.linux.org.uk, linux-ext4@vger.kernel.org, xfs@oss.sgi.com, dm-devel@redhat.com, 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 References: <20080709005254.GQ11558@disturbed> <20080709010922.GE9957@mit.edu> <20080709061621.GA5260@infradead.org> <20080708234120.5072111f@infradead.org> <20080708235502.1c52a586@infradead.org> <20080709071346.GS11558@disturbed> <20080709110900.GI9957@mit.edu> <20080709114958.GV11558@disturbed> <4874C3E8.20804@hp.com> In-Reply-To: <4874C3E8.20804@hp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Barracuda-Connect: g1t0026.austin.hp.com[15.216.28.33] X-Barracuda-Start-Time: 1215612810 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Virus-Status: Clean X-archive-position: 16813 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: jowens@hp.com Precedence: bulk X-list: xfs Oops.. > WHY A TIMEOUT - need a way for operator to abort the > freeze instead of "abort" I should have said "limit" because it is really proactive control (so they will not get called in the middle of the night by pissed users). I forgot to make it clear that TIMEOUT is the same as AUTO-THAW in logging errors so the adnin knows they have a bad snapshot and can do it again. I also forgot to say that our customers all say they can deal with retrying a snapshot, but not with unknown bad snapshots and most definitely not with killing their 24/7 operations! jim From owner-xfs@oss.sgi.com Wed Jul 9 08:54:14 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Jul 2008 08:54: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_00,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 m69FsDcB032267 for ; Wed, 9 Jul 2008 08:54:13 -0700 X-ASG-Debug-ID: 1215618918-0b8903600000-w1Z2WR X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from omr-d25.mx.aol.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 98E752CDA9B for ; Wed, 9 Jul 2008 08:55:18 -0700 (PDT) Received: from omr-d25.mx.aol.com (omr-d25.mx.aol.com [205.188.249.69]) by cuda.sgi.com with ESMTP id Dmz1g57TSNW1YzVL for ; Wed, 09 Jul 2008 08:55:18 -0700 (PDT) X-ASG-Whitelist: Barracuda Reputation Received: from rly-df02.mx.aol.com (rly-df02.mx.aol.com [205.188.252.6]) by omr-d25.mx.aol.com (v117.7) with ESMTP id MAILOMRD258-7d8b4874df59142; Wed, 09 Jul 2008 11:55:05 -0400 Received: from localhost (localhost) by rly-df02.mx.aol.com (8.14.1/8.14.1) id m69FsnFr024241; Wed, 9 Jul 2008 11:55:05 -0400 Date: Wed, 9 Jul 2008 11:55:05 -0400 From: Mail Delivery Subsystem Message-Id: <200807091555.m69FsnFr024241@rly-df02.mx.aol.com> To: MIME-Version: 1.0 Content-Type: multipart/report; report-type=delivery-status; boundary="m69FsnFr024241.1215618905/rly-df02.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: reverse.204.8.184.66.static.ldmi.com [66.184.8.204] rly-df02 X-AOL-IP: 205.188.252.6 X-Barracuda-Connect: omr-d25.mx.aol.com[205.188.249.69] X-Barracuda-Start-Time: 1215618919 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: 16814 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 --m69FsnFr024241.1215618905/rly-df02.mx.aol.com The original message was received at Wed, 9 Jul 2008 11:54:35 -0400 from reverse.204.8.184.66.static.ldmi.com [66.184.8.204] *** 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-df04.mail.aol.com.: >>> DATA <<< 554 TRANSACTION FAILED - Unrepairable Virus Detected. Your mail has not been sent. 554 5.0.0 Service unavailable --m69FsnFr024241.1215618905/rly-df02.mx.aol.com Content-Type: message/delivery-status Reporting-MTA: dns; rly-df02.mx.aol.com Arrival-Date: Wed, 9 Jul 2008 11:54:35 -0400 Final-Recipient: RFC822; geoffbyrd@aol.com Action: failed Status: 5.0.0 Remote-MTA: DNS; air-df04.mail.aol.com Diagnostic-Code: SMTP; 554 TRANSACTION FAILED - Unrepairable Virus Detected. Your mail has not been sent. Last-Attempt-Date: Wed, 9 Jul 2008 11:55:05 -0400 --m69FsnFr024241.1215618905/rly-df02.mx.aol.com Content-Type: text/rfc822-headers Received: from oss.sgi.com (reverse.204.8.184.66.static.ldmi.com [66.184.8.204]) by rly-df02.mx.aol.com (v121.5) with ESMTP id MAILRELAYINDF026-5334874df39e6; Wed, 09 Jul 2008 11:54:34 -0400 From: linux-xfs@oss.sgi.com To: geoffbyrd@aol.com Subject: Delivery reports about your e-mail Date: Wed, 9 Jul 2008 11:54:34 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0006_A29D1E24.83530DE3" 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: 66.184.8.204 X-AOL-SCOLL-SCORE:0:2:146085616: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: <200807091154.5334874df39e6@rly-df02.mx.aol.com> --m69FsnFr024241.1215618905/rly-df02.mx.aol.com-- From owner-xfs@oss.sgi.com Wed Jul 9 09:28:25 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Jul 2008 09:28: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.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 m69GSOlD003565 for ; Wed, 9 Jul 2008 09:28:25 -0700 X-ASG-Debug-ID: 1215620968-2ea502650000-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 AF87A189F6D9; Wed, 9 Jul 2008 09:29:28 -0700 (PDT) Received: from verein.lst.de (verein.lst.de [213.95.11.210]) by cuda.sgi.com with ESMTP id FAWuvcUJXbLexYRn; Wed, 09 Jul 2008 09:29:28 -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 m69GTGNW017068 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 9 Jul 2008 18:29:16 +0200 Received: (from hch@localhost) by verein.lst.de (8.12.3/8.12.3/Debian-6.6) id m69GTEMD017065; Wed, 9 Jul 2008 18:29:14 +0200 Date: Wed, 9 Jul 2008 18:29:14 +0200 From: Christoph Hellwig To: Timothy Shimmin Cc: 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: <20080709162914.GA16308@lst.de> References: <20080627154557.GB31476@lst.de> <20080705172021.GA7177@lst.de> <48747DAD.7060501@sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48747DAD.7060501@sgi.com> 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: 1215620969 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.55584 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: 16815 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 Wed, Jul 09, 2008 at 06:58:21PM +1000, Timothy Shimmin wrote: > > - 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 > > - > > So this code looks different. > We are now dropping the flags. Why is that? > Presumably because we were mapping ia_valid's: > ATTR_MTIME_SET or ATTR_ATIME_SET --> ATTR_UTIME > ATTR_NO_BLOCK -> ATTR_NONBLOCK > But now we pass ATTR_?TIME_SET and ATTR_NO_BLOCK straight thru. > So previously we didn't map them onto va_mask bits but as separate flags > instead. Yeah, not that ATTR_NO_BLOCK doesn't actually exist in any tree I have access to, and thus it's not actually handled in the new xfs_setattr. > So we get rid of the test for XFS_AT_NOSET. > where: > #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) > > I can't see anywhere we set any of these. > Presumably out of the xattr calls. > Some left over from IRIX I guess. Probably. Note that linux uses the ATTR_ flags only for ->setattr so there are per defintion none that can't be set. > #define XFS_AT_UPDATIME 0x00010000 > #define XFS_AT_UPDMTIME 0x00020000 > #define XFS_AT_UPDCTIME 0x00040000 > 3 more not supported by vfs ATTR_* macros. > I can't see where we set any of these. > So no loss there I guess. > Presumably they were just for IRIX. It's an IRIX leftover. I will submit a patch to introduce something similar to Linux for 2.6.27, that's why I'd like these patches in for 2.6.26 so that I have a clean base to start from. From owner-xfs@oss.sgi.com Wed Jul 9 09:56:08 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Jul 2008 09:56: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=-2.0 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 m69Gu7hf006502 for ; Wed, 9 Jul 2008 09:56:08 -0700 X-ASG-Debug-ID: 1215622631-6f9c03090000-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 6D360DDABEC for ; Wed, 9 Jul 2008 09:57:12 -0700 (PDT) Received: from bby1mta02.pmc-sierra.bc.ca (bby1mta02.pmc-sierra.com [216.241.235.117]) by cuda.sgi.com with ESMTP id 4EdQua2VeC5VQRXX for ; Wed, 09 Jul 2008 09:57:12 -0700 (PDT) Received: from bby1mta02.pmc-sierra.bc.ca (localhost.pmc-sierra.bc.ca [127.0.0.1]) by localhost (Postfix) with SMTP id 2B31A8E008D; Wed, 9 Jul 2008 10:00:02 -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 165108E008B; Wed, 9 Jul 2008 10:00:02 -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, 9 Jul 2008 09:57:51 -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: Wed, 9 Jul 2008 09:57:48 -0700 Message-ID: <340C71CD25A7EB49BFA81AE8C839266702A08F91@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> In-Reply-To: <4872E33E.3090107@sandeen.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Xfs Access to block zero exception and system crash Thread-Index: AcjgrWReJLSDlJRQSj6EZpV6D5oEvQBNiDiQ References: <4872E0BC.6070400@pmc-sierra.com> <4872E33E.3090107@sandeen.net> From: "Sagar Borikar" To: "Eric Sandeen" Cc: X-OriginalArrivalTime: 09 Jul 2008 16:57:51.0012 (UTC) FILETIME=[EC1C2640:01C8E1E4] X-Barracuda-Connect: bby1mta02.pmc-sierra.com[216.241.235.117] X-Barracuda-Start-Time: 1215622632 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.55584 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 m69Gu8hf006509 X-archive-position: 16816 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 Sagar Borikar wrote: > That's right Eric but I am still surprised that why should we get a dead > lock in this scenario as it is a plain copy of file in multiple > directories. Our customer is reporting similar kind of lockup in our > platform. ok, I guess I had missed that, sorry. > I do understand that we are chasing the access to block zero > exception and XFS forced shutdown which I mentioned earlier. But we > also see quite a few smbd processes which are writing data to XFS are in > uninterruptible sleep state and the system locks up too. Ok; then the next step is probably to do sysrq-t and see where things are stuck. It might be better to see if you can reproduce w/o the loopback file, too, since that's just another layer to go through that might be changing things. I ran it on actual device w/o loopback file and even there observed that XFS transactions going into uninterruptible sleep state and the copies were stalled. I had to hard reboot the system to bring XFS out of that state since soft reboot didn't work, it was waiting for file system to get unmounted. I shall provide the sysrq-t update later. > So I thought > the test which I am running could be pointing to similar issue which we > are observing on our platform. But does this indicate that the problem > lies with x86 XFS too ? or maybe the vm ... > Also I presume in enterprise market such kind > of simultaneous write situation may happen. Has anybody reported > similar issues to you? As you observed it over x86 and 2.6.24 kernel, > could you say what would be root cause of this? Haven't really seen it before that I recall, and at this point can't say for sure what it might be. -Eric > Sorry for lots of questions at same time :) But I am happy that you > were able to see the deadlock in x86 on your setup with 2.6.24 > > Thanks > Sagar > > > Eric Sandeen wrote: >> Sagar Borikar wrote: >> >>> Hi Eric, >>> >>> Did you see any issues in your test? >>> >> I got a deadlock but that's it; I don't think that's the bug you want to >> chase... >> >> >> -Eric >> >> >>> Thanks >>> Sagar >>> >>> >>> Sagar Borikar wrote: >>> >>>> Eric Sandeen wrote: >>>> >>>>> Sagar Borikar wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> Could you kindly try with my test? I presume you should see failure >>>>>> soon. I tried this on >>>>>> 2 different x86 systems 2 times ( after rebooting the system ) and I >>>>>> saw it every time. >>>>>> >>>>>> >>>>> Sure. Is there a reason you're doing this on a loopback file? That >>>>> probably stresses the vm a bit more, and might get even trickier if the >>>>> loopback file is sparse... >>>>> >>>>> >>>> Initially I thought to do that since I didn't want to have a strict >>>> allocation limit but >>>> allowing allocations to grow as needed until the backing filesystem >>>> runs out of free space >>>> due to type of the test case I had. But then I dropped the plan and >>>> created a non-sparse >>>> loopback device. There was no specific reason to create loopback but >>>> as it was >>>> simplest option to do it. >>>> >>>>> But anyway, on an x86_64 machine with 2G of memory and a non-sparse 10G >>>>> loopback file on 2.6.24.7-92.fc8, your test runs w/o problems for me, >>>>> though the system does get sluggish. I let it run a bit then ran repair >>>>> and it found no problems, I'll run it overnight to see if anything else >>>>> turns up. >>>>> >>>>> >>>> That will be great. Thanks indeed. >>>> Sagar >>>> >>>> >>>>> -Eric >>>>> >>>>> >> > From owner-xfs@oss.sgi.com Wed Jul 9 13:54:39 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Jul 2008 13:54: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.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 m69Kscd1027876 for ; Wed, 9 Jul 2008 13:54:39 -0700 X-ASG-Debug-ID: 1215636928-7cbf01440000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from spitz.ucw.cz (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id C8ED52D1C3D for ; Wed, 9 Jul 2008 13:55:34 -0700 (PDT) Received: from spitz.ucw.cz (gprs189-60.eurotel.cz [160.218.189.60]) by cuda.sgi.com with ESMTP id DDNL9ouyg4f96XWD for ; Wed, 09 Jul 2008 13:55:34 -0700 (PDT) Received: by spitz.ucw.cz (Postfix, from userid 0) id 0853B27879; Wed, 9 Jul 2008 20:48:30 +0000 (UTC) Date: Wed, 9 Jul 2008 22:48:30 +0200 From: Pavel Machek To: Miklos Szeredi Cc: arjan@infradead.org, hch@infradead.org, tytso@mit.edu, t-sato@yk.jp.nec.com, 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: <20080709204829.GH11006@ucw.cz> References: <20080708232031.GE18195@elf.ucw.cz> <20080709005254.GQ11558@disturbed> <20080709010922.GE9957@mit.edu> <20080709061621.GA5260@infradead.org> <20080708234120.5072111f@infradead.org> <20080708235502.1c52a586@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Barracuda-Connect: gprs189-60.eurotel.cz[160.218.189.60] X-Barracuda-Start-Time: 1215636942 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.55598 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: 16817 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pavel@suse.cz Precedence: bulk X-list: xfs On Wed 2008-07-09 09:08:07, Miklos Szeredi wrote: > On Tue, 8 Jul 2008, Arjan van de Ven wrote: > > I tihnk the idea there is > > > > freeze . do the snapshot op . unfreeze . make backup of snapshot > > Ah, so then my proposal would become > > run_frozen mountpoint do-snapshot > do-backup > release-snapshot > > and if they are afraid of deadlocks they can just implement the > timeout in userspace: > > run_frozen -t timeout mountpoint do-snapshot > > 'run_frozen' can be a trivial 30 line app, that can be guaranteed not > to deadlock. Userland apps can be swapped out and need kernel memory allocations during syscalls. I bet even sleep(30) uses kmalloc internally. So yes, even trivial applications can deadlock. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html From owner-xfs@oss.sgi.com Wed Jul 9 13:55:05 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Jul 2008 13:55: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.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 m69Kt27Y027947 for ; Wed, 9 Jul 2008 13:55:03 -0700 X-ASG-Debug-ID: 1215636930-31a102d40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from spitz.ucw.cz (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 02F69123BE7A for ; Wed, 9 Jul 2008 13:55:38 -0700 (PDT) Received: from spitz.ucw.cz (gprs189-60.eurotel.cz [160.218.189.60]) by cuda.sgi.com with ESMTP id oTWqmD2IiPI2x14m for ; Wed, 09 Jul 2008 13:55:38 -0700 (PDT) Received: by spitz.ucw.cz (Postfix, from userid 0) id 62F2427878; Wed, 9 Jul 2008 20:44:13 +0000 (UTC) Date: Wed, 9 Jul 2008 22:44:13 +0200 From: Pavel Machek To: Christoph Hellwig , Takashi Sato , 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: <20080709204412.GG11006@ucw.cz> References: <20080630212450t-sato@mail.jp.nec.com> <20080701081026.GB16691@infradead.org> <20080707110730.GG5643@ucw.cz> <20080708231026.GP11558@disturbed> <20080708232031.GE18195@elf.ucw.cz> <20080709005254.GQ11558@disturbed> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080709005254.GQ11558@disturbed> User-Agent: Mutt/1.5.9i X-Barracuda-Connect: gprs189-60.eurotel.cz[160.218.189.60] X-Barracuda-Start-Time: 1215636967 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.55597 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: 16818 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: pavel@suse.cz Precedence: bulk X-list: xfs Hi! > > > > > 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 > > > > > > > > What happens when someone dirties so much data that vm swaps out > > > > whatever process that frozen the filesystem? > > > > > > a) you can't dirty a frozen filesystem - by definition a frozen > > > filesystem is a *clean filesystem* and *cannot be dirtied*. > > > > Can you stop me? > > > > mmap("/some/huge_file", MAP_SHARED); > > > > then write to memory mapping? > > Sure - we can put a hook in ->page_mkwrite() to prevent it. We > don't right now because nobody in the real world really cares if one > half of a concurrent user data change is in the old snapshot or the > new one...... > > > > b) Swap doesn't write through the filesystem > > > c) you can still read from a frozen filesystem to page your > > > executable?? in. > > > > atime modification should mean dirty data, right? > > Metadata, not data. If that's really a problem (and it never has > been for XFS because we always allow in memory changes to atime) > then touch_atime could be easily changed to avoid this... > > > And dirty data mean > > memory pressure, right? > > If you walk enough inodes while the filesystem is frozen, it > theoretically could happen. Typically a filesystem is only for a > few seconds at a time so in the real world this has never, ever been > a problem. So we have freezing interface that does not really freeze, and that can break the system when filesystem is frozen for too long... :-(. Maybe you could use process freezer -- cgroup people are adding userspace interface to that -- to solve those... but that would mean stopping everyone but thread doing freezing... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html From owner-xfs@oss.sgi.com Wed Jul 9 16:58:33 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Jul 2008 16:58: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=-0.8 required=5.0 tests=ANY_BOUNCE_MESSAGE,BAYES_05, MISSING_MIMEOLE,RDNS_NONE,VBOUNCE_MESSAGE 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 m69NwWkO008539 for ; Wed, 9 Jul 2008 16:58:33 -0700 X-ASG-Debug-ID: 1215647977-660b00d40000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from outbound-mail-81.bluehost.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with SMTP id 7DC8318A15EC for ; Wed, 9 Jul 2008 16:59:37 -0700 (PDT) Received: from outbound-mail-81.bluehost.com (outbound-mail-81.bluehost.com [69.89.22.20]) by cuda.sgi.com with SMTP id gNu1rzwxnoRlalem for ; Wed, 09 Jul 2008 16:59:37 -0700 (PDT) Received: (qmail 28630 invoked for bounce); 9 Jul 2008 23:59:36 -0000 Date: 9 Jul 2008 23:59:36 -0000 From: MAILER-DAEMON@outbound-mail-81.bluehost.com To: xfs@oss.sgi.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="1215647976outbound-mail-81.bluehost.com5534804" X-ASG-Orig-Subj: failure notice Subject: ***** SUSPECTED SPAM ***** failure notice X-Barracuda-Connect: outbound-mail-81.bluehost.com[69.89.22.20] X-Barracuda-Start-Time: 1215647978 Message-Id: <20080709235937.7DC8318A15EC@cuda.sgi.com> X-Barracuda-Bayes: INNOCENT GLOBAL 0.5014 1.0000 0.7500 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 2.01 X-Barracuda-Spam-Status: Yes, SCORE=2.01 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=ANY_BOUNCE_MESSAGE, BOUNCE_MESSAGE, MSGID_FROM_MTA_ID, NO_REAL_NAME, VBOUNCE_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.55609 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.55 NO_REAL_NAME From: does not include a real name 0.70 MSGID_FROM_MTA_ID Message-Id for external message added locally 0.00 VBOUNCE_MESSAGE Virus-scanner bounce message 0.00 BOUNCE_MESSAGE MTA bounce message 0.00 ANY_BOUNCE_MESSAGE Message is some kind of bounce message X-Priority: 5 (Lowest) X-MSMail-Priority: Low Importance: Low X-Barracuda-Spam-Flag: YES 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: 16819 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@outbound-mail-81.bluehost.com Precedence: bulk X-list: xfs --1215647976outbound-mail-81.bluehost.com5534804 Hi. This is the qmail-send program at outbound-mail-81.bluehost.com. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. : 209.85.201.27 failed after I sent the message. Remote host said: 552-5.7.0 Our system detected an illegal attachment on your message. 552-5.7.0 Please visit http://mail.google.com/support/bin/answer.py?answer=6590 552 5.7.0 to review our attachment guidelines. 9si11292553wfc.6 --- Enclosed are the original headers of the message. --1215647976outbound-mail-81.bluehost.com5534804 Content-Type: message/rfc822 Return-Path: Received: (qmail 28611 invoked by uid 0); 9 Jul 2008 23:59:36 -0000 Received: from unknown (HELO box303.bluehost.com) (69.89.31.103) by forwardproxy3.bluehost.com with SMTP; 9 Jul 2008 23:59:35 -0000 Received: from pop-cowbird.atl.sa.earthlink.net ([207.69.195.68]) by box303.bluehost.com with esmtp (Exim 4.69) (envelope-from ) id 1KGjZP-0007J8-9M for jasonsilver@crookedbush.com; Wed, 09 Jul 2008 17:59:35 -0600 Received: from user-119abd2.biz.mindspring.com ([66.149.45.162] helo=lucerne.solutionip.com) by pop-cowbird.atl.sa.earthlink.net with esmtp (Exim 3.36 #1) id 1KGjZN-000772-00 for jasonsilver@crookedbush.com; Wed, 09 Jul 2008 19:59:34 -0400 Received: from [172.16.1.215] (helo=oss.sgi.com) by lucerne.solutionip.com with esmtp (Exim 3.34 #1) id 1KGjZF-00061C-00 for jasonsilver@crookedbush.com; Wed, 09 Jul 2008 19:59:26 -0400 From: xfs@oss.sgi.com To: jasonsilver@crookedbush.com Subject: status Date: Wed, 9 Jul 2008 19:59:25 -0400 MIME-Version: 1.0 Content-Type: multipart/mixed; This is a multi-part message in MIME format... ---- --1215647976outbound-mail-81.bluehost.com5534804-- From owner-xfs@oss.sgi.com Wed Jul 9 22:02:23 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Jul 2008 22:02: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.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 m6A52JJU032708 for ; Wed, 9 Jul 2008 22:02:21 -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 PAA10318; Thu, 10 Jul 2008 15:03:15 +1000 Message-ID: <48759813.2080601@sgi.com> Date: Thu, 10 Jul 2008 15:03:15 +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> <486C75DD.2040109@sgi.com> In-Reply-To: <486C75DD.2040109@sgi.com> 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: 16820 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 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. > > Don > Ok I hit the Oops again last weekend without the patch. Which means I have a patch to checkin and another bug to fix Yea! Dave, Eric said this should still be considered signed-off-by you, You ok with that? Eric, am I ok to add yours too since you kept this on the radar? Don From owner-xfs@oss.sgi.com Wed Jul 9 22:09:18 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Jul 2008 22:09: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.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 m6A59HTe000829 for ; Wed, 9 Jul 2008 22:09:18 -0700 X-ASG-Debug-ID: 1215666622-176701cb0000-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 7E11DDE2D4B for ; Wed, 9 Jul 2008 22:10:22 -0700 (PDT) Received: from sandeen.net (sandeen.net [209.173.210.139]) by cuda.sgi.com with ESMTP id yq28ENG8xegpG2EE for ; Wed, 09 Jul 2008 22:10: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 BEEA3AC6278; Thu, 10 Jul 2008 00:10:21 -0500 (CDT) Message-ID: <487599BD.2040003@sandeen.net> Date: Thu, 10 Jul 2008 00:10:21 -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> <48759813.2080601@sgi.com> In-Reply-To: <48759813.2080601@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: 1215666623 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0004 1.0000 -2.0183 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.55630 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: 16821 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: > 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. >> >> Don >> > > Ok I hit the Oops again last weekend without the patch. > Which means I have a patch to checkin and another bug to fix Yea! > > Dave, Eric said this should still be considered signed-off-by you, > You ok with that? > Eric, am I ok to add yours too since you kept this on the radar? That's fine by me, thanks. -Eric From owner-xfs@oss.sgi.com Wed Jul 9 22:11:10 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Jul 2008 22:11: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.0 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 m6A5BAND001223 for ; Wed, 9 Jul 2008 22:11:10 -0700 X-ASG-Debug-ID: 1215666735-201c01400000-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 31362DE2D6B for ; Wed, 9 Jul 2008 22:12:15 -0700 (PDT) Received: from bby1mta02.pmc-sierra.bc.ca (bby1mta02.pmc-sierra.com [216.241.235.117]) by cuda.sgi.com with ESMTP id aMC18RDPZdTaaW4x for ; Wed, 09 Jul 2008 22:12:15 -0700 (PDT) Received: from bby1mta02.pmc-sierra.bc.ca (localhost.pmc-sierra.bc.ca [127.0.0.1]) by localhost (Postfix) with SMTP id 6A1918E0065; Wed, 9 Jul 2008 22:15: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 53DC78E0058; Wed, 9 Jul 2008 22:15: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); Wed, 9 Jul 2008 22:12:55 -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: Wed, 9 Jul 2008 22:12:51 -0700 Message-ID: <340C71CD25A7EB49BFA81AE8C839266702A092A2@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> In-Reply-To: <340C71CD25A7EB49BFA81AE8C839266702A08F91@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Xfs Access to block zero exception and system crash Thread-Index: AcjgrWReJLSDlJRQSj6EZpV6D5oEvQBNiDiQABhR0dA= References: <4872E0BC.6070400@pmc-sierra.com> <4872E33E.3090107@sandeen.net> <340C71CD25A7EB49BFA81AE8C839266702A08F91@BBY1EXM10.pmc_nt.nt.pmc-sierra.bc.ca> From: "Sagar Borikar" To: "Eric Sandeen" Cc: X-OriginalArrivalTime: 10 Jul 2008 05:12:55.0924 (UTC) FILETIME=[9CAFA340:01C8E24B] X-Barracuda-Connect: bby1mta02.pmc-sierra.com[216.241.235.117] X-Barracuda-Start-Time: 1215666736 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.55630 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 m6A5BAND001225 X-archive-position: 16822 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, Could be a slight digression but can you let me know why the fragmentation factor is going to 99% immediately? I observed this on both x86 and MIPS platform. Also to alleviate this issue, if I specify allocsize=512m what would be the consequences? Since default allocsize is 64k right? Also while mounting we are setting up default option for mounting file system. Thanks Sagar -----Original Message----- From: xfs-bounce@oss.sgi.com [mailto:xfs-bounce@oss.sgi.com] On Behalf Of Sagar Borikar Sent: Wednesday, July 09, 2008 10:28 PM To: Eric Sandeen Cc: xfs@oss.sgi.com Subject: RE: Xfs Access to block zero exception and system crash Sagar Borikar wrote: > That's right Eric but I am still surprised that why should we get a dead > lock in this scenario as it is a plain copy of file in multiple > directories. Our customer is reporting similar kind of lockup in our > platform. ok, I guess I had missed that, sorry. > I do understand that we are chasing the access to block zero > exception and XFS forced shutdown which I mentioned earlier. But we > also see quite a few smbd processes which are writing data to XFS are in > uninterruptible sleep state and the system locks up too. Ok; then the next step is probably to do sysrq-t and see where things are stuck. It might be better to see if you can reproduce w/o the loopback file, too, since that's just another layer to go through that might be changing things. I ran it on actual device w/o loopback file and even there observed that XFS transactions going into uninterruptible sleep state and the copies were stalled. I had to hard reboot the system to bring XFS out of that state since soft reboot didn't work, it was waiting for file system to get unmounted. I shall provide the sysrq-t update later. > So I thought > the test which I am running could be pointing to similar issue which we > are observing on our platform. But does this indicate that the problem > lies with x86 XFS too ? or maybe the vm ... > Also I presume in enterprise market such kind > of simultaneous write situation may happen. Has anybody reported > similar issues to you? As you observed it over x86 and 2.6.24 kernel, > could you say what would be root cause of this? Haven't really seen it before that I recall, and at this point can't say for sure what it might be. -Eric > Sorry for lots of questions at same time :) But I am happy that you > were able to see the deadlock in x86 on your setup with 2.6.24 > > Thanks > Sagar > > > Eric Sandeen wrote: >> Sagar Borikar wrote: >> >>> Hi Eric, >>> >>> Did you see any issues in your test? >>> >> I got a deadlock but that's it; I don't think that's the bug you want to >> chase... >> >> >> -Eric >> >> >>> Thanks >>> Sagar >>> >>> >>> Sagar Borikar wrote: >>> >>>> Eric Sandeen wrote: >>>> >>>>> Sagar Borikar wrote: >>>>> >>>>> >>>>> >>>>> >>>>>> Could you kindly try with my test? I presume you should see failure >>>>>> soon. I tried this on >>>>>> 2 different x86 systems 2 times ( after rebooting the system ) and I >>>>>> saw it every time. >>>>>> >>>>>> >>>>> Sure. Is there a reason you're doing this on a loopback file? That >>>>> probably stresses the vm a bit more, and might get even trickier if the >>>>> loopback file is sparse... >>>>> >>>>> >>>> Initially I thought to do that since I didn't want to have a strict >>>> allocation limit but >>>> allowing allocations to grow as needed until the backing filesystem >>>> runs out of free space >>>> due to type of the test case I had. But then I dropped the plan and >>>> created a non-sparse >>>> loopback device. There was no specific reason to create loopback but >>>> as it was >>>> simplest option to do it. >>>> >>>>> But anyway, on an x86_64 machine with 2G of memory and a non-sparse 10G >>>>> loopback file on 2.6.24.7-92.fc8, your test runs w/o problems for me, >>>>> though the system does get sluggish. I let it run a bit then ran repair >>>>> and it found no problems, I'll run it overnight to see if anything else >>>>> turns up. >>>>> >>>>> >>>> That will be great. Thanks indeed. >>>> Sagar >>>> >>>> >>>>> -Eric >>>>> >>>>> >> > From owner-xfs@oss.sgi.com Wed Jul 9 23:04:15 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Jul 2008 23:04: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 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 m6A64Dwa004266 for ; Wed, 9 Jul 2008 23:04:15 -0700 X-ASG-Debug-ID: 1215669917-7d0200bd0000-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 0D0F02D330B for ; Wed, 9 Jul 2008 23:05:18 -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 VrG1OBe1vPbU3GPJ for ; Wed, 09 Jul 2008 23:05:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEJDdUh5LFxA/2dsb2JhbACwNw X-IronPort-AV: E=Sophos;i="4.30,336,1212330600"; d="scan'208";a="145783020" Received: from ppp121-44-92-64.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.92.64]) by ipmail01.adl6.internode.on.net with ESMTP; 10 Jul 2008 15:35:07 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KGpH8-0005Qq-5x; Thu, 10 Jul 2008 16:05:06 +1000 Date: Thu, 10 Jul 2008 16:05:06 +1000 From: Dave Chinner To: Donald Douwsma Cc: Eric Sandeen , xfs-oss X-ASG-Orig-Subj: Re: [PATCH] re-remove xfs custom bitops Subject: Re: [PATCH] re-remove xfs custom bitops Message-ID: <20080710060506.GW11558@disturbed> Mail-Followup-To: Donald Douwsma , Eric Sandeen , xfs-oss 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> <48759813.2080601@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48759813.2080601@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: 1215669919 X-Barracuda-Bayes: INNOCENT GLOBAL 0.3077 1.0000 -0.3158 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.32 X-Barracuda-Spam-Status: No, SCORE=-0.32 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.55633 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: 16823 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 10, 2008 at 03:03:15PM +1000, Donald Douwsma wrote: > 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. >> >> Don >> > > Ok I hit the Oops again last weekend without the patch. > Which means I have a patch to checkin and another bug to fix Yea! > > Dave, Eric said this should still be considered signed-off-by you, > You ok with that? Yeah, no problems there. Cheers, Dave. -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Wed Jul 9 23:32:39 2008 Received: with ECARTIS (v1.0.0; list xfs); Wed, 09 Jul 2008 23:32: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=3.3 required=5.0 tests=BAYES_50,HTML_MESSAGE, J_CHICKENPOX_23,J_CHICKENPOX_34,J_CHICKENPOX_53 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 m6A6WdPv006139 for ; Wed, 9 Jul 2008 23:32:39 -0700 X-ASG-Debug-ID: 1215671622-73ed004f0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from hu-out-0506.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 74E80DE4FE4 for ; Wed, 9 Jul 2008 23:33:43 -0700 (PDT) Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.234]) by cuda.sgi.com with ESMTP id iehb35Uh23h21rvu for ; Wed, 09 Jul 2008 23:33:43 -0700 (PDT) Received: by hu-out-0506.google.com with SMTP id 27so11144452hub.17 for ; Wed, 09 Jul 2008 23:33:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type; bh=+e8ws1yUaellAkA2k6+qQEu2fDD+H9IJvpHkGvOkDyI=; b=RnKrkxEcLYVPlHL7hu0RiMRO/EJZiiNzJd8ZUlo6jaMc7suYA5q5tl6o/Jc8zJ3cxT pNoPIG8br3FQcuO66OHFd7RAA3FBKCymIjY5PpGp3KOenPRI4giZquMueRlLBe0DI9gS asZH3lqKBVrz7iOjoOxYDyuCN/T47xhlASdTM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type; b=kNiiiI7mUP5JuiEFFLqzOwt0pRT2y10vozcuD/oX8O7VGfv316XdfPeGsgocI76CQq vUY5LJunaol0OyDW84hD2T8/Q3/Q1X1/WuzNZImd0+dQwaiJQ1cnFKH0/QMyquEVo/0f XgzMjv9zkHvYNg2hxf+ZLubc7M/mL1+xm7ut4= Received: by 10.210.65.2 with SMTP id n2mr5817006eba.48.1215671595254; Wed, 09 Jul 2008 23:33:15 -0700 (PDT) Received: by 10.210.138.9 with HTTP; Wed, 9 Jul 2008 23:33:15 -0700 (PDT) Message-ID: <5667e290807092333h28c9776kf832c17dc46a5a6a@mail.gmail.com> Date: Thu, 10 Jul 2008 08:33:15 +0200 From: "Naomie Wattle" To: bulkmailhaley@gmail.com X-ASG-Orig-Subj: ABC's DVD for kids Subject: ABC's DVD for kids MIME-Version: 1.0 X-Barracuda-Connect: hu-out-0506.google.com[72.14.214.234] X-Barracuda-Start-Time: 1215671624 X-Barracuda-Bayes: INNOCENT GLOBAL 0.7173 1.0000 1.5030 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: 1.50 X-Barracuda-Spam-Status: No, SCORE=1.50 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.55633 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: 1092 X-archive-position: 16824 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: wattle.naomie@gmail.com Precedence: bulk X-list: xfs Promote early learning with our ABC DVD. This digital video disc is applicable to children that are 4-7 years of age. Children have fun while learning the letters of the alphabet. The process is unique and summated upon the South-African grade (R) and grade one1 syllabus. The kids are taught the letters through sight,and phonetic sounds. They are shown how to form the letters by associating with familiar objects. Animals, toys other children combined with music in conjunction with friendly narration ensures the entertainment of the kids. This scientifically researched video is.the first outcome based video of its kind in South Africa and will give your child a head start in the early learning stage. This video is an irresistible adventure that will form the basis for reading and writing skills for the early learner. Get it at: learningletters@gmail.com or unsubscribe: *not. now.thxs. at gmail.com.* Please send us your telephone number and we will phone u with more info or to take your order and arrange for delivery. Kind regards Judy [[HTML alternate version deleted]] From owner-xfs@oss.sgi.com Thu Jul 10 00:25:08 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 10 Jul 2008 00:25: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.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 m6A7P5Cu016229 for ; Thu, 10 Jul 2008 00:25:07 -0700 Received: from linuxbuild.melbourne.sgi.com (linuxbuild.melbourne.sgi.com [134.14.54.115]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id RAA12904; Thu, 10 Jul 2008 17:26:04 +1000 Received: by linuxbuild.melbourne.sgi.com (Postfix, from userid 16365) id 7F28732F6987; Thu, 10 Jul 2008 17:26:04 +1000 (EST) To: xfs@oss.sgi.com, sgi.bugs.xfs@engr.sgi.com Subject: PARTIAL TAKE 981498 - Use the generic bitops rather than implementing them ourselves Message-Id: <20080710072604.7F28732F6987@linuxbuild.melbourne.sgi.com> Date: Thu, 10 Jul 2008 17:26:04 +1000 (EST) From: donaldd@sgi.com (Donald Douwsma) 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: 16825 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 Use the generic bitops rather than implementing them ourselves. This keeps xfs_lowbit64 as it was since there aren't good generic helpers there ... Patch inspired by Andi Kleen. Signed-off-by: Dave Chinner Signed-off-by: Eric Sandeen Date: Thu Jul 10 17:25:02 AEST 2008 Workarea: linuxbuild.melbourne.sgi.com:/home/donaldd/isms/2.6.x-xfs Inspected by: david@fromorbit.com,sandeen@sandeen.net The following file(s) were checked into: longdrop.melbourne.sgi.com:/isms/linux/2.6.x-xfs-melb Modid: xfs-linux-melb:xfs-kern:31472a fs/xfs/xfs_bit.h - 1.25 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bit.h.diff?r1=text&tr1=1.25&r2=text&tr2=1.24&f=h - Use the generic bitops rather than implementing them ourselves. fs/xfs/xfs_bit.c - 1.34 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_bit.c.diff?r1=text&tr1=1.34&r2=text&tr2=1.33&f=h - Use the generic bitops rather than implementing them ourselves. fs/xfs/xfs_rtalloc.c - 1.113 - changed http://oss.sgi.com/cgi-bin/cvsweb.cgi/xfs-linux/xfs_rtalloc.c.diff?r1=text&tr1=1.113&r2=text&tr2=1.112&f=h - Use the generic bitops rather than implementing them ourselves. From owner-xfs@oss.sgi.com Thu Jul 10 00:38:11 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 10 Jul 2008 00:38: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.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from relay.sgi.com (relay2.corp.sgi.com [192.26.58.22]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m6A7cBpQ017167 for ; Thu, 10 Jul 2008 00:38:11 -0700 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by relay2.corp.sgi.com (Postfix) with ESMTP id 1C95C30408A; Thu, 10 Jul 2008 00:39:12 -0700 (PDT) Received: from itchy.melbourne.sgi.com (postfix@itchy.melbourne.sgi.com [134.14.55.96]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m6A7d8jm2598471; Thu, 10 Jul 2008 17:39:09 +1000 (AEST) Received: by itchy.melbourne.sgi.com (Postfix, from userid 16403) id 8F29958878; Thu, 10 Jul 2008 17:39:05 +1000 (EST) From: Niv Sardi To: xfs@oss.sgi.com Cc: Niv Sardi Subject: [PATCH] Introduce xfs_bmap_add_attrfork_trans. Date: Thu, 10 Jul 2008 17:39:04 +1000 Message-Id: <1215675545-2707-4-git-send-email-xaiki@sgi.com> X-Mailer: git-send-email 1.5.6.2 In-Reply-To: <1215675545-2707-3-git-send-email-xaiki@sgi.com> References: <1214196150-5427-1-git-send-email-xaiki@sgi.com> <1215675545-2707-1-git-send-email-xaiki@sgi.com> <1215675545-2707-2-git-send-email-xaiki@sgi.com> <1215675545-2707-3-git-send-email-xaiki@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: 16826 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 That takes a transaction and doesn't require everything to be locked anymore. This doesn't commit the transaction ! so direct callers, willing to use xfs_trans_roll() should do it themselves. Change xfs_bmap_add_attrfork to do the initialization/allocation of the transaction and commit arround xfs_bmap_add_attrfork_trans. Signed-off-by: Niv Sardi --- fs/xfs/xfs_bmap.c | 107 ++++++++++++++++++++++++++++++++++------------------ fs/xfs/xfs_bmap.h | 11 +++++ 2 files changed, 81 insertions(+), 37 deletions(-) diff --git a/fs/xfs/xfs_bmap.c b/fs/xfs/xfs_bmap.c index 53c259f..231c8bc 100644 --- a/fs/xfs/xfs_bmap.c +++ b/fs/xfs/xfs_bmap.c @@ -3941,20 +3941,20 @@ xfs_bunmap_trace( #endif /* - * Convert inode from non-attributed to attributed. - * Must not be in a transaction, ip must not be locked. + * Convert inode from non-attributed to attributed (transaction + * version: Use the transaction given via tpp) */ int /* error code */ -xfs_bmap_add_attrfork( - xfs_inode_t *ip, /* incore inode pointer */ +xfs_bmap_add_attrfork_trans( + struct xfs_trans **tpp, /* transaction pointer */ + struct xfs_inode *ip, /* incore inode pointer */ int size, /* space new attribute needs */ int rsvd) /* xact may use reserved blks */ { xfs_fsblock_t firstblock; /* 1st block/ag allocated */ - xfs_bmap_free_t flist; /* freed extent records */ - xfs_mount_t *mp; /* mount structure */ - xfs_trans_t *tp; /* transaction pointer */ - int blks; /* space reservation */ + struct xfs_bmap_free flist; /* freed extent records */ + struct xfs_mount *mp; /* mount structure */ + struct xfs_trans *tp; /* transaction pointer */ int version = 1; /* superblock attr version */ int committed; /* xaction was committed */ int logflags; /* logging flags */ @@ -3966,24 +3966,8 @@ xfs_bmap_add_attrfork( mp = ip->i_mount; ASSERT(!XFS_NOT_DQATTACHED(mp, ip)); - tp = xfs_trans_alloc(mp, XFS_TRANS_ADDAFORK); - blks = XFS_ADDAFORK_SPACE_RES(mp); - if (rsvd) - tp->t_flags |= XFS_TRANS_RESERVE; - if ((error = xfs_trans_reserve(tp, blks, XFS_ADDAFORK_LOG_RES(mp), 0, - XFS_TRANS_PERM_LOG_RES, XFS_ADDAFORK_LOG_COUNT))) - goto error0; - xfs_ilock(ip, XFS_ILOCK_EXCL); - error = XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, tp, ip, blks, 0, rsvd ? - XFS_QMOPT_RES_REGBLKS | XFS_QMOPT_FORCE_RES : - XFS_QMOPT_RES_REGBLKS); - if (error) { - xfs_iunlock(ip, XFS_ILOCK_EXCL); - xfs_trans_cancel(tp, XFS_TRANS_RELEASE_LOG_RES); - return error; - } - if (XFS_IFORK_Q(ip)) - goto error1; + ASSERT(*tpp); + tp = *tpp; if (ip->i_d.di_aformat != XFS_DINODE_FMT_EXTENTS) { /* * For inodes coming from pre-6.2 filesystems. @@ -3991,10 +3975,7 @@ xfs_bmap_add_attrfork( ASSERT(ip->i_d.di_aformat == 0); ip->i_d.di_aformat = XFS_DINODE_FMT_EXTENTS; } - 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); + switch (ip->i_d.di_format) { case XFS_DINODE_FMT_DEV: ip->i_d.di_forkoff = roundup(sizeof(xfs_dev_t), 8) >> 3; @@ -4014,7 +3995,7 @@ xfs_bmap_add_attrfork( default: ASSERT(0); error = XFS_ERROR(EINVAL); - goto error1; + goto error0; } ip->i_df.if_ext_max = XFS_IFORK_DSIZE(ip) / (uint)sizeof(xfs_bmbt_rec_t); @@ -4045,7 +4026,7 @@ xfs_bmap_add_attrfork( if (logflags) xfs_trans_log_inode(tp, ip, logflags); if (error) - goto error2; + goto error1; if (!xfs_sb_version_hasattr(&mp->m_sb) || (!xfs_sb_version_hasattr2(&mp->m_sb) && version == 2)) { __int64_t sbfields = 0; @@ -4065,14 +4046,66 @@ xfs_bmap_add_attrfork( } else spin_unlock(&mp->m_sb_lock); } - if ((error = xfs_bmap_finish(&tp, &flist, &committed))) - goto error2; - error = xfs_trans_commit(tp, XFS_TRANS_PERM_LOG_RES); + error = xfs_bmap_finish(tpp, &flist, &committed); + if (error) + goto error1; ASSERT(ip->i_df.if_ext_max == XFS_IFORK_DSIZE(ip) / (uint)sizeof(xfs_bmbt_rec_t)); - return error; -error2: + return 0; +error1: xfs_bmap_cancel(&flist); +error0: + xfs_trans_cancel(tp, XFS_TRANS_RELEASE_LOG_RES|XFS_TRANS_ABORT); + ASSERT(ip->i_df.if_ext_max == + XFS_IFORK_DSIZE(ip) / (uint)sizeof(xfs_bmbt_rec_t)); + return error; +} + +/* + * Convert inode from non-attributed to attributed. + * Must not be in a transaction, ip must not be locked. + */ +int +xfs_bmap_add_attrfork( + struct xfs_inode *ip, /* incore inode pointer */ + int size, /* space new attribute needs */ + int rsvd) /* xact may use reserved blks */ +{ + struct xfs_trans *tp; /* transaction pointer */ + struct xfs_mount *mp; /* mount structure */ + int blks; /* space reservation */ + int error; /* error return value */ + + mp = ip->i_mount; + tp = xfs_trans_alloc(mp, XFS_TRANS_ADDAFORK); + blks = XFS_ADDAFORK_SPACE_RES(mp); + + if (rsvd) + tp->t_flags |= XFS_TRANS_RESERVE; + error = xfs_trans_reserve(tp, blks, XFS_ADDAFORK_LOG_RES(mp), 0, + XFS_TRANS_PERM_LOG_RES, XFS_ADDAFORK_LOG_COUNT); + if (error) + goto error0; + + xfs_ilock(ip, XFS_ILOCK_EXCL); + error = XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, tp, ip, blks, 0, rsvd ? + XFS_QMOPT_RES_REGBLKS | XFS_QMOPT_FORCE_RES : + XFS_QMOPT_RES_REGBLKS); + 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_bmap_add_attrfork_trans(&tp, ip, size, rsvd); + if (error) + return error; + return xfs_trans_commit(tp, XFS_TRANS_PERM_LOG_RES); error1: xfs_iunlock(ip, XFS_ILOCK_EXCL); error0: diff --git a/fs/xfs/xfs_bmap.h b/fs/xfs/xfs_bmap.h index 6ff70cd..7a6b3f3 100644 --- a/fs/xfs/xfs_bmap.h +++ b/fs/xfs/xfs_bmap.h @@ -157,6 +157,17 @@ xfs_bmap_trace_exlist( #endif /* + * Convert inode from non-attributed to attributed (transaction + * version: Use the transaction given via tpp) + */ +int /* error code */ +xfs_bmap_add_attrfork_trans( + struct xfs_trans **tpp, /* transaction */ + struct xfs_inode *ip, /* incore inode pointer */ + int size, /* space needed for new attribute */ + int rsvd); /* flag for reserved block allocation */ + +/* * Convert inode from non-attributed to attributed. * Must not be in a transaction, ip must not be locked. */ -- 1.5.6.2 From owner-xfs@oss.sgi.com Thu Jul 10 00:38:12 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 10 Jul 2008 00:38: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.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 m6A7cCZS017177 for ; Thu, 10 Jul 2008 00:38:12 -0700 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by relay1.corp.sgi.com (Postfix) with ESMTP id 1BC5B8F806F; Thu, 10 Jul 2008 00:39:12 -0700 (PDT) Received: from itchy.melbourne.sgi.com (postfix@itchy.melbourne.sgi.com [134.14.55.96]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m6A7d8jm2593893; Thu, 10 Jul 2008 17:39:09 +1000 (AEST) Received: by itchy.melbourne.sgi.com (Postfix, from userid 16403) id 846D258875; Thu, 10 Jul 2008 17:39:05 +1000 (EST) From: Niv Sardi To: xfs@oss.sgi.com Cc: Niv Sardi Subject: [PATCH] Move xfs_attr_rolltrans to xfs_trans_roll Date: Thu, 10 Jul 2008 17:39:03 +1000 Message-Id: <1215675545-2707-3-git-send-email-xaiki@sgi.com> X-Mailer: git-send-email 1.5.6.2 In-Reply-To: <1215675545-2707-2-git-send-email-xaiki@sgi.com> References: <1214196150-5427-1-git-send-email-xaiki@sgi.com> <1215675545-2707-1-git-send-email-xaiki@sgi.com> <1215675545-2707-2-git-send-email-xaiki@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: 16827 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 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. We use this excuse to change all the: if ((error = xfs_attr_rolltrans())) calls into: error = xfs_trans_roll(); if (error) Signed-off-by: Niv Sardi --- fs/xfs/xfs_attr.c | 30 +++++++++++++------ fs/xfs/xfs_attr_leaf.c | 73 +++++------------------------------------------ fs/xfs/xfs_attr_leaf.h | 2 - fs/xfs/xfs_trans.c | 63 +++++++++++++++++++++++++++++++++++++++++ fs/xfs/xfs_trans.h | 1 + 5 files changed, 92 insertions(+), 77 deletions(-) diff --git a/fs/xfs/xfs_attr.c b/fs/xfs/xfs_attr.c index 4036bdc..4888a35 100644 --- a/fs/xfs/xfs_attr.c +++ b/fs/xfs/xfs_attr.c @@ -403,7 +403,9 @@ xfs_attr_set_int(xfs_inode_t *dp, struct xfs_name *name, * Commit the leaf transformation. We'll need another (linked) * transaction to add the new attribute to the leaf. */ - if ((error = xfs_attr_rolltrans(&args.trans, dp))) + + error = xfs_trans_roll(&args.trans, dp); + if (error) goto out; } @@ -1035,7 +1037,8 @@ xfs_attr_leaf_addname(xfs_da_args_t *args) * Commit the current trans (including the inode) and start * a new one. */ - if ((error = xfs_attr_rolltrans(&args->trans, dp))) + error = xfs_trans_roll(&args->trans, dp); + if (error) return (error); /* @@ -1049,7 +1052,8 @@ xfs_attr_leaf_addname(xfs_da_args_t *args) * Commit the transaction that added the attr name so that * later routines can manage their own transactions. */ - if ((error = xfs_attr_rolltrans(&args->trans, dp))) + error = xfs_trans_roll(&args->trans, dp); + if (error) return (error); /* @@ -1138,7 +1142,7 @@ xfs_attr_leaf_addname(xfs_da_args_t *args) /* * Commit the remove and start the next trans in series. */ - error = xfs_attr_rolltrans(&args->trans, dp); + error = xfs_trans_roll(&args->trans, dp); } else if (args->rmtblkno > 0) { /* @@ -1369,7 +1373,8 @@ restart: * Commit the node conversion and start the next * trans in the chain. */ - if ((error = xfs_attr_rolltrans(&args->trans, dp))) + error = xfs_trans_roll(&args->trans, dp); + if (error) goto out; goto restart; @@ -1420,7 +1425,8 @@ restart: * Commit the leaf addition or btree split and start the next * trans in the chain. */ - if ((error = xfs_attr_rolltrans(&args->trans, dp))) + error = xfs_trans_roll(&args->trans, dp); + if (error) goto out; /* @@ -1520,7 +1526,8 @@ restart: /* * Commit and start the next trans in the chain. */ - if ((error = xfs_attr_rolltrans(&args->trans, dp))) + error = xfs_trans_roll(&args->trans, dp); + if (error) goto out; } else if (args->rmtblkno > 0) { @@ -1652,7 +1659,8 @@ xfs_attr_node_removename(xfs_da_args_t *args) /* * Commit the Btree join operation and start a new trans. */ - if ((error = xfs_attr_rolltrans(&args->trans, dp))) + error = xfs_trans_roll(&args->trans, dp); + if (error) goto out; } @@ -2153,7 +2161,8 @@ xfs_attr_rmtval_set(xfs_da_args_t *args) /* * Start the next trans in the chain. */ - if ((error = xfs_attr_rolltrans(&args->trans, dp))) + error = xfs_trans_roll(&args->trans, dp); + if (error) return (error); } @@ -2303,7 +2312,8 @@ xfs_attr_rmtval_remove(xfs_da_args_t *args) /* * Close out trans and start the next one in the chain. */ - if ((error = xfs_attr_rolltrans(&args->trans, args->dp))) + error = xfs_trans_roll(&args->trans, args->dp); + if (error) return (error); } return(0); diff --git a/fs/xfs/xfs_attr_leaf.c b/fs/xfs/xfs_attr_leaf.c index 303d41e..36aa10c 100644 --- a/fs/xfs/xfs_attr_leaf.c +++ b/fs/xfs/xfs_attr_leaf.c @@ -2543,9 +2543,7 @@ xfs_attr_leaf_clearflag(xfs_da_args_t *args) /* * Commit the flag value change and start the next trans in series. */ - error = xfs_attr_rolltrans(&args->trans, args->dp); - - return(error); + return xfs_trans_roll(&args->trans, args->dp); } /* @@ -2592,7 +2590,7 @@ xfs_attr_leaf_setflag(xfs_da_args_t *args) /* * Commit the flag value change and start the next trans in series. */ - error = xfs_attr_rolltrans(&args->trans, args->dp); + error = xfs_trans_roll(&args->trans, args->dp); return(error); } @@ -2710,7 +2708,7 @@ xfs_attr_leaf_flipflags(xfs_da_args_t *args) /* * Commit the flag value change and start the next trans in series. */ - error = xfs_attr_rolltrans(&args->trans, args->dp); + error = xfs_trans_roll(&args->trans, args->dp); return(error); } @@ -2768,7 +2766,7 @@ xfs_attr_root_inactive(xfs_trans_t **trans, xfs_inode_t *dp) /* * Commit the invalidate and start the next transaction. */ - error = xfs_attr_rolltrans(trans, dp); + error = xfs_trans_roll(trans, dp); return (error); } @@ -2870,7 +2868,8 @@ xfs_attr_node_inactive(xfs_trans_t **trans, xfs_inode_t *dp, xfs_dabuf_t *bp, /* * Atomically commit the whole invalidate stuff. */ - if ((error = xfs_attr_rolltrans(trans, dp))) + error = xfs_trans_roll(trans, dp); + if (error) return (error); } @@ -3009,7 +3008,8 @@ xfs_attr_leaf_freextent(xfs_trans_t **trans, xfs_inode_t *dp, /* * Roll to next transaction. */ - if ((error = xfs_attr_rolltrans(trans, dp))) + error = xfs_trans_roll(trans, dp); + if (error) return (error); } @@ -3019,60 +3019,3 @@ xfs_attr_leaf_freextent(xfs_trans_t **trans, xfs_inode_t *dp, return(0); } - - -/* - * Roll from one trans in the sequence of PERMANENT transactions to the next. - */ -int -xfs_attr_rolltrans(xfs_trans_t **transp, xfs_inode_t *dp) -{ - xfs_trans_t *trans; - unsigned int logres, count; - int error; - - /* - * Ensure that the inode is always logged. - */ - trans = *transp; - xfs_trans_log_inode(trans, dp, XFS_ILOG_CORE); - - /* - * Copy the critical parameters from one trans to the next. - */ - logres = trans->t_log_res; - count = trans->t_log_count; - *transp = xfs_trans_dup(trans); - - /* - * Commit the current transaction. - * If this commit failed, then it'd just unlock those items that - * are not marked ihold. That also means that a filesystem shutdown - * is in progress. The caller takes the responsibility to cancel - * the duplicate transaction that gets returned. - */ - if ((error = xfs_trans_commit(trans, 0))) - return (error); - - trans = *transp; - - /* - * Reserve space in the log for th next transaction. - * This also pushes items in the "AIL", the list of logged items, - * out to disk if they are taking up space at the tail of the log - * that we want to use. This requires that either nothing be locked - * across this call, or that anything that is locked be logged in - * the prior and the next transactions. - */ - error = xfs_trans_reserve(trans, 0, logres, 0, - XFS_TRANS_PERM_LOG_RES, count); - /* - * Ensure that the inode is in the new transaction and locked. - */ - if (!error) { - xfs_trans_ijoin(trans, dp, XFS_ILOCK_EXCL); - xfs_trans_ihold(trans, dp); - } - return (error); - -} diff --git a/fs/xfs/xfs_attr_leaf.h b/fs/xfs/xfs_attr_leaf.h index 040f732..698e078 100644 --- a/fs/xfs/xfs_attr_leaf.h +++ b/fs/xfs/xfs_attr_leaf.h @@ -301,6 +301,4 @@ int xfs_attr_leaf_order(struct xfs_dabuf *leaf1_bp, struct xfs_dabuf *leaf2_bp); int xfs_attr_leaf_newentsize(int namelen, int valuelen, int blocksize, int *local); -int xfs_attr_rolltrans(struct xfs_trans **transp, struct xfs_inode *dp); - #endif /* __XFS_ATTR_LEAF_H__ */ diff --git a/fs/xfs/xfs_trans.c b/fs/xfs/xfs_trans.c index 1403864..8403eac 100644 --- a/fs/xfs/xfs_trans.c +++ b/fs/xfs/xfs_trans.c @@ -43,6 +43,7 @@ #include "xfs_quota.h" #include "xfs_trans_priv.h" #include "xfs_trans_space.h" +#include "xfs_inode_item.h" STATIC void xfs_trans_apply_sb_deltas(xfs_trans_t *); @@ -1216,6 +1217,68 @@ xfs_trans_free( kmem_zone_free(xfs_trans_zone, tp); } +/* + * Roll from one trans in the sequence of PERMANENT transactions to + * the next: permanent transactions are only flushed out when + * committed 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 + * chunk we've been working on and get a new transaction to continue. + */ +int +xfs_trans_roll( + struct xfs_trans **tpp, + struct xfs_inode *dp) +{ + struct xfs_trans *trans; + unsigned int logres, count; + int error; + + /* + * Ensure that the inode is always logged. + */ + trans = *tpp; + xfs_trans_log_inode(trans, dp, XFS_ILOG_CORE); + + /* + * Copy the critical parameters from one trans to the next. + */ + logres = trans->t_log_res; + count = trans->t_log_count; + *tpp = xfs_trans_dup(trans); + + /* + * Commit the current transaction. + * If this commit failed, then it'd just unlock those items that + * are not marked ihold. That also means that a filesystem shutdown + * is in progress. The caller takes the responsibility to cancel + * the duplicate transaction that gets returned. + */ + error = xfs_trans_commit(trans, 0); + if (error) + return (error); + + trans = *tpp; + + /* + * Reserve space in the log for th next transaction. + * This also pushes items in the "AIL", the list of logged items, + * out to disk if they are taking up space at the tail of the log + * that we want to use. This requires that either nothing be locked + * across this call, or that anything that is locked be logged in + * the prior and the next transactions. + */ + error = xfs_trans_reserve(trans, 0, logres, 0, + XFS_TRANS_PERM_LOG_RES, count); + /* + * Ensure that the inode is in the new transaction and locked. + */ + if (error) + return error; + + xfs_trans_ijoin(trans, dp, XFS_ILOCK_EXCL); + xfs_trans_ihold(trans, dp); + return 0; +} /* * THIS SHOULD BE REWRITTEN TO USE xfs_trans_next_item(). diff --git a/fs/xfs/xfs_trans.h b/fs/xfs/xfs_trans.h index 0804207..9161e99 100644 --- a/fs/xfs/xfs_trans.h +++ b/fs/xfs/xfs_trans.h @@ -986,6 +986,7 @@ int _xfs_trans_commit(xfs_trans_t *, int *); #define xfs_trans_commit(tp, flags) _xfs_trans_commit(tp, flags, NULL) void xfs_trans_cancel(xfs_trans_t *, int); +int xfs_trans_roll(struct xfs_trans **, struct xfs_inode *); int xfs_trans_ail_init(struct xfs_mount *); void xfs_trans_ail_destroy(struct xfs_mount *); void xfs_trans_push_ail(struct xfs_mount *, xfs_lsn_t); -- 1.5.6.2 From owner-xfs@oss.sgi.com Thu Jul 10 00:38:21 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 10 Jul 2008 00:38: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.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45, J_CHICKENPOX_47 autolearn=no version=3.3.0-r574664 Received: from relay.sgi.com (netops-testserver-3.corp.sgi.com [192.26.57.72]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m6A7cKxq017250 for ; Thu, 10 Jul 2008 00:38:21 -0700 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by netops-testserver-3.corp.sgi.com (Postfix) with ESMTP id 3048F908C8; Thu, 10 Jul 2008 00:39:12 -0700 (PDT) Received: from itchy.melbourne.sgi.com (postfix@itchy.melbourne.sgi.com [134.14.55.96]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m6A7d8jm2597030; Thu, 10 Jul 2008 17:39:09 +1000 (AEST) Received: by itchy.melbourne.sgi.com (Postfix, from userid 16403) id 7B5F758877; Thu, 10 Jul 2008 17:39:05 +1000 (EST) From: Niv Sardi To: xfs@oss.sgi.com Cc: Niv Sardi Subject: [PATCH] Move attr log alloc size calculator to another function. Date: Thu, 10 Jul 2008 17:39:02 +1000 Message-Id: <1215675545-2707-2-git-send-email-xaiki@sgi.com> X-Mailer: git-send-email 1.5.6.2 In-Reply-To: <1215675545-2707-1-git-send-email-xaiki@sgi.com> References: <1214196150-5427-1-git-send-email-xaiki@sgi.com> <1215675545-2707-1-git-send-email-xaiki@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: 16828 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 We will need that to be able to calculate the size of log we need for a specific attr (for Create+EA). The local flag is needed so that we can fail if we run into ENOSPC when trying to alloc blocks. Signed-off-by: Niv Sardi --- fs/xfs/xfs_attr.c | 80 +++++++++++++++++++++++++++++++--------------------- fs/xfs/xfs_attr.h | 1 + 2 files changed, 49 insertions(+), 32 deletions(-) diff --git a/fs/xfs/xfs_attr.c b/fs/xfs/xfs_attr.c index df151a8..4036bdc 100644 --- a/fs/xfs/xfs_attr.c +++ b/fs/xfs/xfs_attr.c @@ -196,6 +196,46 @@ xfs_attr_get( return(error); } +/* + * Calculate how many blocks we need for the new attribute, + */ +int +xfs_attr_calc_size( + struct xfs_inode *ip, + int namelen, + int valuelen, + int *local) +{ + struct xfs_mount *mp = ip->i_mount; + int size; + int nblks; + + /* + * Determine space new attribute will use, and if it would be + * "local" or "remote" (note: local != inline). + */ + size = xfs_attr_leaf_newentsize(namelen, valuelen, + mp->m_sb.sb_blocksize, local); + + nblks = XFS_DAENTER_SPACE_RES(mp, XFS_ATTR_FORK); + if (*local) { + if (size > (mp->m_sb.sb_blocksize >> 1)) { + /* Double split possible */ + nblks *= 2; + } + } else { + /* + * Out of line attribute, cannot double split, but + * make room for the attribute value itself. + */ + uint dblocks = XFS_B_TO_FSB(mp, valuelen); + nblks += dblocks; + nblks += XFS_NEXTENTADD_SPACE_RES(mp, dblocks, XFS_ATTR_FORK); + } + + return nblks; +} + STATIC int xfs_attr_set_int(xfs_inode_t *dp, struct xfs_name *name, char *value, int valuelen, int flags) @@ -204,10 +244,9 @@ xfs_attr_set_int(xfs_inode_t *dp, struct xfs_name *name, xfs_fsblock_t firstblock; xfs_bmap_free_t flist; int error, err2, committed; - int local, size; - uint nblks; xfs_mount_t *mp = dp->i_mount; int rsvd = (flags & ATTR_ROOT) != 0; + int local; /* * Attach the dquots to the inode. @@ -244,30 +283,8 @@ xfs_attr_set_int(xfs_inode_t *dp, struct xfs_name *name, args.addname = 1; args.oknoent = 1; - /* - * Determine space new attribute will use, and if it would be - * "local" or "remote" (note: local != inline). - */ - size = xfs_attr_leaf_newentsize(name->len, valuelen, - mp->m_sb.sb_blocksize, &local); - - nblks = XFS_DAENTER_SPACE_RES(mp, XFS_ATTR_FORK); - if (local) { - if (size > (mp->m_sb.sb_blocksize >> 1)) { - /* Double split possible */ - nblks <<= 1; - } - } else { - uint dblocks = XFS_B_TO_FSB(mp, valuelen); - /* Out of line attribute, cannot double split, but make - * room for the attribute value itself. - */ - nblks += dblocks; - nblks += XFS_NEXTENTADD_SPACE_RES(mp, dblocks, XFS_ATTR_FORK); - } - /* Size is now blocks for attribute data */ - args.total = nblks; + args.total = xfs_attr_calc_size(dp, name->len, valuelen, &local); /* * Start our first transaction of the day. @@ -289,18 +306,17 @@ xfs_attr_set_int(xfs_inode_t *dp, struct xfs_name *name, if (rsvd) args.trans->t_flags |= XFS_TRANS_RESERVE; - if ((error = xfs_trans_reserve(args.trans, (uint) nblks, - XFS_ATTRSET_LOG_RES(mp, nblks), - 0, XFS_TRANS_PERM_LOG_RES, - XFS_ATTRSET_LOG_COUNT))) { + if ((error = xfs_trans_reserve(args.trans, args.total, + XFS_ATTRSET_LOG_RES(mp, args.total), 0, + XFS_TRANS_PERM_LOG_RES, XFS_ATTRSET_LOG_COUNT))) { xfs_trans_cancel(args.trans, 0); return(error); } xfs_ilock(dp, XFS_ILOCK_EXCL); - error = XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, args.trans, dp, nblks, 0, - rsvd ? XFS_QMOPT_RES_REGBLKS | XFS_QMOPT_FORCE_RES : - XFS_QMOPT_RES_REGBLKS); + error = XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, args.trans, dp, args.total, 0, + rsvd ? XFS_QMOPT_RES_REGBLKS | XFS_QMOPT_FORCE_RES : + XFS_QMOPT_RES_REGBLKS); if (error) { xfs_iunlock(dp, XFS_ILOCK_EXCL); xfs_trans_cancel(args.trans, XFS_TRANS_RELEASE_LOG_RES); diff --git a/fs/xfs/xfs_attr.h b/fs/xfs/xfs_attr.h index 6cfc938..f99395c 100644 --- a/fs/xfs/xfs_attr.h +++ b/fs/xfs/xfs_attr.h @@ -158,6 +158,7 @@ struct xfs_da_args; /* * Overall external interface routines. */ +int xfs_attr_calc_size(struct xfs_inode *, int, int, int *); int xfs_attr_inactive(struct xfs_inode *dp); int xfs_attr_shortform_getvalue(struct xfs_da_args *); -- 1.5.6.2 From owner-xfs@oss.sgi.com Thu Jul 10 00:38:39 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 10 Jul 2008 00:38: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.3 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_45, J_CHICKENPOX_65 autolearn=no version=3.3.0-r574664 Received: from relay.sgi.com (netops-testserver-3.corp.sgi.com [192.26.57.72]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m6A7cdkg017594 for ; Thu, 10 Jul 2008 00:38:39 -0700 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by netops-testserver-3.corp.sgi.com (Postfix) with ESMTP id 1D141908C4; Thu, 10 Jul 2008 00:39:12 -0700 (PDT) Received: from itchy.melbourne.sgi.com (postfix@itchy.melbourne.sgi.com [134.14.55.96]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m6A7d8jm2550759; Thu, 10 Jul 2008 17:39:09 +1000 (AEST) Received: by itchy.melbourne.sgi.com (Postfix, from userid 16403) id 9CB1758879; Thu, 10 Jul 2008 17:39:05 +1000 (EST) From: Niv Sardi To: xfs@oss.sgi.com Cc: Niv Sardi Subject: [PATCH] Give a transaction to xfs_attr_set_int Date: Thu, 10 Jul 2008 17:39:05 +1000 Message-Id: <1215675545-2707-5-git-send-email-xaiki@sgi.com> X-Mailer: git-send-email 1.5.6.2 In-Reply-To: <1215675545-2707-4-git-send-email-xaiki@sgi.com> References: <1214196150-5427-1-git-send-email-xaiki@sgi.com> <1215675545-2707-1-git-send-email-xaiki@sgi.com> <1215675545-2707-2-git-send-email-xaiki@sgi.com> <1215675545-2707-3-git-send-email-xaiki@sgi.com> <1215675545-2707-4-git-send-email-xaiki@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: 16829 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 We introduce xfs_attr_set_int_trans that takes a transaction pointer as an argument (or creates one if NULL) and only finishes the transaction if it has created it. We use xfs_trans_roll to do the trans_dup dance. xfs_attr_set_int is changed to a wrapper that will only call xfs_attr_set_int_trans with a NULL transaction. make it use the new xfs_bmap_add_attrfork_trans(), and roll the transaction after the call. This is needed for Create+EA/Parent Pointers Signed-off-by: Niv Sardi --- fs/xfs/xfs_attr.c | 139 ++++++++++++++++++++++++++++++++++++----------------- 1 files changed, 94 insertions(+), 45 deletions(-) diff --git a/fs/xfs/xfs_attr.c b/fs/xfs/xfs_attr.c index 4888a35..8e9598d 100644 --- a/fs/xfs/xfs_attr.c +++ b/fs/xfs/xfs_attr.c @@ -236,9 +236,19 @@ xfs_attr_calc_size( return nblks; } +/* + * So if the trans is given we don't have the right to dispose of it, + * we can't commit it either as we don't know if the caller is + * done with it. + */ STATIC int -xfs_attr_set_int(xfs_inode_t *dp, struct xfs_name *name, - char *value, int valuelen, int flags) +xfs_attr_set_int_trans( + xfs_trans_t **tpp, + xfs_inode_t *dp, + struct xfs_name *name, + char *value, + int valuelen, + int flags) { xfs_da_args_t args; xfs_fsblock_t firstblock; @@ -260,10 +270,14 @@ xfs_attr_set_int(xfs_inode_t *dp, struct xfs_name *name, */ if (XFS_IFORK_Q(dp) == 0) { int sf_size = sizeof(xfs_attr_sf_hdr_t) + - XFS_ATTR_SF_ENTSIZE_BYNAME(name->len, valuelen); + XFS_ATTR_SF_ENTSIZE_BYNAME(name->len, valuelen); - if ((error = xfs_bmap_add_attrfork(dp, sf_size, rsvd))) - return(error); + error = xfs_bmap_add_attrfork_trans(tpp, dp, sf_size, rsvd); + if (error) + return error; + error = xfs_trans_roll(tpp, dp); + if (error) + return error; } /* @@ -286,45 +300,52 @@ xfs_attr_set_int(xfs_inode_t *dp, struct xfs_name *name, /* Size is now blocks for attribute data */ args.total = xfs_attr_calc_size(dp, name->len, valuelen, &local); - /* - * Start our first transaction of the day. - * - * All future transactions during this code must be "chained" off - * this one via the trans_dup() call. All transactions will contain - * the inode, and the inode will always be marked with trans_ihold(). - * Since the inode will be locked in all transactions, we must log - * the inode in every transaction to let it float upward through - * the log. - */ - args.trans = xfs_trans_alloc(mp, XFS_TRANS_ATTR_SET); + if (tpp) { + ASSERT(*tpp); + args.trans = *tpp; + } else { + /* + * Start our first transaction of the day. + * + * All future transactions during this code must be "chained" off + * this one via the trans_dup() call. All transactions will contain + * the inode, and the inode will always be marked with trans_ihold(). + * Since the inode will be locked in all transactions, we must log + * the inode in every transaction to let it float upward through + * the log. + */ + args.trans = xfs_trans_alloc(mp, XFS_TRANS_ATTR_SET); - /* - * Root fork attributes can use reserved data blocks for this - * operation if necessary - */ + /* + * Root fork attributes can use reserved data blocks for this + * operation if necessary + */ - if (rsvd) - args.trans->t_flags |= XFS_TRANS_RESERVE; + if (rsvd) + args.trans->t_flags |= XFS_TRANS_RESERVE; - if ((error = xfs_trans_reserve(args.trans, args.total, - XFS_ATTRSET_LOG_RES(mp, args.total), 0, - XFS_TRANS_PERM_LOG_RES, XFS_ATTRSET_LOG_COUNT))) { - xfs_trans_cancel(args.trans, 0); - return(error); - } - xfs_ilock(dp, XFS_ILOCK_EXCL); + error = xfs_trans_reserve(args.trans, args.total, + XFS_ATTRSET_LOG_RES(mp, args.total), 0, + XFS_TRANS_PERM_LOG_RES, XFS_ATTRSET_LOG_COUNT); + if (error) { + xfs_trans_cancel(args.trans, 0); + return(error); + } + xfs_ilock(dp, XFS_ILOCK_EXCL); - error = XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, args.trans, dp, args.total, 0, - rsvd ? XFS_QMOPT_RES_REGBLKS | XFS_QMOPT_FORCE_RES : + error = XFS_TRANS_RESERVE_QUOTA_NBLKS(mp, args.trans, dp, + args.total, 0, + rsvd?XFS_QMOPT_RES_REGBLKS|XFS_QMOPT_FORCE_RES: XFS_QMOPT_RES_REGBLKS); - if (error) { - xfs_iunlock(dp, XFS_ILOCK_EXCL); - xfs_trans_cancel(args.trans, XFS_TRANS_RELEASE_LOG_RES); - return (error); - } + if (error) { + xfs_iunlock(dp, XFS_ILOCK_EXCL); + xfs_trans_cancel(args.trans, XFS_TRANS_RELEASE_LOG_RES); + return (error); + } - xfs_trans_ijoin(args.trans, dp, XFS_ILOCK_EXCL); - xfs_trans_ihold(args.trans, dp); + xfs_trans_ijoin(args.trans, dp, XFS_ILOCK_EXCL); + xfs_trans_ihold(args.trans, dp); + } /* * If the attribute list is non-existent or a shortform list, @@ -360,8 +381,14 @@ xfs_attr_set_int(xfs_inode_t *dp, struct xfs_name *name, if (mp->m_flags & XFS_MOUNT_WSYNC) { xfs_trans_set_sync(args.trans); } - err2 = xfs_trans_commit(args.trans, - XFS_TRANS_RELEASE_LOG_RES); + + /* Only finish trans if it's ours */ + if (tpp) { + err2 = xfs_trans_roll(&args.trans, dp); + } else { + err2 = xfs_trans_commit(args.trans, + XFS_TRANS_RELEASE_LOG_RES); + } xfs_iunlock(dp, XFS_ILOCK_EXCL); /* @@ -370,6 +397,8 @@ xfs_attr_set_int(xfs_inode_t *dp, struct xfs_name *name, if (!error && (flags & ATTR_KERNOTIME) == 0) { xfs_ichgtime(dp, XFS_ICHGTIME_CHG); } + if (tpp) + *tpp = args.trans; return(error == 0 ? err2 : error); } @@ -415,13 +444,13 @@ xfs_attr_set_int(xfs_inode_t *dp, struct xfs_name *name, } else { error = xfs_attr_node_addname(&args); } - if (error) { + if (error) goto out; - } /* * If this is a synchronous mount, make sure that the - * transaction goes to disk before returning to the user. + * transaction goes to disk before returning to the user. If + * this is not our transaction, the allocator should do this. */ if (mp->m_flags & XFS_MOUNT_WSYNC) { xfs_trans_set_sync(args.trans); @@ -430,8 +459,12 @@ xfs_attr_set_int(xfs_inode_t *dp, struct xfs_name *name, /* * Commit the last in the sequence of transactions. */ - xfs_trans_log_inode(args.trans, dp, XFS_ILOG_CORE); - error = xfs_trans_commit(args.trans, XFS_TRANS_RELEASE_LOG_RES); + if (tpp) { + xfs_trans_roll(&args.trans, dp); + } else { + xfs_trans_log_inode(args.trans, dp, XFS_ILOG_CORE); + error = xfs_trans_commit(args.trans, XFS_TRANS_RELEASE_LOG_RES); + } xfs_iunlock(dp, XFS_ILOCK_EXCL); /* @@ -441,6 +474,8 @@ xfs_attr_set_int(xfs_inode_t *dp, struct xfs_name *name, xfs_ichgtime(dp, XFS_ICHGTIME_CHG); } + if (tpp) + *tpp = args.trans; return(error); out: @@ -448,9 +483,23 @@ out: xfs_trans_cancel(args.trans, XFS_TRANS_RELEASE_LOG_RES|XFS_TRANS_ABORT); xfs_iunlock(dp, XFS_ILOCK_EXCL); + if (tpp) + *tpp = args.trans; return(error); } +STATIC int +xfs_attr_set_int( + xfs_inode_t *dp, + struct xfs_name *name, + char *value, + int valuelen, + int flags) +{ + return xfs_attr_set_int_trans(NULL, dp, name, + value, valuelen, flags); +} + int xfs_attr_set( xfs_inode_t *dp, -- 1.5.6.2 From owner-xfs@oss.sgi.com Thu Jul 10 00:39:16 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 10 Jul 2008 00:39: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.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.0-r574664 Received: from relay.sgi.com (relay2.corp.sgi.com [192.26.58.22]) by oss.sgi.com (8.12.11.20060308/8.12.11/SuSE Linux 0.7) with ESMTP id m6A7dGWu018290 for ; Thu, 10 Jul 2008 00:39:16 -0700 Received: from outhouse.melbourne.sgi.com (outhouse.melbourne.sgi.com [134.14.52.145]) by relay2.corp.sgi.com (Postfix) with ESMTP id 1F126304076 for ; Thu, 10 Jul 2008 00:39:12 -0700 (PDT) Received: from itchy.melbourne.sgi.com (postfix@itchy.melbourne.sgi.com [134.14.55.96]) by outhouse.melbourne.sgi.com (SGI-8.12.5/8.12.5) with ESMTP id m6A7d8jm2589202 for ; Thu, 10 Jul 2008 17:39:09 +1000 (AEST) Received: by itchy.melbourne.sgi.com (Postfix, from userid 16403) id 6745D58876; Thu, 10 Jul 2008 17:39:05 +1000 (EST) From: Niv Sardi To: xfs@oss.sgi.com Subject: [UPDATED RFC] Create with EA initial work Date: Thu, 10 Jul 2008 17:39:01 +1000 Message-Id: <1215675545-2707-1-git-send-email-xaiki@sgi.com> X-Mailer: git-send-email 1.5.6.2 In-Reply-To: <1214196150-5427-1-git-send-email-xaiki@sgi.com> References: <1214196150-5427-1-git-send-email-xaiki@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit 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: 16830 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 Thanks to everyone for the review of the former patchset, this ones fixes the bugs found by dgc, changes the naming of the *_trans_* functions, splits out xfs_bmap_add_attrfork{,_trans} to have one version doing the whole allocation and calling into the other as suggested by hch, and has the x_t -> struct x changes too. There is a bug in this, that I can see with the Parent Pointers code going on top of it (that will be posted soon), it is basically calling xfs_attr_set_int_trans() in xfs_create() just before the last commit. For some reason, the first call to xfs_roll_trans (after xfs_bmap_add_attrfork_trans()) will complain about the inode being unlocked after xfs_trans_commit(). I understand I need to call xfs_trans_ihold(ip) on it, but we already do in xfs_create() so I think I must be missing something elseā€¦ any ideas ? From owner-xfs@oss.sgi.com Thu Jul 10 09:47:18 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 10 Jul 2008 09:47: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=-0.6 required=5.0 tests=BAYES_00,DATE_IN_FUTURE_06_12, 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 m6AGlIsW026122 for ; Thu, 10 Jul 2008 09:47:18 -0700 X-ASG-Debug-ID: 1215708503-5b3b02dc0000-NocioJ X-Barracuda-URL: http://cuda.sgi.com:80/cgi-bin/mark.cgi Received: from yx-out-1718.google.com (localhost [127.0.0.1]) by cuda.sgi.com (Spam Firewall) with ESMTP id 5E5892D7DEB for ; Thu, 10 Jul 2008 09:48:23 -0700 (PDT) Received: from yx-out-1718.google.com (yx-out-1718.google.com [74.125.44.153]) by cuda.sgi.com with ESMTP id hqSLy4qTdDejaNBs for ; Thu, 10 Jul 2008 09:48:23 -0700 (PDT) Received: by yx-out-1718.google.com with SMTP id 36so895715yxh.32 for ; Thu, 10 Jul 2008 09:48:21 -0700 (PDT) Received: by 10.114.125.2 with SMTP id x2mr11455564wac.59.1215708499133; Thu, 10 Jul 2008 09:48:19 -0700 (PDT) Received: from localhost ( [67.160.173.222]) by mx.google.com with ESMTPS id 9sm365897wfc.6.2008.07.10.09.47.47 (version=SSLv3 cipher=RC4-MD5); Thu, 10 Jul 2008 09:48:18 -0700 (PDT) Date: Thu, 10 Jul 2008 17:53:40 -0700 From: Brandon Philips To: Andreas Gruenbacher , tes@sgi.com Cc: xfs@oss.sgi.com X-ASG-Orig-Subj: [PATCH] acl: Fix WALK_TREE_RECURSIVE for the WALK_TREE_DEREFERENCE case Subject: [PATCH] acl: Fix WALK_TREE_RECURSIVE for the WALK_TREE_DEREFERENCE case Message-ID: <20080711005340.GA30185@potty.ifup.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.18 (2008-05-17) X-Barracuda-Connect: yx-out-1718.google.com[74.125.44.153] X-Barracuda-Start-Time: 1215708504 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0049 1.0000 -1.9887 X-Barracuda-Virus-Scanned: by cuda.sgi.com at sgi.com X-Barracuda-Spam-Score: -0.49 X-Barracuda-Spam-Status: No, SCORE=-0.49 using per-user scores of TAG_LEVEL=2.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=2.1 tests=DATE_IN_FUTURE_06_12 X-Barracuda-Spam-Report: Code version 3.1, rules version 3.1.55677 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 1.50 DATE_IN_FUTURE_06_12 Date: is 6 to 12 hours after Received: date 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: 16831 X-ecartis-version: Ecartis v1.0.0 Sender: xfs-bounce@oss.sgi.com Errors-to: xfs-bounce@oss.sgi.com X-original-sender: brandon@ifup.org Precedence: bulk X-list: xfs NOTE: Sending to xfs@oss.sgi.com instead of acl-devel since it doesn't seem active anymore. getfacl.c calls walk_tree() with WALK_TREE_DEREFERENCE. This causes a stat() of symlinks which in turn causes S_ISDIR(st.st_mode) to be true on symlinks. This causes getfacl -P to return the contents of symlinks... e.g. $ mkdir -p test/sub $ mkdir test/link $ touch test/link/file $ ln -s `pwd`/test/link test/sub/link $ getfacl -P -R test/sub # file: test/sub # owner: philips # group: users user::rwx group::r-x other::r-x # file: test/sub/link/file # owner: philips # group: users user::rw- group::r-- other::r-- After the fix: $ getfacl -R -P test/sub/ # file: test/sub/ # owner: philips # group: users user::rwx group::r-x other::r-x Signed-off-by: Brandon Philips --- libmisc/walk_tree.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) Index: acl-2.2.47/libmisc/walk_tree.c =================================================================== --- acl-2.2.47.orig/libmisc/walk_tree.c +++ acl-2.2.47/libmisc/walk_tree.c @@ -93,8 +93,15 @@ static int walk_tree_rec(const char *pat have_dir_stat = 1; } err = func(path, &st, flags, arg); + + /* + * Recurse if WALK_TREE_RECURSIVE and the path is: + * a dir not from a symlink + * a link and follow_symlinks + */ if ((flags & WALK_TREE_RECURSIVE) && - (S_ISDIR(st.st_mode) || (S_ISLNK(st.st_mode) && follow_symlinks))) { + (!(flags & WALK_TREE_SYMLINK) && S_ISDIR(st.st_mode)) || + ((flags & WALK_TREE_SYMLINK) && follow_symlinks)) { struct dirent *entry; /* From owner-xfs@oss.sgi.com Thu Jul 10 15:41:52 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 10 Jul 2008 15:41: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 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 m6AMfo6U030424 for ; Thu, 10 Jul 2008 15:41:52 -0700 X-ASG-Debug-ID: 1215729774-724003880000-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 5A5DCDF2F31 for ; Thu, 10 Jul 2008 15:42:55 -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 ySo8bYDKupSItD0N for ; Thu, 10 Jul 2008 15:42:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHYrdkh5LFxA/2dsb2JhbACyFA X-IronPort-AV: E=Sophos;i="4.30,341,1212330600"; d="scan'208";a="146254480" Received: from ppp121-44-92-64.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.92.64]) by ipmail01.adl6.internode.on.net with ESMTP; 11 Jul 2008 08:12:39 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KH4qU-0002jZ-23 for xfs@oss.sgi.com; Fri, 11 Jul 2008 08:42:38 +1000 Date: Fri, 11 Jul 2008 08:42:38 +1000 From: Dave Chinner To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [patch] xfsqa 078 - use rmdir to remove directories Subject: Re: [patch] xfsqa 078 - use rmdir to remove directories Message-ID: <20080710224237.GX11558@disturbed> Mail-Followup-To: xfs@oss.sgi.com References: <20080522061120.GP173056135@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080522061120.GP173056135@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: 1215729776 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.55699 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: 16832 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 ping? On Thu, May 22, 2008 at 04:11:20PM +1000, David Chinner wrote: > > If test 078 fails and you try to run it again immediately, it > will execute a 'rm -f' on a directory which will fail. This should > be a rmdir.... > > Signed-off-by: Dave Chinner > --- > xfstests/078 | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > Index: xfs-cmds/xfstests/078 > =================================================================== > --- xfs-cmds.orig/xfstests/078 2008-03-20 09:10:02.000000000 +1100 > +++ xfs-cmds/xfstests/078 2008-05-15 23:21:58.192413673 +1000 > @@ -50,8 +50,8 @@ _filter_io() > # real QA test starts here > > echo "*** create loop mount point" > -rm -f $LOOP_MNT 2>/dev/null > -mkdir $LOOP_MNT || _fail "cannot create loopback mount point" > +rmdir $LOOP_MNT 2>/dev/null > +mkdir -p $LOOP_MNT || _fail "cannot create loopback mount point" > > _grow_loop() > { > > -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Thu Jul 10 15:43:36 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 10 Jul 2008 15:43:38 -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,J_CHICKENPOX_29 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 m6AMhZDP030789 for ; Thu, 10 Jul 2008 15:43:36 -0700 X-ASG-Debug-ID: 1215729880-05d103470000-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 B68F5DF358C for ; Thu, 10 Jul 2008 15:44:40 -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 6RloNwfu7twzruql for ; Thu, 10 Jul 2008 15:44:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHYrdkh5LFxA/2dsb2JhbACyFA X-IronPort-AV: E=Sophos;i="4.30,341,1212330600"; d="scan'208";a="146255441" Received: from ppp121-44-92-64.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.92.64]) by ipmail01.adl6.internode.on.net with ESMTP; 11 Jul 2008 08:14:39 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KH4sR-0002mD-Gb for xfs@oss.sgi.com; Fri, 11 Jul 2008 08:44:39 +1000 Date: Fri, 11 Jul 2008 08:44:34 +1000 From: Dave Chinner To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [patch] allow mkfs to make larger logs Subject: Re: [patch] allow mkfs to make larger logs Message-ID: <20080710224434.GY11558@disturbed> Mail-Followup-To: xfs@oss.sgi.com References: <20080522061222.GQ173056135@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080522061222.GQ173056135@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: 1215729881 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.55699 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: 16833 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 ping? On Thu, May 22, 2008 at 04:12:22PM +1000, David Chinner wrote: > > Increase the maximum log size supported by mkfs. > > The log size can be increased easily in mkfs by changing a few > defines and a couple of types to allow the log size to increase to > just under 2GB. Theoretically, the log size can be made much, much > larger than this (up to 2^32 sectors), but going beyond 2^31 > *bytes* causes integer overflow issues in the kernel log code. > > We use a maximum size of just under 2GB as exactly 2GB will cause > overflow issues on the first transaction reservation. > > Maximum log size is now reached at a fs size of ~4TB. > > Signed-off-by: Dave Chinner > --- > xfsprogs/include/xfs_fs.h | 11 +++++++---- > xfsprogs/mkfs/xfs_mkfs.c | 14 +++++++------- > 2 files changed, 14 insertions(+), 11 deletions(-) > > Index: xfs-cmds/xfsprogs/include/xfs_fs.h > =================================================================== > --- xfs-cmds.orig/xfsprogs/include/xfs_fs.h 2008-05-15 16:32:52.929462025 +1000 > +++ xfs-cmds/xfsprogs/include/xfs_fs.h 2008-05-15 18:50:19.494520368 +1000 > @@ -248,10 +248,13 @@ typedef struct xfs_fsop_resblks { > * Minimum and maximum sizes need for growth checks > */ > #define XFS_MIN_AG_BLOCKS 64 > -#define XFS_MIN_LOG_BLOCKS 512 > -#define XFS_MAX_LOG_BLOCKS (64 * 1024) > -#define XFS_MIN_LOG_BYTES (256 * 1024) > -#define XFS_MAX_LOG_BYTES (128 * 1024 * 1024) > +#define XFS_MIN_LOG_BLOCKS 512ULL > +#define XFS_MAX_LOG_BLOCKS (1024 * 1024ULL) > +#define XFS_MIN_LOG_BYTES (10 * 1024 * 1024ULL) > + > +/* keep the maximum size under 2^31 by a small amount */ > +#define XFS_MAX_LOG_BYTES \ > + ((2 * 1024 * 1024 * 1024ULL) - XFS_MIN_LOG_BYTES) > > /* > * Structures for XFS_IOC_FSGROWFSDATA, XFS_IOC_FSGROWFSLOG & XFS_IOC_FSGROWFSRT > Index: xfs-cmds/xfsprogs/mkfs/xfs_mkfs.c > =================================================================== > --- xfs-cmds.orig/xfsprogs/mkfs/xfs_mkfs.c 2008-05-15 16:32:53.013451121 +1000 > +++ xfs-cmds/xfsprogs/mkfs/xfs_mkfs.c 2008-05-15 18:47:54.093343349 +1000 > @@ -362,13 +362,13 @@ validate_log_size(__uint64_t logblocks, > } > if (logblocks > XFS_MAX_LOG_BLOCKS) { > fprintf(stderr, > - _("log size %lld blocks too large, maximum size is %d blocks\n"), > + _("log size %lld blocks too large, maximum size is %lld blocks\n"), > (long long)logblocks, XFS_MAX_LOG_BLOCKS); > usage(); > } > if ((logblocks << blocklog) > XFS_MAX_LOG_BYTES) { > fprintf(stderr, > - _("log size %lld bytes too large, maximum size is %d bytes\n"), > + _("log size %lld bytes too large, maximum size is %lld bytes\n"), > (long long)(logblocks << blocklog), XFS_MAX_LOG_BYTES); > usage(); > } > @@ -1724,7 +1724,7 @@ reported by the device (%u).\n"), > min_logblocks = max_tr_res * XFS_MIN_LOG_FACTOR; > min_logblocks = MAX(XFS_MIN_LOG_BLOCKS, min_logblocks); > if (!logsize && dblocks >= (1024*1024*1024) >> blocklog) > - min_logblocks = MAX(min_logblocks, (10*1024*1024)>>blocklog); > + min_logblocks = MAX(min_logblocks, XFS_MIN_LOG_BYTES>>blocklog); > if (logsize && xi.logBBsize > 0 && logblocks > DTOBT(xi.logBBsize)) { > fprintf(stderr, > _("size %s specified for log subvolume is too large, maximum is %lld blocks\n"), > @@ -1744,10 +1744,10 @@ _("size %s specified for log subvolume i > logblocks = 0; > } else if (loginternal && !logsize) { > /* > - * logblocks grows from min_logblocks to XFS_MAX_LOG_BLOCKS > - * at 128GB > - * > - * 2048 = 128GB / MAX_LOG_BYTES > + * With a 2GB max log size, default to maximum size > + * at 4TB. This keeps the same ratio from the older > + * max log size of 128M at 256GB fs size. IOWs, > + * the ratio of fs size to log size is 2048:1. > */ > logblocks = (dblocks << blocklog) / 2048; > logblocks = logblocks >> blocklog; > > -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Thu Jul 10 15:44:13 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 10 Jul 2008 15:44: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.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 m6AMiCcX031075 for ; Thu, 10 Jul 2008 15:44:12 -0700 X-ASG-Debug-ID: 1215729917-269c02250000-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 9C9452D7BA0 for ; Thu, 10 Jul 2008 15:45:17 -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 lpAAxVMQAKfVgHJS for ; Thu, 10 Jul 2008 15:45:17 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHYrdkh5LFxA/2dsb2JhbACyFA X-IronPort-AV: E=Sophos;i="4.30,341,1212330600"; d="scan'208";a="146255765" Received: from ppp121-44-92-64.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.92.64]) by ipmail01.adl6.internode.on.net with ESMTP; 11 Jul 2008 08:15:15 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KH4t1-0002ne-F4 for xfs@oss.sgi.com; Fri, 11 Jul 2008 08:45:15 +1000 Date: Fri, 11 Jul 2008 08:45:15 +1000 From: Dave Chinner To: xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [patch] xfsqa test to check log size scaling Subject: Re: [patch] xfsqa test to check log size scaling Message-ID: <20080710224515.GZ11558@disturbed> Mail-Followup-To: xfs@oss.sgi.com References: <20080522061257.GR173056135@sgi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080522061257.GR173056135@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: 1215729918 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.55698 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: 16834 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 ping? On Thu, May 22, 2008 at 04:12:57PM +1000, David Chinner wrote: > XFS-QA test to check that log size scaling works correctly > for old and new maximum log sizes. > > Signed-off-by: Dave Chinner > --- > xfstests/188 | 88 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ > xfstests/188.out | 16 ++++++++++ > xfstests/group | 1 > 3 files changed, 105 insertions(+) > > Index: xfs-cmds/xfstests/188 > =================================================================== > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ xfs-cmds/xfstests/188 2008-05-15 22:39:08.741203552 +1000 > @@ -0,0 +1,88 @@ > +#! /bin/sh > +# FS QA Test No. 188 > +# > +# large log size mkfs test - ensure the log size scaling works > +# > +#----------------------------------------------------------------------- > +# Copyright (c) 2008 Silicon Graphics, Inc. All Rights Reserved. > +#----------------------------------------------------------------------- > +# > +# creator > +owner=dgc@sgi.com > + > +seq=`basename $0` > +echo "QA output created by $seq" > + > +here=`pwd` > +tmp=/tmp/$$ > +status=1 # failure is the default! > +trap "_cleanup; exit \$status" 0 1 2 3 15 > + > +_cleanup() > +{ > + cd / > + rm -f $tmp.* > + _cleanup_testdir > +} > + > +# get standard environment, filters and checks > +. ./common.rc > +. ./common.filter > + > +# real QA test starts here > +_supported_fs xfs > +_supported_os Linux > + > +_setup_testdir > +_require_scratch > +_scratch_mkfs_xfs >/dev/null 2>&1 > +_scratch_mount > + > +_require_loop > +LOOP_DEV=$SCRATCH_MNT/test_fs > +LOOP_MNT=$SCRATCH_MNT/test_fs_dir > + > +_do_mkfs() > +{ > + for i in $*; do > + echo -n "fssize=${i}g " > + $MKFS_XFS_PROG -f -b size=4096 -l version=2 \ > + -d name=$LOOP_DEV,size=${i}g |grep log > + mount -o loop -t xfs $LOOP_DEV $LOOP_MNT > + echo "test write" > $LOOP_MNT/test > + umount $LOOP_MNT > + done > +} > +# make large holey file > +$XFS_IO_PROG -f -c "truncate 100t" $LOOP_DEV > + > +#make loopback mount dir > +mkdir $LOOP_MNT > + > +# test if large logs are supported > +LARGE_LOG= > +$MKFS_XFS_PROG -f -l size=256m -d name=$LOOP_DEV,size=10g > /dev/null 2>&1 > +if [ $? -eq 0 ]; then > + LARGE_LOG=true > +fi > + > +# walk over standard sizes (up to 256GB) > +_do_mkfs 1 2 4 8 16 32 64 128 256 > + > +if [ -n "$LARGE_LOG" ]; then > + # walk over larger sizes > + _do_mkfs 512 1024 2048 4096 8192 16384 > +else > + # just cut'n'paste from the golden output for the remaining sizes > + cat << EOF > +fssize=512g log =internal log bsize=4096 blocks=65536, version=2 > +fssize=1024g log =internal log bsize=4096 blocks=131072, version=2 > +fssize=2048g log =internal log bsize=4096 blocks=262144, version=2 > +fssize=4096g log =internal log bsize=4096 blocks=521728, version=2 > +fssize=8192g log =internal log bsize=4096 blocks=521728, version=2 > +fssize=16384g log =internal log bsize=4096 blocks=521728, version=2 > +EOF > +fi > + > +status=0 > +exit > Index: xfs-cmds/xfstests/188.out > =================================================================== > --- /dev/null 1970-01-01 00:00:00.000000000 +0000 > +++ xfs-cmds/xfstests/188.out 2008-05-15 22:39:26.254922874 +1000 > @@ -0,0 +1,16 @@ > +QA output created by 188 > +fssize=1g log =internal log bsize=4096 blocks=2560, version=2 > +fssize=2g log =internal log bsize=4096 blocks=2560, version=2 > +fssize=4g log =internal log bsize=4096 blocks=2560, version=2 > +fssize=8g log =internal log bsize=4096 blocks=2560, version=2 > +fssize=16g log =internal log bsize=4096 blocks=2560, version=2 > +fssize=32g log =internal log bsize=4096 blocks=4096, version=2 > +fssize=64g log =internal log bsize=4096 blocks=8192, version=2 > +fssize=128g log =internal log bsize=4096 blocks=16384, version=2 > +fssize=256g log =internal log bsize=4096 blocks=32768, version=2 > +fssize=512g log =internal log bsize=4096 blocks=65536, version=2 > +fssize=1024g log =internal log bsize=4096 blocks=131072, version=2 > +fssize=2048g log =internal log bsize=4096 blocks=262144, version=2 > +fssize=4096g log =internal log bsize=4096 blocks=521728, version=2 > +fssize=8192g log =internal log bsize=4096 blocks=521728, version=2 > +fssize=16384g log =internal log bsize=4096 blocks=521728, version=2 > Index: xfs-cmds/xfstests/group > =================================================================== > --- xfs-cmds.orig/xfstests/group 2008-05-15 16:32:52.489519140 +1000 > +++ xfs-cmds/xfstests/group 2008-05-15 22:38:32.000000000 +1000 > @@ -275,3 +275,4 @@ filestreams dgc@sgi.com > 185 dmapi auto > 186 attr auto > 187 attr auto > +188 log metadata auto > > -- Dave Chinner david@fromorbit.com From owner-xfs@oss.sgi.com Thu Jul 10 17:32:02 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 10 Jul 2008 17:32: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.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 m6B0VxbR012864 for ; Thu, 10 Jul 2008 17:32:01 -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 KAA04031; Fri, 11 Jul 2008 10:32:57 +1000 Message-ID: <4876AA39.804@sgi.com> Date: Fri, 11 Jul 2008 10:32:57 +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 2/3] simplify xfs_setattr References: <20080627154557.GB31476@lst.de> <20080705172021.GA7177@lst.de> <48747DAD.7060501@sgi.com> <20080709162914.GA16308@lst.de> In-Reply-To: <20080709162914.GA16308@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: 16835 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 Wed, Jul 09, 2008 at 06:58:21PM +1000, Timothy Shimmin wrote: >>> - 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 >>> - >> So this code looks different. >> We are now dropping the flags. Why is that? >> Presumably because we were mapping ia_valid's: >> ATTR_MTIME_SET or ATTR_ATIME_SET --> ATTR_UTIME >> ATTR_NO_BLOCK -> ATTR_NONBLOCK >> But now we pass ATTR_?TIME_SET and ATTR_NO_BLOCK straight thru. >> So previously we didn't map them onto va_mask bits but as separate flags >> instead. > > Yeah, not that ATTR_NO_BLOCK doesn't actually exist in any tree I have > access to, and thus it's not actually handled in the new xfs_setattr. > Hmm...confusing re NO_BLOCK. 1 linux-2.6/xfs_vnode.h 228 #define ATTR_NONBLOCK 0x100 2 linux-2.6/xfs_ioctl.c xfs_ioc_space 686 attr_flags |= ATTR_NONBLOCK; 3 linux-2.6/xfs_ioctl.c xfs_ioc_fssetxattr 899 attr_flags |= ATTR_NONBLOCK; 4 linux-2.6/xfs_ioctl.c xfs_ioc_setxflags 951 attr_flags |= ATTR_NONBLOCK; 5 linux-2.6/xfs_iops.c xfs_vn_setattr 703 flags |= ATTR_NONBLOCK; 1 xfs/xfs_dmapi.h 169 #define AT_DELAY_FLAG(f) ((f&ATTR_NONBLOCK) ? DM_FLAGS_NDELAY : 0) 2 xfs/xfs_vnodeops.c xfs_setattr 200 int dmflags = AT_DELAY_FLAG(flags) | DM_SEM_FLAG_WR; 3 xfs/xfs_vnodeops.c xfs_setattr 757 0, 0, AT_DELAY_FLAG(flags)); 4 xfs/xfs_vnodeops.c xfs_free_file_space 3536 AT_DELAY_FLAG(attr_flags), NULL); So it's just used for dmapi stuff as it only looks like it is tested by AT_DELAY_FLAG(). So for xfs_setattr it will be expecting it coming in as flags param and then testing it via AT_DELAY_FLAG. Hmmm...doesn't seem so good. So looks like it was handled by xfs_setattr and still is. So are we going to be doing the right thing now? If it could just never be set then what is the point of using AT_DELAY_FLAG() in xfs_setattr? >> So we get rid of the test for XFS_AT_NOSET. >> where: >> #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) >> >> I can't see anywhere we set any of these. >> Presumably out of the xattr calls. >> Some left over from IRIX I guess. > > Probably. Note that linux uses the ATTR_ flags only for ->setattr so > there are per defintion none that can't be set. > Which is nice. >> #define XFS_AT_UPDATIME 0x00010000 >> #define XFS_AT_UPDMTIME 0x00020000 >> #define XFS_AT_UPDCTIME 0x00040000 >> 3 more not supported by vfs ATTR_* macros. >> I can't see where we set any of these. >> So no loss there I guess. >> Presumably they were just for IRIX. > > It's an IRIX leftover. I will submit a patch to introduce something > similar to Linux for 2.6.27, that's why I'd like these patches in for > 2.6.26 so that I have a clean base to start from. Ok. --Tim From owner-xfs@oss.sgi.com Thu Jul 10 18:07:00 2008 Received: with ECARTIS (v1.0.0; list xfs); Thu, 10 Jul 2008 18:07: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.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 m6B170Ym015834 for ; Thu, 10 Jul 2008 18:07:00 -0700 X-ASG-Debug-ID: 1215738480-64c001250000-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 BBF20DF3C9C for ; Thu, 10 Jul 2008 18:08:01 -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 qbp094yC3jddYMQk for ; Thu, 10 Jul 2008 18:08:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAF9Odkh5LFxA/2dsb2JhbACxSEE X-IronPort-AV: E=Sophos;i="4.30,341,1212330600"; d="scan'208";a="146346294" Received: from ppp121-44-92-64.lns10.syd6.internode.on.net (HELO disturbed) ([121.44.92.64]) by ipmail01.adl6.internode.on.net with ESMTP; 11 Jul 2008 10:37:59 +0930 Received: from dave by disturbed with local (Exim 4.69) (envelope-from ) id 1KH779-0007wV-6s; Fri, 11 Jul 2008 11:07:59 +1000 Date: Fri, 11 Jul 2008 11:07:59 +1000 From: Dave Chinner To: Timothy Shimmin Cc: Christoph Hellwig , xfs@oss.sgi.com X-ASG-Orig-Subj: Re: [PATCH 2/3] simplify xfs_setattr Subject: Re: [P