tag:old.nabble.com,2006:forum-1029Nabble - Xfs2009-11-30T12:33:49ZXFS combines advanced journaling technology with full 64-bit addressing and scalable structures and algorithms. This combination delivers the most scalable and high-performance filesystem in the world. Xfs home is <a href="http://oss.sgi.com/projects/xfs/" target="_top" rel="nofollow">here</a>.tag:old.nabble.com,2006:post-26581752Re: [PATCH] xfs: check for not fully initialized inodes in xfs_ireclaim2009-11-30T12:33:49Z2009-11-30T12:33:49ZChristoph HellwigOn Mon, Nov 30, 2009 at 02:07:40PM -0600, Alex Elder wrote:
<div class='shrinkable-quote'><br>> Christoph Hellwig wrote:
<br>> > Add an assert for inodes not added to the inode cache in xfs_ireclaim, to make
<br>> > sure we're not going to introduce something like the famous nfsd inode cache
<br>> > bug again.
<br>>
<br>> I confess I have not looked at the radix tree
<br>> code in detail yet, but radix_tree_delete()
<br>> returns a value that is ignored here. It reportedly
<br>> will return a null pointer if the index has no
<br>> corresponding item in the tree, so this could be
<br>> used in the assertion rather than doing a separate
<br>> lookup.
<br>>
<br>> I think the change is fine, but would rather see
<br>> it done without the extra lookup (though there may
<br>> be a good reason for doing it anyway).
</div><br>Sounds good, I'll redo it.
<br><br>_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26581752&i=0" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26581313RE: [PATCH] xfs: check for not fully initialized inodes in xfs_ireclaim2009-11-30T12:07:40Z2009-11-30T12:07:40ZAlex ElderChristoph Hellwig wrote:
<br>> Add an assert for inodes not added to the inode cache in xfs_ireclaim, to make
<br>> sure we're not going to introduce something like the famous nfsd inode cache
<br>> bug again.
<br><br>I confess I have not looked at the radix tree
<br>code in detail yet, but radix_tree_delete()
<br>returns a value that is ignored here. It reportedly
<br>will return a null pointer if the index has no
<br>corresponding item in the tree, so this could be
<br>used in the assertion rather than doing a separate
<br>lookup.
<br><br>I think the change is fine, but would rather see
<br>it done without the extra lookup (though there may
<br>be a good reason for doing it anyway).
<br><br> -Alex
<br><div class='shrinkable-quote'><br>> Signed-off-by: Christoph Hellwig <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26581313&i=0" target="_top" rel="nofollow">hch@...</a>>
<br>>
<br>> Index: xfs/fs/xfs/xfs_iget.c
<br>> ===================================================================
<br>> --- xfs.orig/fs/xfs/xfs_iget.c 2009-11-12 17:10:20.216276486 +0100
<br>> +++ xfs/fs/xfs/xfs_iget.c 2009-11-12 17:13:27.565003964 +0100
<br>> @@ -514,17 +514,21 @@ xfs_ireclaim(
<br>> {
<br>> struct xfs_mount *mp = ip->i_mount;
<br>> struct xfs_perag *pag;
<br>> + xfs_agino_t agino = XFS_INO_TO_AGINO(mp, ip->i_ino);
<br>>
<br>> XFS_STATS_INC(xs_ig_reclaims);
<br>>
<br>> /*
<br>> - * Remove the inode from the per-AG radix tree. It doesn't matter
<br>> - * if it was never added to it because radix_tree_delete can deal
<br>> - * with that case just fine.
<br>> + * Remove the inode from the per-AG radix tree.
<br>> + *
<br>> + * Because radix_tree_delete won't complain even if the item was never
<br>> + * added to the tree assert that it's been there before to catch
<br>> + * problems with the inode life time early on.
<br>> */
<br>> pag = xfs_get_perag(mp, ip->i_ino);
<br>> write_lock(&pag->pag_ici_lock);
<br>> - radix_tree_delete(&pag->pag_ici_root, XFS_INO_TO_AGINO(mp, ip->i_ino));
<br>> + ASSERT(radix_tree_lookup(&pag->pag_ici_root, agino));
<br>> + radix_tree_delete(&pag->pag_ici_root, agino);
<br>> write_unlock(&pag->pag_ici_lock);
<br>> xfs_put_perag(mp, pag);
<br>>
<br>>
<br>> _______________________________________________
<br>> xfs mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26581313&i=1" target="_top" rel="nofollow">xfs@...</a>
<br>> <a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a></div><br>_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26581313&i=2" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26577522Re: XFS & LVM: unexpected cp when issuing mv2009-11-30T07:30:06Z2009-11-30T07:30:06ZMichael Monnerie-5On Montag, 30. November 2009 Alex Elder wrote:
<br>> The quota inheritance property Dave described only applies
<br>> to project quotas, not group or user quotas.
<br>>
<br>Thanks. I thought about it but can't use them anyway, as I would have to
<br>change the owner of files on upload. But I want to keep that
<br>information. So turning off quota is our only chance by now :-(
<br><br>mfg zmi
<br>--
<br>// Michael Monnerie, Ing.BSc ----- <a href="http://it-management.at" target="_top" rel="nofollow">http://it-management.at</a><br>// Tel: 0660 / 415 65 31 .network.your.ideas.
<br>// PGP Key: "curl -s <a href="http://zmi.at/zmi.asc" target="_top" rel="nofollow">http://zmi.at/zmi.asc</a> | gpg --import"
<br>// Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4
<br>// Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4
<br><br /> <br />_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26577522&i=0" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>signature.asc</strong> (205 bytes) <a href="http://old.nabble.com/attachment/26577522/0/signature.asc" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26576026RE: XFS & LVM: unexpected cp when issuing mv2009-11-30T06:21:01Z2009-11-30T06:21:01ZAlex ElderMichael Monnerie wrote:
<div class='shrinkable-quote'><br>> On Montag, 30. November 2009 Dave Chinner wrote:
<br>>>> 1) why this happens
<br>>>
<br>>> It happens if you move from one project directory heirarchy to
<br>>> another - rename is not allowed across project quota boundaries as
<br>>> the moved data has to be correctly attributed to the new project.
<br>>> Hence it causes a mv to do a copy/unlink by returning a EXDEV error to the rename.
<br>>>
<br>>>> 2) how I can prevent this?
<br>>>
<br>>> You can't if you are moving from one project to another. If you
<br>>> move within the project heirarchy, then it will be a rename as per
<br>>> normal.
<br>>
<br>> Shit. So I have to turn project quotas off. I can't accept the extra
<br>> load for a simple move, as there are tons of data. Maybe the projet code
<br>> could be redesigned to allow a simple move? Is it that complicated?
<br>>
<br>> If I change from project to user quota - I guess the same would still
<br>> happen? If so, I have to drop quota support, and build a script to check
<br>> quotas manually. It's a pity. :-(
</div><br>The quota inheritance property Dave described only applies
<br>to project quotas, not group or user quotas.
<br><br> -Alex
<br><br>> mfg zmi
<br><br>_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26576026&i=0" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26575601RE: 2.6.31.6: XFS DEBUG: Assertions cause kernel OOPS.2009-11-30T06:15:57Z2009-11-30T06:15:57ZJustin Piszcz<br><br>On Mon, 30 Nov 2009, Alex Elder wrote:
<br><div class='shrinkable-quote'><br>> Justin Piszcz wrote:
<br>>> Hi,
<br>>>
<br>>> I wanted to compile my kernel with DEBUG for XFS and also kernel frame pointers
<br>>> to catch any issues.
<br>>>
<br>>> However, DEBUG for XFS does more harm than good?
<br>>
<br>> It should not. This simple patch would improve things
<br>> but I'll add to my to-do list a review of assertions
<br>> to find and fix things of this type.
<br>>
<br>> -Alex
<br>>
<br>> diff -Naur old/fs/xfs/xfs_bmap.c new/fs/xfs/xfs_bmap.c
<br>> --- old/fs/xfs/xfs_bmap.c 2009-11-30 07:55:59.000000000 -0600
<br>> +++ new/fs/xfs/xfs_bmap.c 2009-11-30 07:56:43.000000000 -0600
<br>> @@ -4843,6 +4843,7 @@
<br>> orig_mval = mval;
<br>> orig_nmap = *nmap;
<br>> #endif
<br>> + ASSERT(nmap != NULL);
<br>> ASSERT(*nmap >= 1);
<br>> ASSERT(*nmap <= XFS_BMAP_MAX_NMAP || !(flags & XFS_BMAPI_WRITE));
<br>> whichfork = (flags & XFS_BMAPI_ATTRFORK) ?
<br>>
<br>>
</div><br>The patch failed against 2.6.31.6 but I added that line at that point anyway,
<br>ok thanks will let you know if I see anything else with DEBUG enabled.
<br><br>Justin.
<br><br>_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26575601&i=0" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26575602RE: 2.6.31.6: XFS DEBUG: Assertions cause kernel OOPS.2009-11-30T05:59:01Z2009-11-30T05:59:01ZAlex ElderJustin Piszcz wrote:
<br>> Hi,
<br>>
<br>> I wanted to compile my kernel with DEBUG for XFS and also kernel frame pointers
<br>> to catch any issues.
<br>>
<br>> However, DEBUG for XFS does more harm than good?
<br><br>It should not. This simple patch would improve things
<br>but I'll add to my to-do list a review of assertions
<br>to find and fix things of this type.
<br><br> -Alex
<br><br>diff -Naur old/fs/xfs/xfs_bmap.c new/fs/xfs/xfs_bmap.c
<br>--- old/fs/xfs/xfs_bmap.c 2009-11-30 07:55:59.000000000 -0600
<br>+++ new/fs/xfs/xfs_bmap.c 2009-11-30 07:56:43.000000000 -0600
<br>@@ -4843,6 +4843,7 @@
<br> orig_mval = mval;
<br> orig_nmap = *nmap;
<br> #endif
<br>+ ASSERT(nmap != NULL);
<br> ASSERT(*nmap >= 1);
<br> ASSERT(*nmap <= XFS_BMAP_MAX_NMAP || !(flags & XFS_BMAPI_WRITE));
<br> whichfork = (flags & XFS_BMAPI_ATTRFORK) ?
<br><br><div class='shrinkable-quote'><br>> I tried to install bonnie++:
<br>> # apt-get install -y bonnie++
<br>>
<br>> And then this happened:
<br>>
<br>> [ 1578.768558] Assertion failed: *nmap >= 1, file: fs/xfs/xfs_bmap.c, line: 4846
<br>> [ 1578.768633] ------------[ cut here ]------------
<br>> [ 1578.768690] kernel BUG at fs/xfs/support/debug.c:109!
<br>> [ 1578.768742] invalid opcode: 0000 [#1] SMP
<br>> [ 1578.768839] last sysfs file:
<br>> /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host15/target15:0:0/15:0:0:0/queue_depth [
<br>> 1578.768939] CPU 1 [ 1578.769016] Pid: 3273, comm: dpkg Not tainted 2.6.31.6 #6
<br>> [ 1578.769083] RIP: 0010:[<ffffffff81243ada>] [<ffffffff81243ada>] assfail+0x1a/0x20
<br>> [ 1578.769203] RSP: 0018:ffff880121d4bc08 EFLAGS: 00010296
<br>> [ 1578.769252] RAX: 0000000000000054 RBX: 0000000000000000 RCX: ffffffff81364fb0
<br>> [ 1578.769252] RDX: ffff880028038000 RSI: 0000000000000046 RDI: ffffffff816b4730
<br>> [ 1578.769252] RBP: ffff880121d4bc08 R08: 0000000000000000 R09: 0000000000000006
<br>> [ 1578.769252] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000800000000
<br>> [ 1578.769252] R13: ffff88012a295580 R14: 0000000000000002 R15: ffff88012a522000
<br>> [ 1578.769252] FS: 00007f2a7367d790(0000) GS:ffff880028038000(0000) knlGS:0000000000000000
<br>> [ 1578.769252] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<br>> [ 1578.769252] CR2: 000000000204e000 CR3: 0000000121d53000 CR4: 00000000000026e0
<br>> [ 1578.769252] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
<br>> [ 1578.769252] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
<br>> [ 1578.769252] Process dpkg (pid: 3273, threadinfo ffff880121d4a000, task ffff88012b98b990)
<br>> [ 1578.769252] Stack:
<br>> [ 1578.769252] ffff880121d4bdb8 ffffffff811eb916 0000000121d4bc38 000000000204e000
<br>> [ 1578.769252] <0> ffff8801244a85d0 0000000000000286 ffff880121d4bc68 ffffffff81260c51
<br>> [ 1578.769252] <0> ffff880121d4bc68 0000000000000000 000000080204e000 00000000007ffff8
<br>> [ 1578.769252] Call Trace:
<br>> [ 1578.769252] [<ffffffff811eb916>] xfs_bmapi+0x66/0x1940
<br>> [ 1578.769252] [<ffffffff81260c51>] ? __up_read+0x91/0xb0
<br>> [ 1578.769252] [<ffffffff8123a0a7>] ? xfs_buf_free+0xc7/0x110
<br>> [ 1578.769252] [<ffffffff8123a1e6>] ? xfs_buf_rele+0xf6/0x130
<br>> [ 1578.769252] [<ffffffff8122e70a>] ? xfs_trans_brelse+0x19a/0x2a0
<br>> [ 1578.769252] [<ffffffff811f7ac7>] ? xfs_da_brelse+0x77/0x120
<br>> [ 1578.769252] [<ffffffff810bf63d>] ? filldir+0x9d/0xe0
<br>> [ 1578.769252] [<ffffffff8120225a>] xfs_dir2_leaf_getdents+0x61a/0x780
<br>> [ 1578.769252] [<ffffffff810bf5a0>] ? filldir+0x0/0xe0
<br>> [ 1578.769252] [<ffffffff810bf5a0>] ? filldir+0x0/0xe0
<br>> [ 1578.769252] [<ffffffff811fc6ec>] xfs_readdir+0x10c/0x110
<br>> [ 1578.769252] [<ffffffff810bf5a0>] ? filldir+0x0/0xe0
<br>> [ 1578.769252] [<ffffffff8123b4f4>] xfs_file_readdir+0x34/0x50
<br>> [ 1578.769252] [<ffffffff810bf7f8>] vfs_readdir+0xa8/0xc0
<br>> [ 1578.769252] [<ffffffff810bf963>] sys_getdents+0x83/0xe0
<br>> [ 1578.769252] [<ffffffff8102d1ab>] system_call_fastpath+0x16/0x1b
<br>> [ 1578.769252] Code: 57 81 48 c7 c7 8e 94 57 81 e8 b3 19 02 00 c9 c3 90 55 89 d1 48 89 e5 48 89
<br>> f2 31 c0 48 89 fe 48 c7 c7 f0 d0 59 81 e8 15 6a 25 00 <0f> 0b eb fe 66 90 55 48 89 e5 41 57 41
<br>> 56 49 89 ce 41 55 49 89 [ 1578.773074] RIP [<ffffffff81243ada>] assfail+0x1a/0x20 [
<br>> 1578.773074] RSP <ffff880121d4bc08> [ 1578.773343] ---[ end trace 00b4a182e72dfb60 ]---
<br>>
<br>> Will recompile without XFS DEBUG but FYI.
<br>>
<br>> Justin.
<br>>
<br>> _______________________________________________
<br>> xfs mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26575602&i=0" target="_top" rel="nofollow">xfs@...</a>
<br>> <a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a></div><br>_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26575602&i=1" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26575185Re: XFS & LVM: unexpected cp when issuing mv2009-11-30T05:42:20Z2009-11-30T05:42:20ZMichael Monnerie-5On Montag, 30. November 2009 Dave Chinner wrote:
<div class='shrinkable-quote'><div class='shrinkable-quote'><br>> > 1) why this happens
<br>>
<br>> It happens if you move from one project directory heirarchy to
<br>> another - rename is not allowed across project quota boundaries as
<br>> the moved data has to be correctly attributed to the new project.
<br>> Hence it causes a mv to do a copy/unlink by returning a EXDEV error
<br>> to the rename.
<br>>
<br>> > 2) how I can prevent this?
<br>>
<br>> You can't if you are moving from one project to another. If you
<br>> move within the project heirarchy, then it will be a rename as per
<br>> normal.
</div>
</div>Shit. So I have to turn project quotas off. I can't accept the extra
<br>load for a simple move, as there are tons of data. Maybe the projet code
<br>could be redesigned to allow a simple move? Is it that complicated?
<br><br>If I change from project to user quota - I guess the same would still
<br>happen? If so, I have to drop quota support, and build a script to check
<br>quotas manually. It's a pity. :-(
<br><br>mfg zmi
<br>--
<br>// Michael Monnerie, Ing.BSc ----- <a href="http://it-management.at" target="_top" rel="nofollow">http://it-management.at</a><br>// Tel: 0660 / 415 65 31 .network.your.ideas.
<br>// PGP Key: "curl -s <a href="http://zmi.at/zmi.asc" target="_top" rel="nofollow">http://zmi.at/zmi.asc</a> | gpg --import"
<br>// Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4
<br>// Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4
<br><br /> <br />_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26575185&i=0" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>signature.asc</strong> (205 bytes) <a href="http://old.nabble.com/attachment/26575185/0/signature.asc" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26575188Re: XFS & LVM: unexpected cp when issuing mv2009-11-30T05:32:53Z2009-11-30T05:32:53ZMichael Monnerie-5On Sonntag, 29. November 2009 Asdo wrote:
<br>> Please paste the output of the following 2 commands:
<br>
<br># df /disks/sharestore/upload/
<br>Filesystem 1K-blocks Used Available Use% Mounted on
<br>/dev/mapper/sharestore-public
<br> 4192254976 1956672968 2235582008 47%
<br>/disks/sharestore
<br><br># df /disks/sharestore/download/
<br>Filesystem 1K-blocks Used Available Use% Mounted on
<br>/dev/mapper/sharestore-public
<br> 4192254976 1956675156 2235579820 47%
<br>/disks/sharestore
<br><br>Yes, it really *is* the same filesystem.
<br><br>mfg zmi
<br>--
<br>// Michael Monnerie, Ing.BSc ----- <a href="http://it-management.at" target="_top" rel="nofollow">http://it-management.at</a><br>// Tel: 0660 / 415 65 31 .network.your.ideas.
<br>// PGP Key: "curl -s <a href="http://zmi.at/zmi.asc" target="_top" rel="nofollow">http://zmi.at/zmi.asc</a> | gpg --import"
<br>// Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4
<br>// Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4
<br><br /> <br />_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26575188&i=0" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>signature.asc</strong> (205 bytes) <a href="http://old.nabble.com/attachment/26575188/0/signature.asc" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-265747162.6.31.6: XFS DEBUG: Assertions cause kernel OOPS.2009-11-30T05:22:03Z2009-11-30T05:22:03ZJustin PiszczHi,
<br><br>I wanted to compile my kernel with DEBUG for XFS and also kernel frame pointers
<br>to catch any issues.
<br><br>However, DEBUG for XFS does more harm than good?
<br><br>I tried to install bonnie++:
<br># apt-get install -y bonnie++
<br><br>And then this happened:
<br><br>[ 1578.768558] Assertion failed: *nmap >= 1, file: fs/xfs/xfs_bmap.c, line: 4846
<br>[ 1578.768633] ------------[ cut here ]------------
<br>[ 1578.768690] kernel BUG at fs/xfs/support/debug.c:109!
<br>[ 1578.768742] invalid opcode: 0000 [#1] SMP
<br>[ 1578.768839] last sysfs file: /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/host15/target15:0:0/15:0:0:0/queue_depth
<br>[ 1578.768939] CPU 1
<br>[ 1578.769016] Pid: 3273, comm: dpkg Not tainted 2.6.31.6 #6
<br>[ 1578.769083] RIP: 0010:[<ffffffff81243ada>] [<ffffffff81243ada>] assfail+0x1a/0x20
<br>[ 1578.769203] RSP: 0018:ffff880121d4bc08 EFLAGS: 00010296
<br>[ 1578.769252] RAX: 0000000000000054 RBX: 0000000000000000 RCX: ffffffff81364fb0
<br>[ 1578.769252] RDX: ffff880028038000 RSI: 0000000000000046 RDI: ffffffff816b4730
<br>[ 1578.769252] RBP: ffff880121d4bc08 R08: 0000000000000000 R09: 0000000000000006
<br>[ 1578.769252] R10: 0000000000000000 R11: 0000000000000001 R12: 0000000800000000
<br>[ 1578.769252] R13: ffff88012a295580 R14: 0000000000000002 R15: ffff88012a522000
<br>[ 1578.769252] FS: 00007f2a7367d790(0000) GS:ffff880028038000(0000) knlGS:0000000000000000
<br>[ 1578.769252] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<br>[ 1578.769252] CR2: 000000000204e000 CR3: 0000000121d53000 CR4: 00000000000026e0
<br>[ 1578.769252] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
<br>[ 1578.769252] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
<br>[ 1578.769252] Process dpkg (pid: 3273, threadinfo ffff880121d4a000, task ffff88012b98b990)
<br>[ 1578.769252] Stack:
<br>[ 1578.769252] ffff880121d4bdb8 ffffffff811eb916 0000000121d4bc38 000000000204e000
<br>[ 1578.769252] <0> ffff8801244a85d0 0000000000000286 ffff880121d4bc68 ffffffff81260c51
<br>[ 1578.769252] <0> ffff880121d4bc68 0000000000000000 000000080204e000 00000000007ffff8
<br>[ 1578.769252] Call Trace:
<br>[ 1578.769252] [<ffffffff811eb916>] xfs_bmapi+0x66/0x1940
<br>[ 1578.769252] [<ffffffff81260c51>] ? __up_read+0x91/0xb0
<br>[ 1578.769252] [<ffffffff8123a0a7>] ? xfs_buf_free+0xc7/0x110
<br>[ 1578.769252] [<ffffffff8123a1e6>] ? xfs_buf_rele+0xf6/0x130
<br>[ 1578.769252] [<ffffffff8122e70a>] ? xfs_trans_brelse+0x19a/0x2a0
<br>[ 1578.769252] [<ffffffff811f7ac7>] ? xfs_da_brelse+0x77/0x120
<br>[ 1578.769252] [<ffffffff810bf63d>] ? filldir+0x9d/0xe0
<br>[ 1578.769252] [<ffffffff8120225a>] xfs_dir2_leaf_getdents+0x61a/0x780
<br>[ 1578.769252] [<ffffffff810bf5a0>] ? filldir+0x0/0xe0
<br>[ 1578.769252] [<ffffffff810bf5a0>] ? filldir+0x0/0xe0
<br>[ 1578.769252] [<ffffffff811fc6ec>] xfs_readdir+0x10c/0x110
<br>[ 1578.769252] [<ffffffff810bf5a0>] ? filldir+0x0/0xe0
<br>[ 1578.769252] [<ffffffff8123b4f4>] xfs_file_readdir+0x34/0x50
<br>[ 1578.769252] [<ffffffff810bf7f8>] vfs_readdir+0xa8/0xc0
<br>[ 1578.769252] [<ffffffff810bf963>] sys_getdents+0x83/0xe0
<br>[ 1578.769252] [<ffffffff8102d1ab>] system_call_fastpath+0x16/0x1b
<br>[ 1578.769252] Code: 57 81 48 c7 c7 8e 94 57 81 e8 b3 19 02 00 c9 c3 90 55 89 d1 48 89 e5 48 89 f2 31 c0 48 89 fe 48 c7 c7 f0 d0 59 81 e8 15 6a 25 00 <0f> 0b eb fe 66 90 55 48 89 e5 41 57 41 56 49 89 ce 41 55 49 89
<br>[ 1578.773074] RIP [<ffffffff81243ada>] assfail+0x1a/0x20
<br>[ 1578.773074] RSP <ffff880121d4bc08>
<br>[ 1578.773343] ---[ end trace 00b4a182e72dfb60 ]---
<br><br>Will recompile without XFS DEBUG but FYI.
<br><br>Justin.
<br><br>_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26574716&i=0" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26570295Re: Writing journal only in Big Endian format2009-11-29T22:43:56Z2009-11-29T22:43:56ZDave ChinnerOn Mon, Nov 30, 2009 at 10:47:41AM +0530, Nitin Arora wrote:
<br>> The problem is that big endian machine cannot recognize the
<br>> journal which was written in little endian format by the little
<br>> endian machine and once the journal is zerod out it can be
<br>> mouted.
<br>>
<br>> Now the solution to above problem seems writing journal always in
<br>> big endian format.
<br><br>Or you could just replay the log on the little endian machine and do
<br>a clean unmount, then you should be able to move it to the big
<br>endian machine without losing anything.
<br><br>> Please suggest me, Is there any design limitation in XFS for this.
<br><br>No design limitation, just a *lot* of work to change. If you don't
<br>have a few months handy to work on this, I'd just use the above
<br>method....
<br><br>> Is it okay and feasible to implement it if yes then please give
<br>> some pointers so that it can be implemented,
<br><br>All log headers, tails and sector fills need to be converted, every log
<br>item format routine needs a big-endian version, log recovery needs
<br>to be able to read both host-format and big-endian logs, all the
<br>userspace tools need to learn about different log formats, QA tests
<br>need to be written, etc.
<br><br>> under some suitable
<br>> compile time switch.
<br><br>It could be done with a superblock feature bit, so the same kernel
<br>could support both big-endian logs and host format.
<br><br>Cheers,
<br><br>Dave.
<br>--
<br>Dave Chinner
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26570295&i=0" target="_top" rel="nofollow">david@...</a>
<br><br>_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26570295&i=1" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26570123Re: Writing journal only in Big Endian format2009-11-29T21:58:54Z2009-11-29T21:58:54ZEric Sandeen-3<html><body bgcolor="#FFFFFF"><div>On Nov 29, 2009, at 11:17 PM, Nitin Arora <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26570123&i=0" target="_top" rel="nofollow">nitin.arora.del@...</a>> wrote:<br><br></div><div></div><blockquote type="cite"><div>Hello,<br><br>We are using XFS (Kernel 2.6.18) and facing a problem.<br>When any XFS partition is plugged out from a little endian machine and plugged in to a big endian machine,<br>it cannot be mounted and gives the following error.<br>
<br><p><span lang="EN-US">FAT: utf8 is not a recommended IO charset for FAT
filesystems, filesystem will be case sensitive!</span></p>
<p><span lang="EN-US">FAT: bogus number of FAT structure</span></p>
<p><span lang="EN-US">VFS: Can't find a valid FAT filesystem on dev
sda1.</span></p>
<p><span lang="EN-US">VFS: Can't find ext3 filesystem on dev
sda1.</span></p>
<p><span lang="EN-US">XFS mounting filesystem sda1</span></p>
<p><span lang="EN-US">Starting XFS recovery on filesystem: sda1 (logdev:
internal)</span></p>
<p><span style="color: red;" lang="EN-US">XFS: dirty log written in incompatible
format - can't recover</span></p>
<p><span lang="EN-US">XFS: log mount/recovery failed: error
5</span></p>
<p><span lang="EN-US">XFS: log mount failed</span></p><br></div></blockquote><div><br></div>Yep this Is expected for a dirty log, but I think a cleanly unmounted filesystem should migrate without problems; is this not the case?<div><br></div><div>So really the problem should be limited to migrating -dirty- filesystems, and the complexity of endian-swapping the journal at runtime seems overly expensive for this odd case.</div><div><br></div><div>Just unmount before migration....</div><div><br></div><div>-Eric<br><blockquote type="cite"><div><br>Mounting problem goes away after doing <i>"xfs_repair -L /dev/sdb2"<br><br></i>The problem is that big endian machine cannot recognize the journal which was written in <br>
little endian format by the little endian machine and once the journal is zerod out it can be mouted.<br><br>Now the solution to above problem seems writing journal always in big endian format.<br><br>Please suggest me, Is there any design limitation in XFS for this.<br>
Is it okay and feasible to implement it if yes then please give some pointers so that it can be implemented, under some <br>suitable compile time switch.<br><br>Thanks in advance...<br><br>Regards<br>Nitin Arora<br>
</div></blockquote></div></body></html><br />_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26570123&i=1" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26569802Writing journal only in Big Endian format2009-11-29T21:17:41Z2009-11-29T21:17:41ZNitin Arora-2Hello,<br><br>We are using XFS (Kernel 2.6.18) and facing a problem.<br>When any XFS partition is plugged out from a little endian machine and plugged in to a big endian machine,<br>it cannot be mounted and gives the following error.<br>
<br><p><span lang="EN-US">FAT: utf8 is not a recommended IO charset for FAT
filesystems, filesystem will be case sensitive!</span></p>
<p><span lang="EN-US">FAT: bogus number of FAT structure</span></p>
<p><span lang="EN-US">VFS: Can't find a valid FAT filesystem on dev
sda1.</span></p>
<p><span lang="EN-US">VFS: Can't find ext3 filesystem on dev
sda1.</span></p>
<p><span lang="EN-US">XFS mounting filesystem sda1</span></p>
<p><span lang="EN-US">Starting XFS recovery on filesystem: sda1 (logdev:
internal)</span></p>
<p><span style="color: red;" lang="EN-US">XFS: dirty log written in incompatible
format - can't recover</span></p>
<p><span lang="EN-US">XFS: log mount/recovery failed: error
5</span></p>
<p><span lang="EN-US">XFS: log mount failed</span></p><br><br>Mounting problem goes away after doing <i>"xfs_repair -L /dev/sdb2"<br><br></i>The problem is that big endian machine cannot recognize the journal which was written in <br>
little endian format by the little endian machine and once the journal is zerod out it can be mouted.<br><br>Now the solution to above problem seems writing journal always in big endian format.<br><br>Please suggest me, Is there any design limitation in XFS for this.<br>
Is it okay and feasible to implement it if yes then please give some pointers so that it can be implemented, under some <br>suitable compile time switch.<br><br>Thanks in advance...<br><br>Regards<br>Nitin Arora<br>
<br />_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26569802&i=0" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26567559Re: XFS & LVM: unexpected cp when issuing mv2009-11-29T15:27:16Z2009-11-29T15:27:16ZDave ChinnerOn Sun, Nov 29, 2009 at 02:52:16PM +0100, Michael Monnerie wrote:
<div class='shrinkable-quote'><br>> I have an unexpected behaviour and I hope someone can explain me the
<br>> reasons:
<br>>
<br>> This is an openSUSE 11.2 virtual machine within XENserver. XENserver can
<br>> only create 2TB disks, but I needed more. So I create 2x 2TB disks for
<br>> that VM. These disks have no partitions, but are straight LVM:
<br>> # pvscan
<br>> PV /dev/xvdb VG sharestore lvm2 [1,95 TB / 0 free]
<br>> PV /dev/xvdc VG sharestore lvm2 [1,95 TB / 0 free]
<br>> Total: 2 [3,91 TB] / in use: 2 [3,91 TB] / in no VG: 0 [0 ]
<br>>
<br>> I created one VG, and then one LV:
<br>> # vgscan
<br>> Reading all physical volumes. This may take a while...
<br>> Found volume group "sharestore" using metadata type lvm2
<br>> # lvscan
<br>> ACTIVE '/dev/sharestore/public' [3,91 TB] inherit
<br>>
<br>> On that LV, I created an XFS filesystem, mounted from /etc/fstab:
<br>> /dev/sharestore/public /disks/sharestore xfs
<br>> noatime,nodiratime,logbufs=8,logbsize=256k,attr2,nobarrier,largeio,swalloc,inode64,prjquota
</div><br>You are using project quotas.
<br><div class='shrinkable-quote'><br>> Now when I move from one dir to another, example
<br>> mv /disks/sharestore/upload/* /disks/sharestore/download/
<br>>
<br>> within some dirs it's a simple mv where only metadata is moved, but with
<br>> some dirs it's a physical cp+rm of the files. You can easily see that by
<br>> the speed of the mv, plus with iostat:
<br>> Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-
<br>> sz avgqu-sz await svctm %util
<br>> xvdb 0,00 0,00 0,00 647,31 0,00 28424,75
<br>> 87,82 18,46 29,71 0,24 15,65
<br>> xvdc 0,00 0,40 631,14 2,40 26928,54 76,65
<br>> 85,25 5,56 8,69 1,56 98,84
<br>>
<br>> Until now I believed that a mv within one filesystem is always just a
<br>> metadata mv. But it seems I found a case now where even within the same
<br>> filesystem a physical cp+rm is done. Can someone explain me
<br>>
<br>> 1) why this happens
</div><br>It happens if you move from one project directory heirarchy to
<br>another - rename is not allowed across project quota boundaries as
<br>the moved data has to be correctly attributed to the new project.
<br>Hence it causes a mv to do a copy/unlink by returning a EXDEV error
<br>to the rename.
<br><br>> 2) how I can prevent this?
<br><br>You can't if you are moving from one project to another. If you
<br>move within the project heirarchy, then it will be a rename as per
<br>normal.
<br><br>Cheers,
<br><br>Dave.
<br>--
<br>Dave Chinner
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26567559&i=0" target="_top" rel="nofollow">david@...</a>
<br><br>_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26567559&i=1" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26566993Re: xfsdump debian package generation2009-11-29T14:07:42Z2009-11-29T14:07:42ZNathan Scott-5<br>----- "Christoph Hellwig" <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26566993&i=0" target="_top" rel="nofollow">hch@...</a>> wrote:
<br><br>> Hi Nathan,
<br>>
<br>> it seems like xfsdump doesn't have the hardlink based debian package
<br>> generation yet. I was just looking at porting over all recent build
<br>> system improvement in xfsprogs and wondered if that was intentional.
<br>>
<br>> If possible I'd like to keep the two build systems as close as
<br>> possible.
<br><br>Not intentionally different, I just didn't get to it yet.
<br><br>cheers.
<br><br>--
<br>Nathan
<br><br>_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26566993&i=1" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26562736Re: XFS & LVM: unexpected cp when issuing mv2009-11-29T06:41:31Z2009-11-29T06:41:31ZAsdo<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Please paste the output of the following 2 commands:<br>
<br>
df /disks/sharestore/upload/
<br>
<br>
df /disks/sharestore/download/
<br>
<br>
<br>
Michael Monnerie wrote:
<blockquote cite="mid:200911291452.20646@zmi.at" type="cite">
<pre wrap="">I have an unexpected behaviour and I hope someone can explain me the
reasons:
This is an openSUSE 11.2 virtual machine within XENserver. XENserver can
only create 2TB disks, but I needed more. So I create 2x 2TB disks for
that VM. These disks have no partitions, but are straight LVM:
# pvscan
PV /dev/xvdb VG sharestore lvm2 [1,95 TB / 0 free]
PV /dev/xvdc VG sharestore lvm2 [1,95 TB / 0 free]
Total: 2 [3,91 TB] / in use: 2 [3,91 TB] / in no VG: 0 [0 ]
I created one VG, and then one LV:
# vgscan
Reading all physical volumes. This may take a while...
Found volume group "sharestore" using metadata type lvm2
# lvscan
ACTIVE '/dev/sharestore/public' [3,91 TB] inherit
On that LV, I created an XFS filesystem, mounted from /etc/fstab:
/dev/sharestore/public /disks/sharestore xfs
noatime,nodiratime,logbufs=8,logbsize=256k,attr2,nobarrier,largeio,swalloc,inode64,prjquota
Now when I move from one dir to another, example
mv /disks/sharestore/upload/* /disks/sharestore/download/
within some dirs it's a simple mv where only metadata is moved, but with
some dirs it's a physical cp+rm of the files. You can easily see that by
the speed of the mv, plus with iostat:
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-
sz avgqu-sz await svctm %util
xvdb 0,00 0,00 0,00 647,31 0,00 28424,75
87,82 18,46 29,71 0,24 15,65
xvdc 0,00 0,40 631,14 2,40 26928,54 76,65
85,25 5,56 8,69 1,56 98,84
Until now I believed that a mv within one filesystem is always just a
metadata mv. But it seems I found a case now where even within the same
filesystem a physical cp+rm is done. Can someone explain me
1) why this happens
2) how I can prevent this?
We have files >5G there, often 20G or more, so a mv should just be a
metadata mv, everything else is inacceptable.
Could it be the way I created the VG + LV, that there's a cp instead mv?
How could I create all that to get a normal behaviour?
Maybe like this?:
1) create VG only on one disk
2) create LV on that disk
3) create XFS
4) extend VG to 2nd disk
5) extend LV to 2nd disk
6) xfs_growfs to 2nd disk
mfg zmi
</pre>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
xfs mailing list
<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26562736&i=0" target="_top" rel="nofollow">xfs@...</a>
<a class="moz-txt-link-freetext" href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a>
</pre>
</blockquote>
<br>
</body>
</html>
<br />_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26562736&i=1" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26562285XFS & LVM: unexpected cp when issuing mv2009-11-29T05:52:16Z2009-11-29T05:52:16ZMichael Monnerie-5I have an unexpected behaviour and I hope someone can explain me the
<br>reasons:
<br><br>This is an openSUSE 11.2 virtual machine within XENserver. XENserver can
<br>only create 2TB disks, but I needed more. So I create 2x 2TB disks for
<br>that VM. These disks have no partitions, but are straight LVM:
<br># pvscan
<br> PV /dev/xvdb VG sharestore lvm2 [1,95 TB / 0 free]
<br> PV /dev/xvdc VG sharestore lvm2 [1,95 TB / 0 free]
<br> Total: 2 [3,91 TB] / in use: 2 [3,91 TB] / in no VG: 0 [0 ]
<br><br>I created one VG, and then one LV:
<br># vgscan
<br> Reading all physical volumes. This may take a while...
<br> Found volume group "sharestore" using metadata type lvm2
<br># lvscan
<br> ACTIVE '/dev/sharestore/public' [3,91 TB] inherit
<br><br>On that LV, I created an XFS filesystem, mounted from /etc/fstab:
<br>/dev/sharestore/public /disks/sharestore xfs
<br>noatime,nodiratime,logbufs=8,logbsize=256k,attr2,nobarrier,largeio,swalloc,inode64,prjquota
<br><br>Now when I move from one dir to another, example
<br>mv /disks/sharestore/upload/* /disks/sharestore/download/
<br><br>within some dirs it's a simple mv where only metadata is moved, but with
<br>some dirs it's a physical cp+rm of the files. You can easily see that by
<br>the speed of the mv, plus with iostat:
<br>Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-
<br>sz avgqu-sz await svctm %util
<br>xvdb 0,00 0,00 0,00 647,31 0,00 28424,75
<br>87,82 18,46 29,71 0,24 15,65
<br>xvdc 0,00 0,40 631,14 2,40 26928,54 76,65
<br>85,25 5,56 8,69 1,56 98,84
<br><br>Until now I believed that a mv within one filesystem is always just a
<br>metadata mv. But it seems I found a case now where even within the same
<br>filesystem a physical cp+rm is done. Can someone explain me
<br><br>1) why this happens
<br>2) how I can prevent this?
<br><br>We have files >5G there, often 20G or more, so a mv should just be a
<br>metadata mv, everything else is inacceptable.
<br>Could it be the way I created the VG + LV, that there's a cp instead mv?
<br>How could I create all that to get a normal behaviour?
<br><br>Maybe like this?:
<br>1) create VG only on one disk
<br>2) create LV on that disk
<br>3) create XFS
<br>4) extend VG to 2nd disk
<br>5) extend LV to 2nd disk
<br>6) xfs_growfs to 2nd disk
<br><br>mfg zmi
<br>--
<br>// Michael Monnerie, Ing.BSc ----- <a href="http://it-management.at" target="_top" rel="nofollow">http://it-management.at</a><br>// Tel: 0660 / 415 65 31 .network.your.ideas.
<br>// PGP Key: "curl -s <a href="http://zmi.at/zmi.asc" target="_top" rel="nofollow">http://zmi.at/zmi.asc</a> | gpg --import"
<br>// Fingerprint: AC19 F9D5 36ED CD8A EF38 500E CE14 91F7 1C12 09B4
<br>// Keyserver: wwwkeys.eu.pgp.net Key-ID: 1C1209B4
<br><br /> <br />_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26562285&i=0" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>signature.asc</strong> (205 bytes) <a href="http://old.nabble.com/attachment/26562285/0/signature.asc" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26561803Re: please help me! thanks2009-11-29T04:35:49Z2009-11-29T04:35:49ZPeter Grandi-10[ ... ]
<br><br>>>> .el5 smells like Red Hat, Red Hat doesn't do XFS. At least in
<br>>>> nothing that is currently released AFAIR.
<br><br>>> 5.4 has XFS
<br><br>> I googled 5.4 and found a CERT that mentions 2.6.18-164. So i
<br>> guess minimum kernel for 5.4 is way more recent than -128.
<br><br>I think that while the 'xfs.ko' module is part of the base kernels
<br>available standard with EL 5.4, there is an XFS (including 'xfsprogs'
<br>and support) "layered product" from RedHat (that is an optional
<br>extra license) which has become available starting from EL 5.4.
<br><br>Apparently RH have finally realized that many of their enterprise
<br>customers have large XFS based storage systems and these are not
<br>going to be moved to 'ext4' any time soon (also because EL6 is not
<br>going to appear for a while yet).
<br><br> That's I think way EricS replied to consult the distribution
<br> vendor.
<br><br>Alternatively there are the XFS RPMs from ElRepo or CentOSPlus or
<br>SL5; since EL releases are supposed (mostly indeed in my experience)
<br>to be binary-compatible within major releases, they work well across
<br>all EL5 clones.
<br><br>_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26561803&i=0" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26560579Re: please help me! thanks2009-11-29T01:39:03Z2009-11-29T01:39:03ZMatthias SchniedermeyerOn 28.11.2009 18:02, Chris Wedgwood wrote:
<br>> On Sat, Nov 28, 2009 at 07:42:50PM +0100, Matthias Schniedermeyer wrote:
<br>>
<br>> > .el5 smells like Red Hat, Red Hat doesn't do XFS.
<br>> > At least in nothing that is currently released AFAIR.
<br>>
<br>> 5.4 has XFS
<br><br>I googled 5.4 and found a CERT that mentions 2.6.18-164.
<br>So i guess minimum kernel for 5.4 is way more recent than -128.
<br><br>So OP appears that have a pre 5.4 release running.
<br><br><br><br><br><br>Bis denn
<br><br>--
<br>Real Programmers consider "what you see is what you get" to be just as
<br>bad a concept in Text Editors as it is in women. No, the Real Programmer
<br>wants a "you asked for it, you got it" text editor -- complicated,
<br>cryptic, powerful, unforgiving, dangerous.
<br><br>_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26560579&i=0" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26555928Re: please help me! thanks2009-11-28T10:42:50Z2009-11-28T10:42:50ZMatthias SchniedermeyerOn 28.11.2009 11:33, <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26555928&i=0" target="_top" rel="nofollow">givemefile@...</a> wrote:
<br>> my OS:
<br>> [root@DDD-1 ~]# uname -a
<br>> Linux DDD-1 2.6.18-128.el5 #1 SMP Wed Dec 17 11:42:39 EST 2008 i686 i686 i386 GNU/Linux
<br><br>.el5 smells like Red Hat, Red Hat doesn't do XFS.
<br>At least in nothing that is currently released AFAIR.
<br><br><br><br><br><br>Bis denn
<br><br>--
<br>Real Programmers consider "what you see is what you get" to be just as
<br>bad a concept in Text Editors as it is in women. No, the Real Programmer
<br>wants a "you asked for it, you got it" text editor -- complicated,
<br>cryptic, powerful, unforgiving, dangerous.
<br><br>_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26555928&i=1" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26554087Re: please help me! thanks2009-11-28T07:20:40Z2009-11-28T07:20:40ZEric Sandeen-3You need to talk to your Linux distributor....
<br><br>-Eric
<br><br>On Nov 27, 2009, at 9:33 PM, <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26554087&i=0" target="_top" rel="nofollow">givemefile@...</a> wrote:
<br><div class='shrinkable-quote'><br>> my OS:
<br>>
<br>> [root@DDD-1 ~]# uname -a
<br>> Linux DDD-1 2.6.18-128.el5 #1 SMP Wed Dec 17 11:42:39 EST 2008 i686
<br>> i686 i386 GNU/Linux
<br>> [root@DDD-1 ~]#
<br>>
<br>>
<br>>
<br>> [root@DDD-1 ~]# cat /proc/filesystems
<br>> nodev sysfs
<br>> nodev rootfs
<br>> nodev bdev
<br>> nodev proc
<br>> nodev cpuset
<br>> nodev binfmt_misc
<br>> nodev debugfs
<br>> nodev securityfs
<br>> nodev sockfs
<br>> nodev usbfs
<br>> nodev pipefs
<br>> nodev anon_inodefs
<br>> nodev futexfs
<br>> nodev tmpfs
<br>> nodev inotifyfs
<br>> nodev eventpollfs
<br>> nodev devpts
<br>> ext2
<br>> nodev ramfs
<br>> nodev hugetlbfs
<br>> iso9660
<br>> nodev mqueue
<br>> ext3
<br>> nodev vmhgfs
<br>> nodev vmblock
<br>> nodev rpc_pipefs
<br>> nodev autofs
<br>> [root@DDD-1 ~]#
<br>>
<br>>
<br>>
<br>>
<br>>
<br>> this OS don't xfs filesystem..
<br>>
<br>> Please tell me How to do it ?
<br>>
<br>> thanks
<br>>
<br>>
<br>>
<br>> _______________________________________________
<br>> xfs mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26554087&i=1" target="_top" rel="nofollow">xfs@...</a>
<br>> <a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a></div><br>_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26554087&i=2" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26550337please help me! thanks2009-11-27T19:33:25Z2009-11-27T19:33:25Zgivemefile<P> my OS: </P>
<P>[root@DDD-1 ~]# uname -a<BR>Linux DDD-1 2.6.18-128.el5 #1 SMP Wed Dec 17 11:42:39 EST 2008 i686 i686 i386 GNU/Linux<BR>[root@DDD-1 ~]# </P>
<P> </P>
<P>[root@DDD-1 ~]# cat /proc/filesystems <BR>nodev sysfs<BR>nodev rootfs<BR>nodev bdev<BR>nodev proc<BR>nodev cpuset<BR>nodev binfmt_misc<BR>nodev debugfs<BR>nodev securityfs<BR>nodev sockfs<BR>nodev usbfs<BR>nodev pipefs<BR>nodev anon_inodefs<BR>nodev futexfs<BR>nodev tmpfs<BR>nodev inotifyfs<BR>nodev eventpollfs<BR>nodev devpts<BR> ext2<BR>nodev ramfs<BR>nodev hugetlbfs<BR> iso9660<BR>nodev mqueue<BR> ext3<BR>nodev vmhgfs<BR>nodev vmblock<BR>nodev rpc_pipefs<BR>nodev autofs<BR>[root@DDD-1 ~]# </P>
<P> </P>
<P> </P>
<P>this OS don't xfs filesystem..</P>
<P>Please tell me How to do it ?</P>
<P>thanks</P>
<P> </P><br />_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26550337&i=0" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26543931xfsdump debian package generation2009-11-27T07:07:59Z2009-11-27T07:07:59ZChristoph HellwigHi Nathan,
<br><br>it seems like xfsdump doesn't have the hardlink based debian package
<br>generation yet. I was just looking at porting over all recent build
<br>system improvement in xfsprogs and wondered if that was intentional.
<br><br>If possible I'd like to keep the two build systems as close as possible.
<br><br>_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26543931&i=0" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26530223Re: XFS support for ARMv52009-11-26T06:24:08Z2009-11-26T06:24:08ZChristoph HellwigOn Thu, Nov 26, 2009 at 04:19:39PM +0200, Ofer Heifetz wrote:
<div class='shrinkable-quote'><br>> Hi Christoph,
<br>>
<br>> I applied the patches to 2.6.31.6 and the mount passes file. I copied some data to the XFS DOK and had no problem reading the content after several system reset.
<br>>
<br>> Here is a dmesg snippet:
<br>>
<br>> SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled
<br>> XFS mounting filesystem sda3
<br>> Starting XFS recovery on filesystem: sda3 (logdev: internal)
<br>> Ending XFS recovery on filesystem: sda3 (logdev: internal)
<br>>
<br>> Is this patch confirmed to be mainlined in 2.6.33?
<br>> I need to know `cos I want to run some data integrity and performance tests on this patch before I merge it.
</div><br>There's no way to 100% confirm it until it's done, but it's firmly
<br>planned.
<br><br>_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26530223&i=0" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26530222RE: XFS support for ARMv52009-11-26T06:19:39Z2009-11-26T06:19:39ZOfer HeifetzHi Christoph,
<br><br>I applied the patches to 2.6.31.6 and the mount passes file. I copied some data to the XFS DOK and had no problem reading the content after several system reset.
<br><br>Here is a dmesg snippet:
<br><br>SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled
<br>XFS mounting filesystem sda3
<br>Starting XFS recovery on filesystem: sda3 (logdev: internal)
<br>Ending XFS recovery on filesystem: sda3 (logdev: internal)
<br><br>Is this patch confirmed to be mainlined in 2.6.33?
<br>I need to know `cos I want to run some data integrity and performance tests on this patch before I merge it.
<br><br>-Ofer
<br>-----Original Message-----
<br>From: Christoph Hellwig [mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26530222&i=0" target="_top" rel="nofollow">hch@...</a>]
<br>Sent: Wednesday, November 25, 2009 11:06 PM
<br>To: Andy Poling
<br>Cc: Ofer Heifetz; <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26530222&i=1" target="_top" rel="nofollow">xfs@...</a>
<br>Subject: Re: XFS support for ARMv5
<br><br>On Wed, Nov 25, 2009 at 10:30:09AM -0600, Andy Poling wrote:
<div class='shrinkable-quote'><br>> On Mon, 23 Nov 2009, Ofer Heifetz wrote:
<br>>> Here is the dmesg I got for mount /dev/sda3 /mnt/usb:
<br>>> SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled
<br>>> XFS mounting filesystem sda3
<br>>> Starting XFS recovery on filesystem: sda3 (logdev: internal)
<br>>> XFS: xlog_recover_process_data: bad clientid
<br>>> XFS: log mount/recovery failed: error 5
<br>>> XFS: log mount failed
<br>>
<br>> See this thread in the archives for a patch that may fix this:
<br>>
<br>> <a href="http://oss.sgi.com/pipermail/xfs/2009-October/042805.html" target="_top" rel="nofollow">http://oss.sgi.com/pipermail/xfs/2009-October/042805.html</a></div><br>I don't think it's the case you found, although the symptoms are the
<br>same. I'd rather guess this is a case of an architecture with virtually
<br>indexed caches (can anyone confirm the cache architecture?) which
<br>doesn't cope too well with the way we use vmap to write into a buffer
<br>through virtually mapped linear addresses, but then do block I/O using
<br>the physical addresses of the individual pages. James Bottomley has a
<br>patchset to fix this issue by introducing APIs that allow the
<br>architecture specific memory management to cope with it. He're a
<br>version I could quickly find, although newer ones have been posted
<br>since:
<br><br> <a href="http://thread.gmane.org/gmane.linux.kernel.cross-arch/4364" target="_top" rel="nofollow">http://thread.gmane.org/gmane.linux.kernel.cross-arch/4364</a><br><br>The patchset is planned to get merged into Linux 2.6.33.
<br><br>_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26530222&i=2" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26521782User Space Releases2009-11-25T14:56:10Z2009-11-25T14:56:10ZAlex ElderOn October 23, I published an updated set of some XFS user-space
<br>source code on oss.sgi.com.
<br><br>One of the changes (in xfsprogs) affected the ABI presented by
<br>libhandle, but libhandle itself was not updated with a new
<br>version number to reflect the change. This has the potential to
<br>cause problems in the future, and in order to avoid that I will
<br>be withdrawing the 3.0.5 release of xfsprogs (as well as the
<br>3.0.3 release of xfsdump that I published at the same time).
<br><br>For most users, there is no harm in continuing to use the October
<br>code. (If you are developing code that uses the interface added
<br>in that release, be advised it may not be present in future
<br>releases.)
<br><br>A new release of xfsprogs and xfsdump will be published in early
<br>December, and everyone will be encouraged to upgrade when these
<br>are available.
<br><br>I will be replacing the tar files on oss.sgi.com for xfsprogs and
<br>xfsdump with the versions that were there previously. If you
<br>follow the git change history you will also see that some changes
<br>that were applied in October will be reverted.
<br><br>I apologize for whatever confusion or concern have resulted due
<br>to the October release.
<br><br> -Alex
<br><br>_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26521782&i=0" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26521779Re: [PATCH] Prevent lookup from finding bad buffers2009-11-25T14:29:09Z2009-11-25T14:29:09ZEric Sandeen-3Eric Sandeen wrote:
<div class='shrinkable-quote'><br>> Lachlan McIlroy wrote:
<br>>> There's a bug in _xfs_buf_find() that will cause it to return buffers
<br>>> that failed to be initialised.
<br>>>
<br>>> If a thread has a buffer locked and is waiting for I/O to initialise
<br>>> it and another thread wants the same buffer the second thread will
<br>>> wait on the buffer lock in _xfs_buf_find(). If the initial thread
<br>>> gets an I/O error it marks the buffer in error and releases the
<br>>> buffer lock. The second thread gets the buffer lock, assumes the
<br>>> buffer has been successfully initialised, and then tries to use it.
<br>>>
<br>>> Some callers of xfs_buf_get_flags() will check for B_DONE, and if
<br>>> it's not set then re-issue the I/O, bust most callers assume the
<br>>> buffer and it's contents are good and then use the uninitialised
<br>>> data.
<br>>>
<br>>> The solution I've come up with is if we lookup a buffer and find
<br>>> it's got b_error set or has been marked stale then unhash it from
<br>>> the buffer hashtable and retry the lookup. Also if we fail to setup
<br>>> the buffer correctly in xfs_buf_get_flags() then mark the buffer in
<br>>> error and unhash it. If the buffer is marked stale then in
<br>>> xfs_buf_free() inform the page cache that the contents of the pages
<br>>> are no longer valid.
<br>>
<br>> I managed to come up with a sorta-kinda testcase for this.
<br>>
<br>> Fragmented freespace, many files in a dir, on raid5; simply doing
<br>> drop caches / ls in a loop triggered it.
<br>>
<br>> I guess raid5 is bad in this respect; in it's make_request() we have:
<br>>
<br>> } else {
<br>> /* cannot get stripe for read-ahead, just give-up */
<br>> clear_bit(BIO_UPTODATE, &bi->bi_flags);
<br>> finish_wait(&conf->wait_for_overlap, &w);
<br>> break;
<br>> }
<br>>
<br>> and this happens fairly often. This probably explains a large
<br>> percentage of our xfs_da_do_buf(2) errors we've seen on the list.
<br>>
<br>> From my testing, I think this suffices - and interestingly, Lachlan's
<br>> original patch doesn't seem to help...
<br>>
<br>> Comments?
<br>>
<br>> Maybe could clean up the logic a bit... should this only be
<br>> tested for XBF_READ buffers as well ... or maybe an assert that
<br>> if !uptodate, error should be set ...
<br>>
<br>> diff --git a/fs/xfs/linux-2.6/xfs_buf.c b/fs/xfs/linux-2.6/xfs_buf.c
<br>> index 965df12..cbc0541 100644
<br>> --- a/fs/xfs/linux-2.6/xfs_buf.c
<br>> +++ b/fs/xfs/linux-2.6/xfs_buf.c
<br>> @@ -1142,6 +1165,8 @@ xfs_buf_bio_end_io(
<br>> if (unlikely(bp->b_error)) {
<br>> if (bp->b_flags & XBF_READ)
<br>> ClearPageUptodate(page);
<br>> + } else if (!test_bit(BIO_UPTODATE, &bio->bi_flags)) {
<br>> + ClearPageUptodate(bp);
<br>> } else if (blocksize >= PAGE_CACHE_SIZE) {
<br>> SetPageUptodate(page);
<br>> } else if (!PagePrivate(page) &&
</div><br>Ok, so that was shoot-from-the-hip, and actually it was tested on an
<br>older kernel; upstream didn't demonstrate the problem, thanks to:
<br><br>commit c2b00852fbae4f8c45c2651530ded3bd01bde814
<br>Author: NeilBrown <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26521779&i=0" target="_top" rel="nofollow">neilb@...</a>>
<br>Date: Sun Dec 10 02:20:51 2006 -0800
<br><br>[PATCH] md: return a non-zero error to bi_end_io as appropriate in raid5
<br><br>Currently raid5 depends on clearing the BIO_UPTODATE flag to signal an
<br>error
<br>to higher levels. While this should be sufficient, it is safer to
<br>explicitly
<br>set the error code as well - less room for confusion.
<br><br>Signed-off-by: Neil Brown <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26521779&i=1" target="_top" rel="nofollow">neilb@...</a>>
<br>Signed-off-by: Andrew Morton <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26521779&i=2" target="_top" rel="nofollow">akpm@...</a>>
<br>Signed-off-by: Linus Torvalds <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26521779&i=3" target="_top" rel="nofollow">torvalds@...</a>>
<br><br>As Neil says, xfs should probably cope too by checking uptodate itself
<br>as well, though...
<br><br>-Eric
<br><br>_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26521779&i=4" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26521784Re: XFS support for ARMv52009-11-25T14:29:00Z2009-11-25T14:29:00ZRichard Sharpe-2On Wed, Nov 25, 2009 at 1:06 PM, Christoph Hellwig <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26521784&i=0" target="_top" rel="nofollow">hch@...</a>> wrote:
<div class='shrinkable-quote'><br>> On Wed, Nov 25, 2009 at 10:30:09AM -0600, Andy Poling wrote:
<br>>> On Mon, 23 Nov 2009, Ofer Heifetz wrote:
<br>>>> Here is the dmesg I got for mount /dev/sda3 /mnt/usb:
<br>>>> SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled
<br>>>> XFS mounting filesystem sda3
<br>>>> Starting XFS recovery on filesystem: sda3 (logdev: internal)
<br>>>> XFS: xlog_recover_process_data: bad clientid
<br>>>> XFS: log mount/recovery failed: error 5
<br>>>> XFS: log mount failed
<br>>>
<br>>> See this thread in the archives for a patch that may fix this:
<br>>>
<br>>> <a href="http://oss.sgi.com/pipermail/xfs/2009-October/042805.html" target="_top" rel="nofollow">http://oss.sgi.com/pipermail/xfs/2009-October/042805.html</a><br>>
<br>> I don't think it's the case you found, although the symptoms are the
<br>> same. I'd rather guess this is a case of an architecture with virtually
<br>> indexed caches (can anyone confirm the cache architecture?) which
</div><br>The Marvell 78xx series uses a VIVT cache. I will have to consult the
<br>documentation about the 6281 (I think that was it).
<br><div class='shrinkable-quote'><br>> doesn't cope too well with the way we use vmap to write into a buffer
<br>> through virtually mapped linear addresses, but then do block I/O using
<br>> the physical addresses of the individual pages. James Bottomley has a
<br>> patchset to fix this issue by introducing APIs that allow the
<br>> architecture specific memory management to cope with it. He're a
<br>> version I could quickly find, although newer ones have been posted
<br>> since:
<br>>
<br>> <a href="http://thread.gmane.org/gmane.linux.kernel.cross-arch/4364" target="_top" rel="nofollow">http://thread.gmane.org/gmane.linux.kernel.cross-arch/4364</a><br>>
<br>> The patchset is planned to get merged into Linux 2.6.33.
<br>>
<br>> _______________________________________________
<br>> xfs mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26521784&i=1" target="_top" rel="nofollow">xfs@...</a>
<br>> <a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br>>
</div><br><br><br>--
<br>Regards,
<br>Richard Sharpe
<br><br>_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26521784&i=2" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26521391Re: XFS support for ARMv52009-11-25T14:10:36Z2009-11-25T14:10:36ZEric Sandeen-3Christoph Hellwig wrote:
<div class='shrinkable-quote'><br>> On Wed, Nov 25, 2009 at 10:30:09AM -0600, Andy Poling wrote:
<br>>> On Mon, 23 Nov 2009, Ofer Heifetz wrote:
<br>>>> Here is the dmesg I got for mount /dev/sda3 /mnt/usb:
<br>>>> SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled
<br>>>> XFS mounting filesystem sda3
<br>>>> Starting XFS recovery on filesystem: sda3 (logdev: internal)
<br>>>> XFS: xlog_recover_process_data: bad clientid
<br>>>> XFS: log mount/recovery failed: error 5
<br>>>> XFS: log mount failed
<br>>> See this thread in the archives for a patch that may fix this:
<br>>>
<br>>> <a href="http://oss.sgi.com/pipermail/xfs/2009-October/042805.html" target="_top" rel="nofollow">http://oss.sgi.com/pipermail/xfs/2009-October/042805.html</a><br>>
<br>> I don't think it's the case you found, although the symptoms are the
<br>> same. I'd rather guess this is a case of an architecture with virtually
<br>> indexed caches (can anyone confirm the cache architecture?) which
<br>> doesn't cope too well with the way we use vmap to write into a buffer
<br>> through virtually mapped linear addresses, but then do block I/O using
<br>> the physical addresses of the individual pages. James Bottomley has a
<br>> patchset to fix this issue by introducing APIs that allow the
<br>> architecture specific memory management to cope with it. He're a
<br>> version I could quickly find, although newer ones have been posted
<br>> since:
<br>>
<br>> <a href="http://thread.gmane.org/gmane.linux.kernel.cross-arch/4364" target="_top" rel="nofollow">http://thread.gmane.org/gmane.linux.kernel.cross-arch/4364</a><br>>
<br>> The patchset is planned to get merged into Linux 2.6.33.
</div><br>I'll do some ARM testing w/ that stuff next week.
<br><br>-Eric
<br><br>_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26521391&i=0" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26520997Re: [PATCH] xfstests 213: Add enospc case to fallocate test2009-11-25T13:36:10Z2009-11-25T13:36:10ZEric Sandeen-5Christoph Hellwig wrote:
<div class='shrinkable-quote'><br>> On Wed, Nov 25, 2009 at 11:18:47AM -0600, Eric Sandeen wrote:
<br>>> Add a test for ENOSPC when fallocating.
<br>>>
<br>>> Also, add an expected output, not sure how that went missing!
<br>>
<br>> Oops. Easily to do because xfstests doesn't complain but rather just
<br>> skips tests without golden output..
<br>>
<br>> I guess the ENOSPC test is to catch the inverted error returns just
<br>> detected?
</div><br>yep
<br><br>> Anyway, looks good,
<br><br>thanks!
<br><br>-eric
<br><br>>
<br>> Reviewed-by: Christoph Hellwig <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26520997&i=0" target="_top" rel="nofollow">hch@...</a>>
<br><br>_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26520997&i=1" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26520617Re: [PATCH] db: stop using xfs_bmbt_rec_32_t2009-11-25T13:10:38Z2009-11-25T13:10:38ZChristoph Hellwigping?
<br><br>On Tue, Nov 03, 2009 at 10:50:19AM -0500, Christoph Hellwig wrote:
<div class='shrinkable-quote'><br>> xfs_db uses the xfs_bmbt_rec_32_t type to pass around extent information in a
<br>> few places. But everywhere where we actually use it we use the normal
<br>> xfs_bmbt_rec_t just casting from/to xfs_bmbt_rec_32_t to pass it around.
<br>>
<br>> Just pass the xfs_bmbt_rec_t directly and thus get rid of the last use
<br>> of xfs_bmbt_rec_32_t in xfsprogs.
<br>>
<br>> Signed-off-by: Christoph Hellwig <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26520617&i=0" target="_top" rel="nofollow">hch@...</a>>
<br>>
<br>> Index: xfsprogs-dev/db/check.c
<br>> ===================================================================
<br>> --- xfsprogs-dev.orig/db/check.c 2009-10-11 03:16:17.350004081 +0200
<br>> +++ xfsprogs-dev/db/check.c 2009-11-03 16:46:56.067277983 +0100
<br>> @@ -265,7 +265,7 @@ static int ncheck_f(int argc, char **ar
<br>> static char *prepend_path(char *oldpath, char *parent);
<br>> static xfs_ino_t process_block_dir_v2(blkmap_t *blkmap, int *dot,
<br>> int *dotdot, inodata_t *id);
<br>> -static void process_bmbt_reclist(xfs_bmbt_rec_32_t *rp, int numrecs,
<br>> +static void process_bmbt_reclist(xfs_bmbt_rec_t *rp, int numrecs,
<br>> dbm_t type, inodata_t *id,
<br>> xfs_drfsbno_t *tot,
<br>> blkmap_t **blkmapp);
<br>> @@ -2012,7 +2012,7 @@ process_block_dir_v2(
<br>>
<br>> static void
<br>> process_bmbt_reclist(
<br>> - xfs_bmbt_rec_32_t *rp,
<br>> + xfs_bmbt_rec_t *rp,
<br>> int numrecs,
<br>> dbm_t type,
<br>> inodata_t *id,
<br>> @@ -2038,7 +2038,7 @@ process_bmbt_reclist(
<br>> iagno = XFS_INO_TO_AGNO(mp, id->ino);
<br>> iagbno = XFS_INO_TO_AGBNO(mp, id->ino);
<br>> for (i = 0; i < numrecs; i++, rp++) {
<br>> - convert_extent((xfs_bmbt_rec_64_t *)rp, &o, &s, &c, &f);
<br>> + convert_extent(rp, &o, &s, &c, &f);
<br>> if (v)
<br>> dbprintf(_("inode %lld extent [%lld,%lld,%lld,%d]\n"),
<br>> id->ino, o, s, c, f);
<br>> @@ -2120,7 +2120,6 @@ process_btinode(
<br>> xfs_bmdr_block_t *dib;
<br>> int i;
<br>> xfs_bmbt_ptr_t *pp;
<br>> - xfs_bmbt_rec_32_t *rp;
<br>>
<br>> dib = (xfs_bmdr_block_t *)XFS_DFORK_PTR(dip, whichfork);
<br>> if (be16_to_cpu(dib->bb_level) >= XFS_BM_MAXLEVELS(mp, whichfork)) {
<br>> @@ -2146,7 +2145,7 @@ process_btinode(
<br>> return;
<br>> }
<br>> if (be16_to_cpu(dib->bb_level) == 0) {
<br>> - rp = (xfs_bmbt_rec_32_t *)XFS_BMDR_REC_ADDR(dib, 1);
<br>> + xfs_bmbt_rec_t *rp = XFS_BMDR_REC_ADDR(dib, 1);
<br>> process_bmbt_reclist(rp, be16_to_cpu(dib->bb_numrecs), type,
<br>> id, totd, blkmapp);
<br>> *nex += be16_to_cpu(dib->bb_numrecs);
<br>> @@ -2579,12 +2578,12 @@ process_exinode(
<br>> blkmap_t **blkmapp,
<br>> int whichfork)
<br>> {
<br>> - xfs_bmbt_rec_32_t *rp;
<br>> + xfs_bmbt_rec_t *rp;
<br>>
<br>> - rp = (xfs_bmbt_rec_32_t *)XFS_DFORK_PTR(dip, whichfork);
<br>> + rp = (xfs_bmbt_rec_t *)XFS_DFORK_PTR(dip, whichfork);
<br>> *nex = XFS_DFORK_NEXTENTS(dip, whichfork);
<br>> if (*nex < 0 || *nex > XFS_DFORK_SIZE(dip, mp, whichfork) /
<br>> - sizeof(xfs_bmbt_rec_32_t)) {
<br>> + sizeof(xfs_bmbt_rec_t)) {
<br>> if (!sflag || id->ilist)
<br>> dbprintf(_("bad number of extents %d for inode %lld\n"),
<br>> *nex, id->ino);
<br>> @@ -4207,7 +4206,7 @@ scanfunc_bmap(
<br>> xfs_agnumber_t agno;
<br>> int i;
<br>> xfs_bmbt_ptr_t *pp;
<br>> - xfs_bmbt_rec_32_t *rp;
<br>> + xfs_bmbt_rec_t *rp;
<br>>
<br>> agno = XFS_FSB_TO_AGNO(mp, bno);
<br>> agbno = XFS_FSB_TO_AGBNO(mp, bno);
<br>> @@ -4240,7 +4239,7 @@ scanfunc_bmap(
<br>> error++;
<br>> return;
<br>> }
<br>> - rp = (xfs_bmbt_rec_32_t *)XFS_BMBT_REC_ADDR(mp, block, 1);
<br>> + rp = XFS_BMBT_REC_ADDR(mp, block, 1);
<br>> *nex += be16_to_cpu(block->bb_numrecs);
<br>> process_bmbt_reclist(rp, be16_to_cpu(block->bb_numrecs), type, id, totd,
<br>> blkmapp);
<br>> Index: xfsprogs-dev/db/frag.c
<br>> ===================================================================
<br>> --- xfsprogs-dev.orig/db/frag.c 2009-10-11 03:16:17.364007469 +0200
<br>> +++ xfsprogs-dev/db/frag.c 2009-11-03 16:46:56.068277413 +0100
<br>> @@ -66,7 +66,7 @@ static void extmap_set_ext(extmap_t **e
<br>> xfs_extlen_t c);
<br>> static int frag_f(int argc, char **argv);
<br>> static int init(int argc, char **argv);
<br>> -static void process_bmbt_reclist(xfs_bmbt_rec_32_t *rp, int numrecs,
<br>> +static void process_bmbt_reclist(xfs_bmbt_rec_t *rp, int numrecs,
<br>> extmap_t **extmapp);
<br>> static void process_btinode(xfs_dinode_t *dip, extmap_t **extmapp,
<br>> int whichfork);
<br>> @@ -223,7 +223,7 @@ init(
<br>>
<br>> static void
<br>> process_bmbt_reclist(
<br>> - xfs_bmbt_rec_32_t *rp,
<br>> + xfs_bmbt_rec_t *rp,
<br>> int numrecs,
<br>> extmap_t **extmapp)
<br>> {
<br>> @@ -234,7 +234,7 @@ process_bmbt_reclist(
<br>> xfs_dfsbno_t s;
<br>>
<br>> for (i = 0; i < numrecs; i++, rp++) {
<br>> - convert_extent((xfs_bmbt_rec_64_t *)rp, &o, &s, &c, &f);
<br>> + convert_extent(rp, &o, &s, &c, &f);
<br>> extmap_set_ext(extmapp, (xfs_fileoff_t)o, (xfs_extlen_t)c);
<br>> }
<br>> }
<br>> @@ -248,11 +248,10 @@ process_btinode(
<br>> xfs_bmdr_block_t *dib;
<br>> int i;
<br>> xfs_bmbt_ptr_t *pp;
<br>> - xfs_bmbt_rec_32_t *rp;
<br>>
<br>> dib = (xfs_bmdr_block_t *)XFS_DFORK_PTR(dip, whichfork);
<br>> if (be16_to_cpu(dib->bb_level) == 0) {
<br>> - rp = (xfs_bmbt_rec_32_t *)XFS_BMDR_REC_ADDR(dib, 1);
<br>> + xfs_bmbt_rec_t *rp = XFS_BMDR_REC_ADDR(dib, 1);
<br>> process_bmbt_reclist(rp, be16_to_cpu(dib->bb_numrecs), extmapp);
<br>> return;
<br>> }
<br>> @@ -270,9 +269,9 @@ process_exinode(
<br>> extmap_t **extmapp,
<br>> int whichfork)
<br>> {
<br>> - xfs_bmbt_rec_32_t *rp;
<br>> + xfs_bmbt_rec_t *rp;
<br>>
<br>> - rp = (xfs_bmbt_rec_32_t *)XFS_DFORK_PTR(dip, whichfork);
<br>> + rp = (xfs_bmbt_rec_t *)XFS_DFORK_PTR(dip, whichfork);
<br>> process_bmbt_reclist(rp, XFS_DFORK_NEXTENTS(dip, whichfork), extmapp);
<br>> }
<br>>
<br>> @@ -448,8 +447,7 @@ scanfunc_bmap(
<br>> return;
<br>> }
<br>> rp = XFS_BMBT_REC_ADDR(mp, block, 1);
<br>> - process_bmbt_reclist((xfs_bmbt_rec_32_t *)rp,
<br>> - nrecs, extmapp);
<br>> + process_bmbt_reclist(rp, nrecs, extmapp);
<br>> return;
<br>> }
<br>>
<br>>
<br>> _______________________________________________
<br>> xfs mailing list
<br>> <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26520617&i=1" target="_top" rel="nofollow">xfs@...</a>
<br>> <a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a></div>---end quoted text---
<br><br>_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26520617&i=2" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26520614Re: XFS quota setup2009-11-25T13:09:22Z2009-11-25T13:09:22ZChristoph HellwigOn Tue, Nov 24, 2009 at 12:03:45PM +0100, Michael Monnerie wrote:
<br>> I took this from the manpage:
<br>> xfs_quota -x -c 'project -s upload' /disks/sharestore/upload/
<br>> xfs_quota: cannot setup path for mount /disks/sharestore/upload/: No
<br>> such device or address
<br>>
<br>> but this works:
<br>> cd /disks/sharestore/
<br>> xfs_quota -x -c 'project -s upload'
<br><br>I can't see these specific paths mentioned in the manpage. The last
<br>argument to xfs_quota should always be a mountpoint, is
<br>/disks/sharestore/upload/ a mountpoint?
<br><br>> Maybe the docs can be simpler? It's confusing now.
<br><br>Suggestions or even better patches are welcome.
<br><br>_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26520614&i=0" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26520613Re: [PATCH] xfstests 213: Add enospc case to fallocate test2009-11-25T13:07:31Z2009-11-25T13:07:31ZChristoph HellwigOn Wed, Nov 25, 2009 at 11:18:47AM -0600, Eric Sandeen wrote:
<br>> Add a test for ENOSPC when fallocating.
<br>>
<br>> Also, add an expected output, not sure how that went missing!
<br><br>Oops. Easily to do because xfstests doesn't complain but rather just
<br>skips tests without golden output..
<br><br>I guess the ENOSPC test is to catch the inverted error returns just
<br>detected?
<br><br>Anyway, looks good,
<br><br><br>Reviewed-by: Christoph Hellwig <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26520613&i=0" target="_top" rel="nofollow">hch@...</a>>
<br><br>_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26520613&i=1" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26520619Re: XFS support for ARMv52009-11-25T13:06:11Z2009-11-25T13:06:11ZChristoph HellwigOn Wed, Nov 25, 2009 at 10:30:09AM -0600, Andy Poling wrote:
<div class='shrinkable-quote'><br>> On Mon, 23 Nov 2009, Ofer Heifetz wrote:
<br>>> Here is the dmesg I got for mount /dev/sda3 /mnt/usb:
<br>>> SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled
<br>>> XFS mounting filesystem sda3
<br>>> Starting XFS recovery on filesystem: sda3 (logdev: internal)
<br>>> XFS: xlog_recover_process_data: bad clientid
<br>>> XFS: log mount/recovery failed: error 5
<br>>> XFS: log mount failed
<br>>
<br>> See this thread in the archives for a patch that may fix this:
<br>>
<br>> <a href="http://oss.sgi.com/pipermail/xfs/2009-October/042805.html" target="_top" rel="nofollow">http://oss.sgi.com/pipermail/xfs/2009-October/042805.html</a></div><br>I don't think it's the case you found, although the symptoms are the
<br>same. I'd rather guess this is a case of an architecture with virtually
<br>indexed caches (can anyone confirm the cache architecture?) which
<br>doesn't cope too well with the way we use vmap to write into a buffer
<br>through virtually mapped linear addresses, but then do block I/O using
<br>the physical addresses of the individual pages. James Bottomley has a
<br>patchset to fix this issue by introducing APIs that allow the
<br>architecture specific memory management to cope with it. He're a
<br>version I could quickly find, although newer ones have been posted
<br>since:
<br><br> <a href="http://thread.gmane.org/gmane.linux.kernel.cross-arch/4364" target="_top" rel="nofollow">http://thread.gmane.org/gmane.linux.kernel.cross-arch/4364</a><br><br>The patchset is planned to get merged into Linux 2.6.33.
<br><br>_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26520619&i=0" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26519770Re: [PATCH] Prevent lookup from finding bad buffers2009-11-25T12:26:19Z2009-11-25T12:26:19ZEric Sandeen-3Lachlan McIlroy wrote:
<div class='shrinkable-quote'><br>> There's a bug in _xfs_buf_find() that will cause it to return buffers
<br>> that failed to be initialised.
<br>>
<br>> If a thread has a buffer locked and is waiting for I/O to initialise
<br>> it and another thread wants the same buffer the second thread will
<br>> wait on the buffer lock in _xfs_buf_find(). If the initial thread
<br>> gets an I/O error it marks the buffer in error and releases the
<br>> buffer lock. The second thread gets the buffer lock, assumes the
<br>> buffer has been successfully initialised, and then tries to use it.
<br>>
<br>> Some callers of xfs_buf_get_flags() will check for B_DONE, and if
<br>> it's not set then re-issue the I/O, bust most callers assume the
<br>> buffer and it's contents are good and then use the uninitialised
<br>> data.
<br>>
<br>> The solution I've come up with is if we lookup a buffer and find
<br>> it's got b_error set or has been marked stale then unhash it from
<br>> the buffer hashtable and retry the lookup. Also if we fail to setup
<br>> the buffer correctly in xfs_buf_get_flags() then mark the buffer in
<br>> error and unhash it. If the buffer is marked stale then in
<br>> xfs_buf_free() inform the page cache that the contents of the pages
<br>> are no longer valid.
</div><br>I managed to come up with a sorta-kinda testcase for this.
<br><br>Fragmented freespace, many files in a dir, on raid5; simply doing
<br>drop caches / ls in a loop triggered it.
<br><br>I guess raid5 is bad in this respect; in it's make_request() we have:
<br><br> } else {
<br> /* cannot get stripe for read-ahead, just give-up */
<br> clear_bit(BIO_UPTODATE, &bi->bi_flags);
<br> finish_wait(&conf->wait_for_overlap, &w);
<br> break;
<br> }
<br><br>and this happens fairly often. This probably explains a large
<br>percentage of our xfs_da_do_buf(2) errors we've seen on the list.
<br><br>From my testing, I think this suffices - and interestingly, Lachlan's
<br>original patch doesn't seem to help...
<br><br>Comments?
<br><br>Maybe could clean up the logic a bit... should this only be
<br>tested for XBF_READ buffers as well ... or maybe an assert that
<br>if !uptodate, error should be set ...
<br><br>diff --git a/fs/xfs/linux-2.6/xfs_buf.c b/fs/xfs/linux-2.6/xfs_buf.c
<br>index 965df12..cbc0541 100644
<br>--- a/fs/xfs/linux-2.6/xfs_buf.c
<br>+++ b/fs/xfs/linux-2.6/xfs_buf.c
<br>@@ -1142,6 +1165,8 @@ xfs_buf_bio_end_io(
<br> if (unlikely(bp->b_error)) {
<br> if (bp->b_flags & XBF_READ)
<br> ClearPageUptodate(page);
<br>+ } else if (!test_bit(BIO_UPTODATE, &bio->bi_flags)) {
<br>+ ClearPageUptodate(bp);
<br> } else if (blocksize >= PAGE_CACHE_SIZE) {
<br> SetPageUptodate(page);
<br> } else if (!PagePrivate(page) &&
<br><br>_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26519770&i=0" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>tag:old.nabble.com,2006:post-26516982[PATCH] xfstests 213: Add enospc case to fallocate test2009-11-25T09:18:47Z2009-11-25T09:18:47ZEric Sandeen-5Add a test for ENOSPC when fallocating.
<br><br>Also, add an expected output, not sure how that went missing!
<br><br>Signed-off-by: Eric Sandeen <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26516982&i=0" target="_top" rel="nofollow">sandeen@...</a>>
<br>---
<br><br>iff --git a/213 b/213
<br>index 3cd55f7..7d66338 100755
<br>--- a/213
<br>+++ b/213
<br>@@ -61,8 +61,6 @@ _require_xfs_io_falloc
<br> avail=`df -P $TEST_DIR | awk 'END {print $4}'`
<br> [ "$avail" -ge 1049600 ] || _notrun "Test device is too small ($avail KiB)"
<br>
<br>-echo Silence is golden
<br>-
<br> # reserve 1GiB, truncate at 100bytes
<br> $XFS_IO_PROG -F -f -c 'falloc 0 1g' -c 'truncate 100' $TEST_DIR/ouch
<br> rm -f $TEST_DIR/ouch
<br>@@ -79,6 +77,14 @@ rm -f $TEST_DIR/ouch
<br> $XFS_IO_PROG -F -f -c 'falloc 0 1g' -c 'falloc 2g 1m' -c 'truncate 3g' $TEST_DIR/ouch
<br> rm -f $TEST_DIR/ouch
<br>
<br>+# Try to reserve more space than we have
<br>+echo "We should get: fallocate: No space left on device"
<br>+echo "Strangely, xfs_io sometimes says \"Success\" when something went wrong, FYI"
<br>+
<br>+let toobig=$avail*2
<br>+$XFS_IO_PROG -F -f -c "falloc 0 ${toobig}k" $TEST_DIR/ouch
<br>+rm -f $TEST_DIR/ouch
<br>+
<br> # success, all done
<br> status=0
<br> exit
<br>diff --git a/213.out b/213.out
<br>new file mode 100644
<br>index 0000000..521fca3
<br>--- /dev/null
<br>+++ b/213.out
<br>@@ -0,0 +1,4 @@
<br>+QA output created by 213
<br>+We should get: fallocate: No space left on device
<br>+Strangely, xfs_io sometimes says "Success" when something went wrong, FYI
<br>+fallocate: No space left on device
<br>diff --git a/group b/group
<br>index b0254dd..8d055a2 100644
<br>--- a/group
<br>+++ b/group
<br>@@ -322,7 +322,7 @@ prealloc
<br> 210 auto aio quick
<br> 211 auto aio quick
<br> 212 auto aio quick
<br>-213 rw auto prealloc quick
<br>+213 rw auto prealloc quick enospc
<br> 214 rw auto prealloc quick
<br> 215 auto metadata quick
<br> 216 log metadata auto quick
<br><br>_______________________________________________
<br>xfs mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26516982&i=1" target="_top" rel="nofollow">xfs@...</a>
<br><a href="http://oss.sgi.com/mailman/listinfo/xfs" target="_top" rel="nofollow">http://oss.sgi.com/mailman/listinfo/xfs</a><br><p>From forum: <a href="http://old.nabble.com/Xfs---General-f1031.html" embed="fixTarget[1031]" target="_top" >Xfs - General</a></p>