Re: [PATCH] Btrfs: Do not use data_alloc_cluster in ssd mode

2017-07-26 Thread David Sterba
On Mon, Jul 24, 2017 at 02:53:52PM -0400, Chris Mason wrote: > On 07/24/2017 02:41 PM, David Sterba wrote: > > On Mon, Jul 24, 2017 at 02:01:07PM -0400, Chris Mason wrote: > >> On 07/24/2017 10:25 AM, David Sterba wrote: > >> > >>> Thanks for the extensive historical summary, this change really

Re: [PATCH] Btrfs: Do not use data_alloc_cluster in ssd mode

2017-07-24 Thread Hans van Kranenburg
Hi Chris, On 07/24/2017 08:53 PM, Chris Mason wrote: > On 07/24/2017 02:41 PM, David Sterba wrote: >> On Mon, Jul 24, 2017 at 02:01:07PM -0400, Chris Mason wrote: >>> On 07/24/2017 10:25 AM, David Sterba wrote: >>> Thanks for the extensive historical summary, this change really deserves

Re: [PATCH] Btrfs: Do not use data_alloc_cluster in ssd mode

2017-07-24 Thread Chris Mason
On 07/24/2017 03:06 PM, Austin S. Hemmelgarn wrote: On 2017-07-24 14:53, Chris Mason wrote: On 07/24/2017 02:41 PM, David Sterba wrote: would it be ok for you to keep ssd_working as before? I'd really like to get this patch merged soon because "do not use ssd mode for ssd" has started to be

Re: [PATCH] Btrfs: Do not use data_alloc_cluster in ssd mode

2017-07-24 Thread Austin S. Hemmelgarn
On 2017-07-24 14:53, Chris Mason wrote: On 07/24/2017 02:41 PM, David Sterba wrote: would it be ok for you to keep ssd_working as before? I'd really like to get this patch merged soon because "do not use ssd mode for ssd" has started to be the recommended workaround. Once this sticks, we

Re: [PATCH] Btrfs: Do not use data_alloc_cluster in ssd mode

2017-07-24 Thread Chris Mason
On 07/24/2017 02:41 PM, David Sterba wrote: On Mon, Jul 24, 2017 at 02:01:07PM -0400, Chris Mason wrote: On 07/24/2017 10:25 AM, David Sterba wrote: Thanks for the extensive historical summary, this change really deserves it. Decoupling the assumptions about the device's block management

Re: [PATCH] Btrfs: Do not use data_alloc_cluster in ssd mode

2017-07-24 Thread David Sterba
On Mon, Jul 24, 2017 at 02:01:07PM -0400, Chris Mason wrote: > On 07/24/2017 10:25 AM, David Sterba wrote: > > > Thanks for the extensive historical summary, this change really deserves > > it. > > > > Decoupling the assumptions about the device's block management is really > > a good thing,

Re: [PATCH] Btrfs: Do not use data_alloc_cluster in ssd mode

2017-07-24 Thread Chris Mason
On 07/24/2017 10:25 AM, David Sterba wrote: Thanks for the extensive historical summary, this change really deserves it. Decoupling the assumptions about the device's block management is really a good thing, mount option 'ssd' should mean that the device just has cheap seeks. Moving the the

Re: [PATCH] Btrfs: Do not use data_alloc_cluster in ssd mode

2017-07-24 Thread Hans van Kranenburg
On 07/24/2017 07:52 PM, David Sterba wrote: > On Mon, Jul 24, 2017 at 07:22:03PM +0200, Hans van Kranenburg wrote: >> On 07/24/2017 04:25 PM, David Sterba wrote: >>> On Fri, Jul 21, 2017 at 01:47:11PM +0200, Hans van Kranenburg wrote: [...] So what now...? The changes

Re: [PATCH] Btrfs: Do not use data_alloc_cluster in ssd mode

2017-07-24 Thread David Sterba
On Mon, Jul 24, 2017 at 07:22:03PM +0200, Hans van Kranenburg wrote: > On 07/24/2017 04:25 PM, David Sterba wrote: > > On Fri, Jul 21, 2017 at 01:47:11PM +0200, Hans van Kranenburg wrote: > >> [...] > >> > >> So what now...? > >> > >> The changes in here do the following: > >> > >> 1. Throw

Re: [PATCH] Btrfs: Do not use data_alloc_cluster in ssd mode

2017-07-24 Thread Hans van Kranenburg
On 07/24/2017 04:25 PM, David Sterba wrote: > On Fri, Jul 21, 2017 at 01:47:11PM +0200, Hans van Kranenburg wrote: >> [...] >> >> So what now...? >> >> The changes in here do the following: >> >> 1. Throw out the current ssd_spread behaviour. >> 2. Move the current ssd behaviour to the

Re: [PATCH] Btrfs: Do not use data_alloc_cluster in ssd mode

2017-07-24 Thread David Sterba
On Fri, Jul 21, 2017 at 01:47:11PM +0200, Hans van Kranenburg wrote: > In the first year of btrfs development, around early 2008, btrfs > gained a mount option which enables specific functionality for > filesystems on solid state devices. The first occurance of this > functionality is in

Re: [PATCH] Btrfs: Do not use data_alloc_cluster in ssd mode

2017-07-24 Thread Austin S. Hemmelgarn
On 2017-07-21 19:21, Hans van Kranenburg wrote: > On 07/21/2017 05:50 PM, Austin S. Hemmelgarn wrote: >> On 2017-07-21 07:47, Hans van Kranenburg wrote: >>> [...] >>> >>> Signed-off-by: Hans van Kranenburg >> Behaves as advertised, and I'm not seeing any issues in

Re: [PATCH] Btrfs: Do not use data_alloc_cluster in ssd mode

2017-07-21 Thread Hans van Kranenburg
On 07/21/2017 05:50 PM, Austin S. Hemmelgarn wrote: > On 2017-07-21 07:47, Hans van Kranenburg wrote: >> [...] >> >> Signed-off-by: Hans van Kranenburg > Behaves as advertised, and I'm not seeing any issues in my testing (and > I can confirm from experience that

Re: [PATCH] Btrfs: Do not use data_alloc_cluster in ssd mode

2017-07-21 Thread Austin S. Hemmelgarn
On 2017-07-21 07:47, Hans van Kranenburg wrote: In the first year of btrfs development, around early 2008, btrfs gained a mount option which enables specific functionality for filesystems on solid state devices. The first occurance of this functionality is in commit e18e4809, labeled "Add

Re: [PATCH] Btrfs: Do not use data_alloc_cluster in ssd mode

2017-07-21 Thread Hans van Kranenburg
On 07/21/2017 04:49 PM, Adam Borowski wrote: > On Fri, Jul 21, 2017 at 01:47:11PM +0200, Hans van Kranenburg wrote: >> The changes in here do the following: >> >> 1. Throw out the current ssd_spread behaviour. >> 2. Move the current ssd behaviour to the ssd_spread option. >> 3. Make ssd mode data

Re: [PATCH] Btrfs: Do not use data_alloc_cluster in ssd mode

2017-07-21 Thread Adam Borowski
On Fri, Jul 21, 2017 at 01:47:11PM +0200, Hans van Kranenburg wrote: > The changes in here do the following: > > 1. Throw out the current ssd_spread behaviour. > 2. Move the current ssd behaviour to the ssd_spread option. > 3. Make ssd mode data allocation identical to tetris mode, like nossd. >