On Sun, Jul 17, 2016 at 03:51:03PM -0500, Mike Christie wrote:
> >
> > diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
> > index a69203a..6ee1e36 100644
> > --- a/fs/btrfs/volumes.c
> > +++ b/fs/btrfs/volumes.c
> > @@ -5533,7 +5533,7 @@ static int __btrfs_map_block(struct btrfs_fs_info
> > *
At 07/16/2016 07:17 PM, John Ettedgui wrote:
On Thu, Jul 14, 2016 at 10:54 PM John Ettedgui mailto:john.etted...@gmail.com>> wrote:
On Thu, Jul 14, 2016 at 10:26 PM Qu Wenruo mailto:quwen...@cn.fujitsu.com>> wrote:
> Would increasing the leaf size help as well?
> nodatac
On Mon, Jul 18, 2016 at 12:13:38AM +0200, Adam Borowski wrote:
> Instead of checking the mode of the file descriptor, let's check whether it
> could have been opened rw. This allows fixing intermittent exec failures
> when deduping a live system: anyone trying to exec a file currently being
> dedu
Instead of checking the mode of the file descriptor, let's check whether it
could have been opened rw. This allows fixing intermittent exec failures
when deduping a live system: anyone trying to exec a file currently being
deduped gets ETXTBSY.
Issuing this ioctl on a ro file was already allowed
Am 17.07.2016 um 22:10 schrieb Henk Slager:
> What kernel (version) did you use ?
> I hope it included:
> http://git.kernel.org/cgit/linux/kernel/git/mkp/linux.git/commit/?h=bugzilla-93581&id=7c4fbd50bfece00abf529bc96ac989dd2bb83ca4
>
> so >= 4.4, as without this patch, it is quite problematic, if
On 07/15/2016 10:03 AM, Vincent Stehlé wrote:
> Add missing comparison to op in expression, which was forgotten when doing
> the REQ_OP transition.
>
> Fixes: b3d3fa519905 ("btrfs: update __btrfs_map_block for REQ_OP transition")
> Signed-off-by: Vincent Stehlé
> Cc: Mike Christie
> Cc: Jens Axb
>>> It's a Seagate Expansion Desktop 5TB (USB3). It is probably a
>>> ST5000DM000.
>>
>>
>> this is TGMR not SMR disk:
>>
>> http://www.seagate.com/www-content/product-content/desktop-hdd-fam/en-us/docs/100743772a.pdf
>> So it still confirms to standard record strategy ...
>
>
> I am not convinced.
On Sun, Jul 17, 2016 at 10:26 AM, Matthias Prager
wrote:
> from my experience btrfs does work as badly with SMR drives (I only had
> the opportunity to test on a 8TB Seagate device-managed drive) as ext4.
> The initial performance is fine (for a few gigabytes / minutes), but
> drops of a cliff as
On Sat, Jul 16, 2016 at 06:51:11PM +0300, Jarkko Lavinen wrote:
> The modified script behaves very much like the original dd version.
Not quite. The bad sector simulation works like old hard drives without error
correction and bad block remapping. This changes the error behaviour.
My script pri
On Friday, July 15, 2016 12:15:15 PM Omar Sandoval wrote:
> On Fri, Jul 15, 2016 at 12:34:10PM +0530, Chandan Rajendra wrote:
> > On Thursday, July 14, 2016 07:47:04 PM Chris Mason wrote:
> > > On 07/14/2016 07:31 PM, Omar Sandoval wrote:
> > > > From: Omar Sandoval
> > > >
> > > > So it turns out
Hi Thomasz,
@Dave I have added you to the conversation, as I refer to your notes
(https://github.com/kdave/drafts/blob/master/btrfs/smr-mode.txt)
thanks for your reply!
It's a Seagate Expansion Desktop 5TB (USB3). It is probably a ST5000DM000.
this is TGMR not SMR disk:
http://www.seagate.
Hello Hendrik,
from my experience btrfs does work as badly with SMR drives (I only had
the opportunity to test on a 8TB Seagate device-managed drive) as ext4.
The initial performance is fine (for a few gigabytes / minutes), but
drops of a cliff as soon as the internal buffer-region for
non-sequent
12 matches
Mail list logo