Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*very\s+slow\s+file\s+deletion\s+on\s+an\s+SSD\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*very\s+slow\s+file\s+deletion\s+on\s+an\s+SSD\s*$/: 24 ]

Total 24 documents matching your query.

1. very slow file deletion on an SSD (score: 1): Author: Joe Landman <joe.landman@xxxxxxxxx>; Date: Fri, 25 May 2012 06:37:05 -0400; Hi folks: Just ran into this (see posted output at bottom). 3.2.14 kernel, MD RAID 5, xfs file system. Not sure (precisely) where the problem is, hence posting to both lists. [root@siFlash ~]# cat /p; /archives/xfs/2012-05/msg00332.html (16,577 bytes)
2. Re: very slow file deletion on an SSD (score: 1): Author: Bernd Schubert <bernd.schubert@xxxxxxxxxxx>; Date: Fri, 25 May 2012 12:45:38 +0200; Hello Joe, Just ran into this (see posted output at bottom). 3.2.14 kernel, MD RAID 5, xfs file system. Not sure (precisely) where the problem is, hence posting to both lists. do you have anything en; /archives/xfs/2012-05/msg00337.html (7,851 bytes)
3. Re: very slow file deletion on an SSD (score: 1): Author: Joe Landman <joe.landman@xxxxxxxxx>; Date: Fri, 25 May 2012 06:49:20 -0400; Just ran into this (see posted output at bottom). 3.2.14 kernel, MD RAID 5, xfs file system. Not sure (precisely) where the problem is, hence posting to both lists. do you have anything enabled, that; /archives/xfs/2012-05/msg00338.html (9,157 bytes)
4. Re: very slow file deletion on an SSD (score: 1): Author: Roberto Spadim <roberto@xxxxxxxxxxxxx>; Date: Fri, 25 May 2012 11:48:01 -0300; noop scheduler could be better for ssd? 2012/5/25 Joe Landman <joe.landman@xxxxxxxxx>: -- Roberto Spadim Spadim Technology / SPAEmpresarial; /archives/xfs/2012-05/msg00342.html (10,970 bytes)
5. Re: very slow file deletion on an SSD (score: 1): Author: Ben Myers <bpm@xxxxxxx>; Date: Fri, 25 May 2012 11:57:19 -0500; Hey Joe, There are a couple recent fixes related to discard that are probably appropriate for 3.2-stable. xfs: fix endian conversion issue in discard code When finding the longest extent in an AG, we; /archives/xfs/2012-05/msg00347.html (19,934 bytes)
6. Re: very slow file deletion on an SSD (score: 1): Author: Joe Landman <joe.landman@xxxxxxxxx>; Date: Fri, 25 May 2012 12:54:43 -0400; [...] There are a couple recent fixes related to discard that are probably appropriate for 3.2-stable. [...] I'm not saying that they'll fix your problem, but you should consider giving them a whirl.; /archives/xfs/2012-05/msg00348.html (10,025 bytes)
7. Re: very slow file deletion on an SSD (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Fri, 25 May 2012 12:59:38 -0400; Discard is not enabled by default.; /archives/xfs/2012-05/msg00349.html (8,124 bytes)
8. Re: very slow file deletion on an SSD (score: 1): Author: David Brown <david.brown@xxxxxxxxxxxx>; Date: Sat, 26 May 2012 18:00:12 +0200; On 25/05/12 18:59, Christoph Hellwig wrote: On Fri, May 25, 2012 at 11:57:19AM -0500, Ben Myers wrote: There are a couple recent fixes related to discard that are probably appropriate for 3.2-stable.; /archives/xfs/2012-05/msg00353.html (9,004 bytes)
9. Re: very slow file deletion on an SSD (score: 1): Author: Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>; Date: Sat, 26 May 2012 14:56:54 -0500; Hi Joe, I may be all wet here, but this is the only thing that jumped out at me: 8*56KB (or 7*64KB) = 448KB write out 7*32KB = 224KB stripe size Other than your XFS writeout being apparently twice th; /archives/xfs/2012-05/msg00354.html (9,370 bytes)
10. Re: very slow file deletion on an SSD (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Sun, 27 May 2012 09:18:38 +1000; But you haven't followed my advice when it comes to using default mkfs options, have you? You're running 2k inodes and 64k directory block size, which is not exactly a common config The question is,; /archives/xfs/2012-05/msg00355.html (10,786 bytes)
11. Re: very slow file deletion on an SSD (score: 1): Author: Joe Landman <joe.landman@xxxxxxxxx>; Date: Sat, 26 May 2012 19:25:55 -0400; Just ran into this (see posted output at bottom). 3.2.14 kernel, MD RAID 5, xfs file system. Not sure (precisely) where the problem is, hence posting to both lists. [root@siFlash ~]# cat /proc/mdstat; /archives/xfs/2012-05/msg00356.html (15,084 bytes)
12. Re: very slow file deletion on an SSD (score: 1): Author: Joe Landman <joe.landman@xxxxxxxxx>; Date: Sat, 26 May 2012 19:55:17 -0400; Sounds like you might be hitting the synchronous xattr removal problem that was recently fixed (as has been mentioned already), but even so 2 IOs don't take 1-2s to do, unless the MD RAID5 barrier i; /archives/xfs/2012-05/msg00357.html (15,293 bytes)
13. Re: very slow file deletion on an SSD (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Sun, 27 May 2012 10:07:01 +1000; It's burning an awful lot of CPU time during this remove. So, 48 files were removed, it was basically CPU bound and one took 2.6 seconds. So, how big are the files, and does the one that took 2.6s ha; /archives/xfs/2012-05/msg00358.html (10,223 bytes)
14. Re: very slow file deletion on an SSD (score: 1): Author: joe.landman@xxxxxxxxx; Date: Sat, 26 May 2012 20:10:45 -0400; Ok. Will do in a few hours Sent from my iPad; /archives/xfs/2012-05/msg00359.html (11,619 bytes)
15. Re: very slow file deletion on an SSD (score: 1): Author: Joe Landman <joe.landman@xxxxxxxxx>; Date: Sat, 26 May 2012 21:49:57 -0400; On 05/26/2012 08:07 PM, Dave Chinner wrote: On Sat, May 26, 2012 at 07:25:55PM -0400, Joe Landman wrote: [root@siFlash test]# ls -alF | wc -l 59 [root@siFlash test]# /usr/bin/time rm -f * ^C0.00user; /archives/xfs/2012-05/msg00360.html (15,121 bytes)
16. Re: very slow file deletion on an SSD (score: 1): Author: Eric Sandeen <sandeen@xxxxxxxxxxx>; Date: Sat, 26 May 2012 21:40:08 -0500; ... <snip> Try filefrag -v maybe, if your e2fsprogs is new enough. Trying to remember, ENOMEM in bmap rings a bell... but this is possibly indicative of an extremely fragmented file. -Eric; /archives/xfs/2012-05/msg00361.html (11,280 bytes)
17. Re: very slow file deletion on an SSD (score: 1): Author: Eric Sandeen <sandeen@xxxxxxxxxxx>; Date: Sat, 26 May 2012 21:43:22 -0500; Ah. f074211f xfs: fallback to vmalloc for large buffers in xfs_getbmap fixed it in 3.4 -Eric; /archives/xfs/2012-05/msg00362.html (11,407 bytes)
18. Re: very slow file deletion on an SSD (score: 1): Author: Stefan Ring <stefanrin@xxxxxxxxx>; Date: Sun, 27 May 2012 09:34:46 +0200; True, I've had it happen with extremely fragmented files. I've started playing around with discard myself only recently, but so far I like the approach of using fstrim a lot better than the discard; /archives/xfs/2012-05/msg00363.html (10,634 bytes)
19. Re: very slow file deletion on an SSD (score: 1): Author: Krzysztof Adamski <k@xxxxxxxxxxx>; Date: Sun, 27 May 2012 09:15:04 -0400; Check what blockdev --getra <md device> is set to. I used to have a several second deletes on large (4GB) fragmented files when ra was the default 256. Once I changed it to 4096 (best value will depe; /archives/xfs/2012-05/msg00365.html (11,120 bytes)
20. Re: very slow file deletion on an SSD (score: 1): Author: joe.landman@xxxxxxxxx; Date: Sun, 27 May 2012 10:59:52 -0400; This is going to be a very fragmented file. I am guessing that this is the reason for the long duration delete. I'll do some more measurements before going to 3.4.x as per Eric's note. Sent from my i; /archives/xfs/2012-05/msg00366.html (12,413 bytes)

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