Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\,\s+RFC\]\s+xfs\:\s+batched\s+discard\s+support\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[PATCH\,\s+RFC\]\s+xfs\:\s+batched\s+discard\s+support\s*$/: 27 ]

Total 27 documents matching your query.

1. [PATCH, RFC] xfs: batched discard support (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Sat, 15 Aug 2009 20:47:05 -0400; Given that everyone is so big in the discard discussion I'd like to present what I had started to prepare for XFS. I didn't plan to send it out until I get my hands onto a TRIM capable device (or at; /archives/xfs/2009-08/msg00150.html (18,543 bytes)
2. Re: [PATCH, RFC] xfs: batched discard support (score: 1): Author: Mark Lord <liml@xxxxxx>; Date: Sat, 15 Aug 2009 21:35:17 -0400; Christoph Hellwig wrote: Given that everyone is so big in the discard discussion I'd like to present what I had started to prepare for XFS. I didn't plan to send it out until I get my hands onto a TR; /archives/xfs/2009-08/msg00152.html (9,692 bytes)
3. Re: [PATCH, RFC] xfs: batched discard support (score: 1): Author: Mark Lord <liml@xxxxxx>; Date: Sat, 15 Aug 2009 22:19:21 -0400; Mark Lord wrote: Christoph Hellwig wrote: .. Mark, any chance to try it? Just create an XFS filesystem, age it a bit and then call the attached little trim.c program on the mountmoint (or any file in; /archives/xfs/2009-08/msg00153.html (8,949 bytes)
4. Re: [PATCH, RFC] xfs: batched discard support (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Sat, 15 Aug 2009 22:25:00 -0400; The actual ioctl is compatible, just add the case XFS_IOC_TRIM: return xfs_ioc_trim(mp, arg); to xfs_file_compat_ioctl(). I'll add this to the next spin of the patch.; /archives/xfs/2009-08/msg00155.html (9,047 bytes)
5. Re: [PATCH, RFC] xfs: batched discard support (score: 1): Author: Mark Lord <liml@xxxxxx>; Date: Sat, 15 Aug 2009 22:49:40 -0400; Christoph Hellwig wrote: On Sat, Aug 15, 2009 at 10:19:21PM -0400, Mark Lord wrote: Mark Lord wrote: Christoph Hellwig wrote: .. Mark, any chance to try it? Just create an XFS filesystem, age it a bi; /archives/xfs/2009-08/msg00156.html (9,966 bytes)
6. Re: [PATCH, RFC] xfs: batched discard support (score: 1): Author: Mark Lord <liml@xxxxxx>; Date: Sat, 15 Aug 2009 23:25:29 -0400; Mark Lord wrote: Christoph Hellwig wrote: On Sat, Aug 15, 2009 at 10:19:21PM -0400, Mark Lord wrote: Mark Lord wrote: Christoph Hellwig wrote: .. Mark, any chance to try it? Just create an XFS filesy; /archives/xfs/2009-08/msg00157.html (10,151 bytes)
7. Re: [PATCH, RFC] xfs: batched discard support (score: 1): Author: Mark Lord <liml@xxxxxx>; Date: Sun, 16 Aug 2009 09:00:35 -0400; Christoph Hellwig wrote: On Sat, Aug 15, 2009 at 10:19:21PM -0400, Mark Lord wrote: Mark Lord wrote: Christoph Hellwig wrote: .. Mark, any chance to try it? Just create an XFS filesystem, age it a bi; /archives/xfs/2009-08/msg00158.html (10,851 bytes)
8. Re: [PATCH, RFC] xfs: batched discard support (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Sun, 16 Aug 2009 09:53:15 -0400; ENOSYS or EOPNOTSUPP? Hmm. That was kinda the reason why I didn't want to post stuff yet. In current mainline only MTD implements the prepare_discard_fn, and we'll need it implemented and working. I; /archives/xfs/2009-08/msg00160.html (9,943 bytes)
9. Re: [PATCH, RFC] xfs: batched discard support (score: 1): Author: Mark Lord <liml@xxxxxx>; Date: Sun, 16 Aug 2009 09:59:32 -0400; Mark Lord wrote: Christoph Hellwig wrote: On Sat, Aug 15, 2009 at 10:19:21PM -0400, Mark Lord wrote: Mark Lord wrote: Christoph Hellwig wrote: .. Mark, any chance to try it? Just create an XFS filesy; /archives/xfs/2009-08/msg00161.html (35,368 bytes)
10. Re: [PATCH, RFC] xfs: batched discard support (score: 1): Author: Mark Lord <liml@xxxxxx>; Date: Sun, 16 Aug 2009 10:06:00 -0400; The problem is, it still issues TRIMs to the LLD one extent at a time. Compare this with doing it all in a single TRIM command with the wiper.sh script (filesystem unmounted): [~] time wiper.sh /dev/; /archives/xfs/2009-08/msg00162.html (11,396 bytes)
11. Re: [PATCH, RFC] xfs: batched discard support (score: 1): Author: Mark Lord <liml@xxxxxx>; Date: Sun, 16 Aug 2009 10:26:03 -0400; Christoph Hellwig wrote: On Sun, Aug 16, 2009 at 09:59:32AM -0400, Mark Lord wrote: Okay, I got Matthews patches updated onto 2.6.31, and fixed the incompatibilities between those and the XFS TRIM pa; /archives/xfs/2009-08/msg00163.html (11,121 bytes)
12. Re: [PATCH, RFC] xfs: batched discard support (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Sun, 16 Aug 2009 10:23:31 -0400; I could do a variant which issues a single TRIM, but that would require us to lock out all other allocations for the time the trim takes. I'll hack that up once I get some time.; /archives/xfs/2009-08/msg00164.html (10,321 bytes)
13. Re: [PATCH, RFC] xfs: batched discard support (score: 1): Author: Ingo Molnar <mingo@xxxxxxx>; Date: Wed, 19 Aug 2009 22:39:16 +0200; A general interface design question: you added a new ioctl XFS_IOC_TRIM case. It's a sub-case of an ugly-looking demultiplexing xfs_file_ioctl(). What is your threshold for turning something into a s; /archives/xfs/2009-08/msg00206.html (17,598 bytes)
14. Re: [PATCH, RFC] xfs: batched discard support (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Wed, 19 Aug 2009 21:05:52 -0400; ioctl is per defintion a multiplexer. Only add a syscall if it has _one_ clear defined purpose, which has kernel-wide meaning. Do not add an syscall that is just another multiplexer without structure; /archives/xfs/2009-08/msg00207.html (11,590 bytes)
15. Re: [PATCH, RFC] xfs: batched discard support (score: 1): Author: Jamie Lokier <jamie@xxxxxxxxxxxxx>; Date: Thu, 20 Aug 2009 02:10:04 +0100; One clear defined purpose which comes to mind is a "trim" or "punch" system call, for making holes in files as well as trimming block devices. Several other OSes have that capability on files. I don'; /archives/xfs/2009-08/msg00208.html (10,558 bytes)
16. Re: [PATCH, RFC] xfs: batched discard support (score: 1): Author: Mark Lord <liml@xxxxxx>; Date: Wed, 19 Aug 2009 21:38:27 -0400; No, it doesn't. A drive can optionally support "deterministic TRIM", whereby it will return consistent data for any given trimmed sector afterwards, but that doesn't mean zeros. -ml; /archives/xfs/2009-08/msg00209.html (10,243 bytes)
17. Re: [PATCH, RFC] xfs: batched discard support (score: 1): Author: Douglas Gilbert <dgilbert@xxxxxxxxxxxx>; Date: Wed, 19 Aug 2009 21:38:21 -0400; Jamie Lokier wrote: Christoph Hellwig wrote: So i'm torn about the 'syscall versus ioctl' issue, i'd like to avoid making interface design mistakes and i'd like to solicit some opinions about this. I; /archives/xfs/2009-08/msg00210.html (11,644 bytes)
18. Re: [PATCH, RFC] xfs: batched discard support (score: 1): Author: Mark Lord <liml@xxxxxx>; Date: Wed, 19 Aug 2009 21:39:34 -0400; [resending, after fixing the Cc: list; somebody trimmed it earlier] No, it doesn't. A drive can optionally support "deterministic TRIM", whereby it will return consistent data for any given trimmed s; /archives/xfs/2009-08/msg00211.html (9,681 bytes)
19. Re: [PATCH, RFC] xfs: batched discard support (score: 1): Author: Ric Wheeler <rwheeler@xxxxxxxxxx>; Date: Thu, 20 Aug 2009 09:48:50 -0400; No, it doesn't. A drive can optionally support "deterministic TRIM", whereby it will return consistent data for any given trimmed sector afterwards, but that doesn't mean zeros. -ml Note that returni; /archives/xfs/2009-08/msg00217.html (11,905 bytes)
20. Re: [PATCH, RFC] xfs: batched discard support (score: 1): Author: Mark Lord <liml@xxxxxx>; Date: Thu, 20 Aug 2009 10:38:19 -0400; Note that returning consistent data is critical for devices that are used in a RAID group since you will need each RAID block that is used to compute the parity to continue to return the same data un; /archives/xfs/2009-08/msg00218.html (11,515 bytes)

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