Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Fragmentation\s+Issue\s+We\s+Are\s+Having\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*Fragmentation\s+Issue\s+We\s+Are\s+Having\s*$/: 15 ]

Total 15 documents matching your query.

1. Fragmentation Issue We Are Having (score: 1): Author: David Fuller <dfuller@xxxxxxxxx>; Date: Wed, 11 Apr 2012 18:04:25 -0700; We seen to be having an issue whereby our database server gets to 90% or higher fragmentation. When it gets to this point we would need to remove form production and defrag using the xfs_fsr tool.; /archives/xfs/2012-04/msg00723.html (9,580 bytes)
2. Re: Fragmentation Issue We Are Having (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Thu, 12 Apr 2012 12:16:26 +1000; Bad assumption. They have no effect on filesystem fragmentation. Read this first: http://xfs.org/index.php/XFS_FAQ#Q:_The_xfs_db_.22frag.22_command_says_I.27m_over_50.25.__Is_that_bad.3F Then decide; /archives/xfs/2012-04/msg00725.html (9,427 bytes)
3. Re: Fragmentation Issue We Are Having (score: 1): Author: David Fuller <dfuller@xxxxxxxxx>; Date: Wed, 11 Apr 2012 19:55:50 -0700; Dave, Thanks so much for that informative read. This helps me fight my case that systematic defrags are not needed and are bad for the system in general. After reading this I did do some checks agai; /archives/xfs/2012-04/msg00726.html (12,187 bytes)
4. Re: Fragmentation Issue We Are Having (score: 1): Author: Eric Sandeen <sandeen@xxxxxxxxxxx>; Date: Wed, 11 Apr 2012 23:24:53 -0500; I've also added a visual aid to that faq entry to show how quickly the frag factor approaches 100% :) -Eric; /archives/xfs/2012-04/msg00728.html (11,894 bytes)
5. Re: Fragmentation Issue We Are Having (score: 1): Author: Brian Candler <B.Candler@xxxxxxxxx>; Date: Thu, 12 Apr 2012 08:57:47 +0100; What's the total file system size? If it's over 1TB then you almost certainly should have 'inode64' as well. http://xfs.org/index.php/XFS_FAQ#Q:_What_is_the_inode64_mount_option_for.3F; /archives/xfs/2012-04/msg00729.html (8,923 bytes)
6. Re: Fragmentation Issue We Are Having (score: 1): Author: David Fuller <dfuller@xxxxxxxxx>; Date: Thu, 12 Apr 2012 17:09:40 -0700; Brian, The total LVM volume group is 4.5 TB. The logical volume is around 2.3TB where the mysql data is stored. --David F. What's the total file system size? If it's over 1TB then you almost certain; /archives/xfs/2012-04/msg00737.html (10,444 bytes)
7. Re: Fragmentation Issue We Are Having (score: 1): Author: Brian Candler <B.Candler@xxxxxxxxx>; Date: Fri, 13 Apr 2012 08:19:05 +0100; Hence you have a 2.3TB XFS filesystem? You need inode64. The side warning "performance sucks" is very true. In particular, if you create a bunch of files in the same directory, without inode64 XFS wi; /archives/xfs/2012-04/msg00739.html (9,837 bytes)
8. Re: Fragmentation Issue We Are Having (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Fri, 13 Apr 2012 17:56:34 +1000; In some cases. You can't just blindly assert that something is needed purely on the size of the filesystem. Much more information is needed such as block maps, which files the database regularly uses; /archives/xfs/2012-04/msg00741.html (10,840 bytes)
9. Re: Fragmentation Issue We Are Having (score: 1): Author: Brian Candler <B.Candler@xxxxxxxxx>; Date: Fri, 13 Apr 2012 09:17:25 +0100; Thanks, but then perhaps the XFS FAQ needs updating. It warns that you might have compatibility problems with old clients (NFS) and inode64, but it doesn't say "for some workloads inode32 may perform; /archives/xfs/2012-04/msg00742.html (10,995 bytes)
10. Re: Fragmentation Issue We Are Having (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Tue, 17 Apr 2012 10:26:10 +1000; The FAQ doesn't say anything about whether inode32 performs better than inode64 or vice versa. All it talks about is inode allocation locality and possible errors (like ENOSPC with lots of free space; /archives/xfs/2012-04/msg00839.html (12,135 bytes)
11. Re: Fragmentation Issue We Are Having (score: 1): Author: Brian Candler <B.Candler@xxxxxxxxx>; Date: Tue, 17 Apr 2012 09:58:28 +0100; With respect it does, although in only three words: "Also, performance sucks". Maybe it would be useful to expand this. How about: "Also, performance sucks for many common workloads and benchmarks, s; /archives/xfs/2012-04/msg00849.html (11,661 bytes)
12. Re: Fragmentation Issue We Are Having (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Wed, 18 Apr 2012 11:36:07 +1000; I missed that. It's a pretty useless comment. Even that generalisation is often wrong. It assumes that separation of metadata and data causes performance degradation, which is not a valid assumption; /archives/xfs/2012-04/msg00865.html (13,459 bytes)
13. Re: Fragmentation Issue We Are Having (score: 1): Author: Brian Candler <B.Candler@xxxxxxxxx>; Date: Wed, 18 Apr 2012 10:00:51 +0100; Ah, that's new to me. So with inode32 and sysctl fs.xfs.rotorstep=255 you can get roughly the same locality benefit for sequentially-written files as inode64? (Aside: if you have two processes writin; /archives/xfs/2012-04/msg00870.html (12,771 bytes)
14. Re: Fragmentation Issue We Are Having (score: 1): Author: Richard Scobie <richard@xxxxxxxxxxx>; Date: Fri, 20 Apr 2012 07:54:50 +1200; -- Ah, that's new to me. So with inode32 and sysctl fs.xfs.rotorstep=255 you can get roughly the same locality benefit for sequentially-written files as inode64? (Aside: if you have two processes wri; /archives/xfs/2012-04/msg00888.html (8,730 bytes)
15. Re: Fragmentation Issue We Are Having (score: 1): Author: Dave Chinner <david@xxxxxxxxxxxxx>; Date: Fri, 20 Apr 2012 09:12:58 +1000; As Richard pointed out, the filestreams allocator was designed specifically to avoid this problem (mainly for file-per-frame realtima, concurrent e ingest/playout of multiple 2k and 4k HD uncompresse; /archives/xfs/2012-04/msg00893.html (13,845 bytes)

Current List: 1 - 15
Page: [1]