Re: question re: trim in btrfs

2016-10-18 Thread Jeff Mahoney
On 10/18/16 3:06 PM, Tim Walberg wrote:
> Forgot to mention - this was on a rather crusty 4.2.6 kernel. Just upgraded 
> to 4.8.1
> and the issue appears to have been resolved...

Thanks for following up.  This issue was actually fixed in v4.3.  There
were a bunch of fixes for discard ranging from correct(ish[1]) reporting
of bytes discarded, discarding ranges in freed block groups, and missing
discards when using -odiscard.

-Jeff

[1] We report the range for which we issue discards.  We don't track if
a particular range has been previously discarded.

> On 10/18/2016 12:42 -0500, Walberg, Tim wrote:
>>> Unless I'm misinterpreting something it appears that maybe btrfs 
>>> doesn't pass
>>> fstrim commands down to the underlying drives when being used in a 
>>> RAID-1 config.
>>> 
>>> I have this output from a small script I wrote to run at boot time (and 
>>> also via
>>> cron.weekly), rather than using continous trim in the boot options:
>>> 
>>> # cat /var/log/trim.log
>>> Thu Oct 13 07:40:07 CDT 2016
>>> /boot: 454 MiB (476062720 bytes) trimmed
>>> 
>>> Thu Oct 13 07:40:08 CDT 2016
>>> /: 8.9 GiB (9585152000 bytes) trimmed
>>> 
>>> Thu Oct 13 07:40:22 CDT 2016
>>> /btrfs/0: 0 B (0 bytes) trimmed
>>> 
>>> /boot and / are mdraid RAID 1 on partitions 1 and 3 of two Samsung 850 
>>> Pro SSDs.
>>> /btrfs/0 is a btrfs-raid RAID 1 of partition 4 on the same two drives. 
>>> The btrfs
>>> case does not seem to accomplish anything. By comparison, I have the 
>>> same drive
>>> in my laptop, but just a single one, and the non-btrfs-raid-1 file 
>>> system on one
>>> of its partitions does run fstrim successfully.
>>> 
>>> This is quite possibly a known limitation, but I didn't find anything 
>>> about it
>>> through some quick searching. Maybe I didn't dive deep enough...
>>> 
>>> -- 
>>> twalb...@gmail.com, twalb...@comcast.net
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" 
>>> in
>>> the body of a message to majord...@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> End of included message
> 
> 
> 


-- 
Jeff Mahoney
SUSE Labs



signature.asc
Description: OpenPGP digital signature


Re: question re: trim in btrfs

2016-10-18 Thread Tim Walberg
Forgot to mention - this was on a rather crusty 4.2.6 kernel. Just upgraded to 
4.8.1
and the issue appears to have been resolved...

On 10/18/2016 12:42 -0500, Walberg, Tim wrote:
>>  Unless I'm misinterpreting something it appears that maybe btrfs 
>> doesn't pass
>>  fstrim commands down to the underlying drives when being used in a 
>> RAID-1 config.
>>  
>>  I have this output from a small script I wrote to run at boot time (and 
>> also via
>>  cron.weekly), rather than using continous trim in the boot options:
>>  
>>  # cat /var/log/trim.log
>>  Thu Oct 13 07:40:07 CDT 2016
>>  /boot: 454 MiB (476062720 bytes) trimmed
>>  
>>  Thu Oct 13 07:40:08 CDT 2016
>>  /: 8.9 GiB (9585152000 bytes) trimmed
>>  
>>  Thu Oct 13 07:40:22 CDT 2016
>>  /btrfs/0: 0 B (0 bytes) trimmed
>>  
>>  /boot and / are mdraid RAID 1 on partitions 1 and 3 of two Samsung 850 
>> Pro SSDs.
>>  /btrfs/0 is a btrfs-raid RAID 1 of partition 4 on the same two drives. 
>> The btrfs
>>  case does not seem to accomplish anything. By comparison, I have the 
>> same drive
>>  in my laptop, but just a single one, and the non-btrfs-raid-1 file 
>> system on one
>>  of its partitions does run fstrim successfully.
>>  
>>  This is quite possibly a known limitation, but I didn't find anything 
>> about it
>>  through some quick searching. Maybe I didn't dive deep enough...
>>  
>>  -- 
>>  twalb...@gmail.com, twalb...@comcast.net
>>  --
>>  To unsubscribe from this list: send the line "unsubscribe linux-btrfs" 
>> in
>>  the body of a message to majord...@vger.kernel.org
>>  More majordomo info at  http://vger.kernel.org/majordomo-info.html
End of included message



-- 
twalb...@gmail.com, twalb...@comcast.net
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html