Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*XFS\s+unlink\s+still\s+slow\s+on\s+3\.1\.9\s+kernel\s+\?\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*XFS\s+unlink\s+still\s+slow\s+on\s+3\.1\.9\s+kernel\s+\?\s*$/: 31 ]

Total 31 documents matching your query.

1. XFS unlink still slow on 3.1.9 kernel ? (score: 1): Author: Richard Ems <richard.ems@xxxxxxxxxxxxxxxxx>; Date: Mon, 13 Feb 2012 17:57:58 +0100; Hello list ! I ran a "find dir" on one directory with 11 million files and dirs in it and it took 100 minutes. Is this a "normal" run time to be expected? I am running openSUSE 12.1, kernel 3.1.9-1.4; /archives/xfs/2012-02/msg00278.html (9,065 bytes)
2. Re: XFS unlink still slow on 3.1.9 kernel ? (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Mon, 13 Feb 2012 12:08:25 -0500; How many ACLs do you usually have set? If they aren't stored inline but need to go out of the inode unlinks will be extremly slow for kernels before v3.2.; /archives/xfs/2012-02/msg00279.html (8,577 bytes)
3. Re: XFS unlink still slow on 3.1.9 kernel ? (score: 1): Author: Richard Ems <richard.ems@xxxxxxxxxxxxxxxxx>; Date: Mon, 13 Feb 2012 18:11:30 +0100; Almost all dirs and files there do have ACLs set. Each of them do have about 10 user ACLs and 10 default ACls. Is that too many? Is this then the reason for being that slow? Will updating to a kernel; /archives/xfs/2012-02/msg00280.html (9,511 bytes)
4. Re: XFS unlink still slow on 3.1.9 kernel ? (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Mon, 13 Feb 2012 12:15:56 -0500; That doesn't sound like a lot to me, but instead of guessing around, let's just check the actual facts. Does "xfs_bmap -a" for the kind of files you are deleting show any extents? If it doesn't the o; /archives/xfs/2012-02/msg00281.html (9,849 bytes)
5. Re: XFS unlink still slow on 3.1.9 kernel ? (score: 1): Author: Richard Ems <richard.ems@xxxxxxxxxxxxxxxxx>; Date: Mon, 13 Feb 2012 18:26:46 +0100; YES. All files (and dirs) that I checked do show something as 0: [0..7]: 18531216..18531223 So, what improvements can I expect from a kernel > 3.2 ? Can I read somewhere about the changes/patches int; /archives/xfs/2012-02/msg00282.html (10,933 bytes)
6. Re: XFS unlink still slow on 3.1.9 kernel ? (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Mon, 13 Feb 2012 12:29:37 -0500; On some crazy workloads I've seen speedups up to a factor of 10.000 (5 orders or magnitude). You probably won't get that much of a speedup, but it will still be significant. The patch in mainline for; /archives/xfs/2012-02/msg00283.html (10,010 bytes)
7. Re: XFS unlink still slow on 3.1.9 kernel ? (score: 1): Author: Richard Ems <richard.ems@xxxxxxxxxxxxxxxxx>; Date: Mon, 13 Feb 2012 18:53:20 +0100; Ok, Many thanks for this good info! I will try to install a > 3.2 kernel and will create new XFS partitions with "-i size=1024", since we use ACLs a lot for user access. Is there a chance to change e; /archives/xfs/2012-02/msg00286.html (11,239 bytes)
8. Re: XFS unlink still slow on 3.1.9 kernel ? (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Mon, 13 Feb 2012 13:02:20 -0500; Unfortunately not. Note that the speedups in 3.2 only matter for out of line attributes - once you store the ACLs inside the inode the code that makes it dog slow in old kernels is never used.; /archives/xfs/2012-02/msg00288.html (9,781 bytes)
9. Re: XFS unlink still slow on 3.1.9 kernel ? (score: 1): Author: Richard Ems <richard.ems@xxxxxxxxxxxxxxxxx>; Date: Mon, 13 Feb 2012 19:06:44 +0100; Ok, I see, many thanks. So 1. use kernels > 3.2, if XFS partition was not created using "-i size=1024" 2. if XFS partition was created using "-i size=1024", kernels < 3.2 will also be fast while unli; /archives/xfs/2012-02/msg00290.html (10,604 bytes)
10. Re: XFS unlink still slow on 3.1.9 kernel ? (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Mon, 13 Feb 2012 13:10:12 -0500; Yes. Exactly. For workloads like yours creating the large inodes (probably only with 512 byte inodes, though) will be preferably if you have a choice, as it should be even faster.; /archives/xfs/2012-02/msg00292.html (10,099 bytes)
11. Re: XFS unlink still slow on 3.1.9 kernel ? (score: 1): Author: Richard Ems <richard.ems@xxxxxxxxxxxxxxxxx>; Date: Mon, 13 Feb 2012 19:18:47 +0100; Ok, I see. I will do it on all new XFS partitions, since we heavily use ACLs. Many thanks, Richard -- Richard Ems mail: Richard.Ems@xxxxxxxxxxxxxxxxx Cape Horn Engineering S.L. C/ Dr. J.J. Dómine 1,; /archives/xfs/2012-02/msg00294.html (10,603 bytes)
12. Re: XFS unlink still slow on 3.1.9 kernel ? (score: 1): Author: Richard Ems <richard.ems@xxxxxxxxxxxxxxxxx>; Date: Mon, 13 Feb 2012 19:48:58 +0100; I already updated to 3.2.4 and started the same "find dir" command again that previously took 100 min to run. It has been running now for over 30 min ... Should this "find" run time also improve ? Or; /archives/xfs/2012-02/msg00296.html (11,577 bytes)
13. Re: XFS unlink still slow on 3.1.9 kernel ? (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Mon, 13 Feb 2012 16:16:54 -0500; No, not by that change anyway. Yes. I'd have to look into it in more detail. IIRC you said you're using RAID6 which can be fairly nasty for small reads. Did you use the inode64 mount option on the fi; /archives/xfs/2012-02/msg00306.html (10,672 bytes)
14. Re: XFS unlink still slow on 3.1.9 kernel ? (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Tue, 14 Feb 2012 11:09:24 +1100; It certainly can be, depending on the way the directory is fragmented, how sequential the inodes the directory references are how slow the seek time of your disks are. Just to put this in context, a; /archives/xfs/2012-02/msg00314.html (12,282 bytes)
15. Re: XFS unlink still slow on 3.1.9 kernel ? (score: 1): Author: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>; Date: Mon, 13 Feb 2012 23:31:55 -0600; (rw,noatime,nodiratime,attr2,delaylog,nobarrier,logbufs=8,logbsize=256k,sunit=256,swidth=5376,noquota,_netdev) With a 16TB+ XFS, 20TB here, isn't inode64 the default allocator? [...] Does the fact th; /archives/xfs/2012-02/msg00320.html (11,953 bytes)
16. Re: XFS unlink still slow on 3.1.9 kernel ? (score: 1): Author: Richard Ems <richard.ems@xxxxxxxxxxxxxxxxx>; Date: Tue, 14 Feb 2012 10:48:25 +0100; Hi Christoph, hi list, I don;t have ONE dir with that 11 million files, it's one dir with many directories and a total of about 11 million files AND dirs! See output below! It didn't improve, 100 min; /archives/xfs/2012-02/msg00322.html (13,001 bytes)
17. Re: XFS unlink still slow on 3.1.9 kernel ? (score: 1): Author: Richard Ems <richard.ems@xxxxxxxxxxxxxxxxx>; Date: Tue, 14 Feb 2012 10:49:19 +0100; I see no improvement at all. :( -- Richard Ems mail: Richard.Ems@xxxxxxxxxxxxxxxxx Cape Horn Engineering S.L. C/ Dr. J.J. Dómine 1, 5º piso 46011 Valencia Tel : +34 96 3242923 / Fax 924 http://www.ca; /archives/xfs/2012-02/msg00323.html (11,237 bytes)
18. Re: XFS unlink still slow on 3.1.9 kernel ? (score: 1): Author: Richard Ems <richard.ems@xxxxxxxxxxxxxxxxx>; Date: Tue, 14 Feb 2012 11:54:48 +0100; I ran a rm on a smaller dir, containing 9225 dirs and 425659 files and it took ~37 sec on 3.1.9 and ~20 sec on 3.2.4, so I do see a good improvement there. Thanks, Richard -- Richard Ems mail: Richar; /archives/xfs/2012-02/msg00325.html (11,248 bytes)
19. Re: XFS unlink still slow on 3.1.9 kernel ? (score: 1): Author: Richard Ems <richard.ems@xxxxxxxxxxxxxxxxx>; Date: Tue, 14 Feb 2012 12:44:16 +0100; On a second test, removing 37981 directories with 312674 files, again all with ACLs set, went from ~46 sec on 3.1.9 to ~13 sec on 3.2.4, so the improvement is clearly there with 3.2.4 ! Richard -- Ri; /archives/xfs/2012-02/msg00326.html (10,921 bytes)
20. Re: XFS unlink still slow on 3.1.9 kernel ? (score: 1): Author: Richard Ems <richard.ems@xxxxxxxxxxxxxxxxx>; Date: Tue, 14 Feb 2012 13:32:00 +0100; Hi Dave, hi list, first thanks for the very detailed reply. Please find below my comments and questions. Yes, true, I know. But I have no other free space for this backups. I am waiting for a new alr; /archives/xfs/2012-02/msg00327.html (12,504 bytes)

Current List: 1 - 20
Page: [1] [2]