Search String: Display: Description: Sort:

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)


This search system is powered by Namazu