Re: [btrfs tools] ability to fail a device...

On 9 September 2015 at 09:07, Ian Kumlien wrote: > On 9 September 2015 at 03:35, Anand Jain wrote: > > There is a patch set to handle this.. > > 'Btrfs: introduce function to handle device offline' > > I'll have a look So from my very quick

Re: [PATCH v1 9/8] copy_file_range.2: New page documenting copy_file_range()

On Tue, Sep 08, 2015 at 01:39:18PM -0700, Darrick J. Wong wrote: > > >> +The file descriptors must not refer to the same file. > > > > > > Why? btrfs (and XFS) reflink can handle the case of a file sharing blocks > > > with itself. > > > > I've never really thought about it... Zach had that in

Re: [PATCH v1 4/8] btrfs: Add mountpoint checking during btrfs_copy_file_range

On Fri, Sep 04, 2015 at 04:16:58PM -0400, Anna Schumaker wrote: > We need to verify that both the source and the destination files are > part of the same filesystem, otherwise we can't create a reflink. > > Signed-off-by: Anna Schumaker > --- > fs/btrfs/ioctl.c | 4

Re: [btrfs tools] ability to fail a device...

On 9 September 2015 at 03:35, Anand Jain wrote: > On 09/09/2015 03:34 AM, Hugo Mills wrote: >> >> On Tue, Sep 08, 2015 at 09:18:05PM +0200, Ian Kumlien wrote: >>> >>> Hi, >>> >>> Currently i have a raid1 configuration on two disks where one of them >>> is failing. >>> >>>

Re: [PATCH v1 3/8] btrfs: add .copy_file_range file operation

On Fri, Sep 04, 2015 at 04:16:57PM -0400, Anna Schumaker wrote: > From: Zach Brown > > This rearranges the existing COPY_RANGE ioctl implementation so that the > .copy_file_range file operation can call the core loop that copies file > data extent items. > > The extent copying

[PATCH 3/5] btrfs: convert: force convert to used mixed block group

Convert has a bug that even we disable it from using mixed block, it will still put data and metadata extent into the same chunk. The bug can be reported by previous fsck patch. Even without the bug, it's still high recommeneded to use mixed block group, as unlike btrfs, ext* is not extent based

[PATCH 1/5] btrfs-progs: fsck: Add check for extent and parent chunk type

There is a bug in btrfs-convert in 4.1.2, even we don't allow mixed block group for converted image, btrfs-convert will still create image with data and metadata inside one chunk. And further more, the chunk type is still DATA or METADATA, not DATA|METADATA (not mixed). So add btrfsck check for

[PATCH 2/5] btrfs: utils: Check nodesize against features

Check nodesize against features, not only sectorsize. In fact, one of the btrfs-convert and mkfs differs in the nodesize check. This patch also provides the basis for later btrfs-convert fix. Signed-off-by: Qu Wenruo --- btrfs-convert.c | 2 +- mkfs.c | 16

[PATCH 4/5] btrfs: util: add parameter for btrfs_list_all_fs_features

Even we tried to make mkfs and btrfs-convert use the same features, but previous patch forced btrfs-convert to use mix-bg feature. So the default fs features is different for mkfs and btrfs-convert, add mask_default parameter for btrfs_list_all_fs_features() to handle the difference.

[PATCH 0/4] Fix for btrfs-convert chunk type and fsck support

Again the buggy btrfs-convert, even David tried to ban mixed-bg features for btrfs-convert, it will still put data and metadata extents into the same chunk, without marking the chunk mixed. So in the patchset, first add fsck support for such problem, and then force btrfs-convert to use mixed

RE: [PATCH 3/3] btrfs-progs: tests: Introduce misc-tests/008-leaf-accross-stripes

Hi, Qu Wenruo > -Original Message- > From: Qu Wenruo [mailto:quwen...@cn.fujitsu.com] > Sent: Wednesday, September 09, 2015 9:46 AM > To: Zhao Lei ; linux-btrfs@vger.kernel.org > Subject: Re: [PATCH 3/3] btrfs-progs: tests: Introduce >

Re: mkfs.btrfs cannot find rotational file for SSD detection for a pmem device

On 2015-09-08 16:00, Elliott, Robert (Persistent Memory) wrote: -Original Message- From: Austin S Hemmelgarn [mailto:ahferro...@gmail.com] Sent: Tuesday, September 8, 2015 7:56 AM Subject: Re: mkfs.btrfs cannot find rotational file for SSD detection for a pmem device On 2015-09-06

Re: mkfs.btrfs cannot find rotational file for SSD detection for a pmem device

On 09/09/2015 02:28 PM, Austin S Hemmelgarn wrote: > On 2015-09-08 16:00, Elliott, Robert (Persistent Memory) wrote: <> > this may actually make things slower (the particular effect of SSD mode > is that it tries to spread allocations out as much as possible, as this > helps with wear-leveling

Re: Btrfs progs release 4.1

sorry for side question - but does this mean that btrfs-convert issues others were having on kernel 4.0+ on this mailing list is now addressed ? On Wed, Sep 9, 2015 at 4:24 AM, Qu Wenruo wrote: > > > Qu Wenruo wrote on 2015/09/09 09:34 +0800: >> >> Hi David, >> >> Sorry

Re: Btrfs progs release 4.1

Vytautas D posted on Wed, 09 Sep 2015 11:35:50 +0100 as excerpted: > sorry for side question - but does this mean that btrfs-convert issues > others were having on kernel 4.0+ on this mailing list is now addressed > ? AFAIK they've not yet been entirely fixed, no. There's still active (within

Re: [PATCH v1 9/8] copy_file_range.2: New page documenting copy_file_range()

On 2015-09-08 16:39, Darrick J. Wong wrote: On Tue, Sep 08, 2015 at 11:04:03AM -0400, Anna Schumaker wrote: On 09/04/2015 05:38 PM, Darrick J. Wong wrote: On Fri, Sep 04, 2015 at 04:17:03PM -0400, Anna Schumaker wrote: copy_file_range() is a new system call for copying ranges of data

Re: [PATCH v2 9/9] Btrfs: add free space tree mount option

On Thu, Sep 03, 2015 at 12:44:27PM -0700, Omar Sandoval wrote: > Now we can finally hook up everything so we can actually use free space > tree. On the first mount with the free_space_tree mount option, the free > space tree will be created and the FREE_SPACE_TREE read-only compat bit > will be

Re: mkfs.btrfs cannot find rotational file for SSD detection for a pmem device

On 09/09/2015 03:40 PM, Austin S Hemmelgarn wrote: > On 2015-09-09 08:12, Boaz Harrosh wrote: >> On 09/09/2015 02:28 PM, Austin S Hemmelgarn wrote: >>> On 2015-09-08 16:00, Elliott, Robert (Persistent Memory) wrote: >> <> >> >>> this may actually make things slower (the particular effect of SSD

Re: Btrfs progs release 4.1

On Wed, Sep 09, 2015 at 11:24:17AM +0800, Qu Wenruo wrote: > The problem is that, for converted image, it's quite possible that data > and metadata extent are stored in one chunk even the chunk is not mixed. > > I'll add fsck support for it soon. That would be great, I have no idea how the

Re: Btrfs progs release 4.1

On Wed, Sep 09, 2015 at 09:34:53AM +0800, Qu Wenruo wrote: > > David Sterba (79): > >btrfs-progs: tests: log the test name in results file > >btrfs-progs: tests: support more formats of test images > >btrfs-progs: tests: use readlink -f to resolve path > >

Re: Btrfs progs release 4.1

On Wed, Sep 09, 2015 at 11:35:50AM +0100, Vytautas D wrote: > sorry for side question - but does this mean that btrfs-convert issues > others were having on kernel 4.0+ on this mailing list is now > addressed ? Per Qu's analysis yes, the broken versions are 3.19.1-4.0.1. -- To unsubscribe from

Re: Btrfs progs release 4.1

On 2015-09-09 09:25, David Sterba wrote: On Wed, Sep 09, 2015 at 11:24:17AM +0800, Qu Wenruo wrote: The problem is that, for converted image, it's quite possible that data and metadata extent are stored in one chunk even the chunk is not mixed. I'll add fsck support for it soon. That would

Re: mkfs.btrfs cannot find rotational file for SSD detection for a pmem device

On 2015-09-09 08:12, Boaz Harrosh wrote: On 09/09/2015 02:28 PM, Austin S Hemmelgarn wrote: On 2015-09-08 16:00, Elliott, Robert (Persistent Memory) wrote: <> this may actually make things slower (the particular effect of SSD mode is that it tries to spread allocations out as much as

[PATCH 1/3] btrfs-progs: Fix infinite loop of btrfs-image

Bug: # btrfs-image -t0 -c9 /dev/sda6 /tmp/btrfs_image.img (hang) # btrfs-image -r -t0 /tmp/btrfs_image.img /dev/sda6 (hang) Reason: Program need to create at least 1 thread for compress/decompress. but if user specify -t0 in argument, it overwrite the default value of 1, then the program

[PATCH 3/3] btrfs-progs: close all_devices for btrfs-image

devices opened by check_mounted() in main() should close before exit of btrfs-image. Signed-off-by: Zhao Lei --- btrfs-image.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/btrfs-image.c b/btrfs-image.c index c7681f4..78ae828 100644 --- a/btrfs-image.c +++

[PATCH 2/3] btrfs-progs: don't create no-used threads in btrfs-image

In case of creating image without compess, we don't need to create many no-used compress threads. Signed-off-by: Zhao Lei --- btrfs-image.c | 13 - 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/btrfs-image.c b/btrfs-image.c index

Re: [PATCH v1 4/8] btrfs: Add mountpoint checking during btrfs_copy_file_range

On 09/09/2015 05:18 AM, David Sterba wrote: > On Fri, Sep 04, 2015 at 04:16:58PM -0400, Anna Schumaker wrote: >> We need to verify that both the source and the destination files are >> part of the same filesystem, otherwise we can't create a reflink. >> >> Signed-off-by: Anna Schumaker

Re: [PATCH 0/2] btrfs: fortification for GFP_NOFS allocations

On 08/19/2015 08:17 PM, Chris Mason wrote: On Wed, Aug 19, 2015 at 02:17:39PM +0200, mho...@kernel.org wrote: Hi, these two patches were sent as a part of a larger RFC which aims at allowing GFP_NOFS allocations to fail to help sort out memory reclaim issues bound to the current behavior

Re: [PATCH 0/3] btrfs-progs: Avoid uninitialized data in output of btrfs-convert

On Tue, Sep 08, 2015 at 09:16:48PM +0800, Zhao Lei wrote: > sequence, transid and reserved field of inode was write to disk > with uninitizlized value, this patchset fixed it, also fixed some > other typo. > > Zhao Lei (3): > btrfs-progs: fix set_get typo of btrfs_inode_item->sequence >

Unmountable btrfs after power failure

I recently had a power failure, and ever since I have been unable to mount one of my btrfs drives (data is the one that is failing to mount, store is fine). I’m running: jkeane@bet:~$ uname -a Linux bet 3.8.0-33-generic #48-Ubuntu SMP Wed Oct 23 09:16:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Re: raid6 + hot spare question

Things can be a little more nuanced. First off, I'm not even sure btrfs supports a hot spare currently. I haven't seen anything along those lines recently in the list - and don't recall anything along those lines before either. The current mention of it in the Project Ideas page on the wiki

kernel 4.2.0, bogus 'no space left on device' with 'btrfs delete missing' raid5

bogus 'no space left on device' with 'btrfs delete missing' raid5 https://bugzilla.kernel.org/show_bug.cgi?id=104361 Summary: 4x 8GB virtual disks in raid5 with 3.62GiB data, no snapshots or subvolumes or reflinks; fail one of the devices; reboot; btrfs dev delete missing fails with 'no space

Re: raid6 + hot spare question

On Wed, Sep 9, 2015 at 9:48 AM, Brendan Hide wrote: > Things can be a little more nuanced. > > First off, I'm not even sure btrfs supports a hot spare currently. I haven't > seen anything along those lines recently in the list - and don't recall > anything along those

Re: raid6 + hot spare question

Brendan Hide posted on Wed, 09 Sep 2015 17:48:11 +0200 as excerpted: > Things can be a little more nuanced. > > First off, I'm not even sure btrfs supports a hot spare currently. I > haven't seen anything along those lines recently in the list - and don't > recall anything along those lines

Re: Btrfs progs release 4.1

David Sterba wrote on 2015/09/09 15:25 +0200: On Wed, Sep 09, 2015 at 11:24:17AM +0800, Qu Wenruo wrote: The problem is that, for converted image, it's quite possible that data and metadata extent are stored in one chunk even the chunk is not mixed. I'll add fsck support for it soon. That

Contact Us For Unsecured Guaranteed Loans Today!!!?

Do you need a genuine Loan to settle your bills and start up a good business? Kindly contact us now with your details to get a good Loan at a low rate of 3% per Annu, Quick send your details via: guarloa...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the

Cancel device remove?

Hi, Is there some way to cancel a device remove operation? I have discovered that if I reboot that will cancel it, but that's not always possible. What I'm after is something the same as cancelling scrub. I keep running into situations where I want to pause a remove operation for speed

[PATCH 0/4] Fix for btrfs-convert chunk type and fsck support

Again the buggy btrfs-convert, even David tried to ban mixed-bg features for btrfs-convert, it will still put data and metadata extents into the same chunk, without marking the chunk mixed. So in the patchset, first add fsck support for such problem, and then force btrfs-convert to use mixed

[PATCH v2 2/5] btrfs-progs: utils: Check nodesize against features

Check nodesize against features, not only sectorsize. In fact, one of the btrfs-convert and mkfs differs in the nodesize check. This patch also provides the basis for later btrfs-convert fix. Signed-off-by: Qu Wenruo --- btrfs-convert.c | 2 +- mkfs.c | 16

[PATCH v2 4/5] btrfs-progs: util: add parameter for btrfs_list_all_fs_features

Even we tried to make mkfs and btrfs-convert use the same features, but previous patch forced btrfs-convert to use mix-bg feature. So the default fs features is different for mkfs and btrfs-convert, add mask_default parameter for btrfs_list_all_fs_features() to handle the difference.

[PATCH v2 1/5] btrfs-progs: fsck: Add check for extent and parent chunk type

There is a bug in btrfs-convert in 4.1.2, even we don't allow mixed block group for converted image, btrfs-convert will still create image with data and metadata inside one chunk. And further more, the chunk type is still DATA or METADATA, not DATA|METADATA (not mixed). So add btrfsck check for

[PATCH v2 3/5] btrfs-progs: convert: force convert to used mixed block group

Convert has a bug that even we disable it from using mixed block, it will still put data and metadata extent into the same chunk. The bug can be reported by previous fsck patch. Even without the bug, it's still high recommeneded to use mixed block group, as unlike btrfs, ext* is not extent based

[PATCH v2 5/5] btrfs-progs: convert-test: Disable different nodesize test

As now btrfs-convert is forced to used mixed block group, only test pagesize as nodesize for convert. Signed-off-by: Qu Wenruo --- tests/convert-tests.sh | 36 +--- 1 file changed, 21 insertions(+), 15 deletions(-) diff --git

Re: [PATCH v1 0/8] VFS: In-kernel copy system call

On 09/08/2015 06:39 PM, Darrick J. Wong wrote: > On Tue, Sep 08, 2015 at 02:45:39PM -0700, Andy Lutomirski wrote: >> On Tue, Sep 8, 2015 at 2:29 PM, Darrick J. Wong >> wrote: >>> On Tue, Sep 08, 2015 at 09:03:09PM +0100, Pádraig Brady wrote: On 08/09/15 20:10, Andy

Re: [PATCH v1 0/8] VFS: In-kernel copy system call

On Wed, Sep 9, 2015 at 4:09 PM, Chris Mason wrote: > On Tue, Sep 08, 2015 at 04:08:43PM -0700, Andy Lutomirski wrote: >> On Tue, Sep 8, 2015 at 3:39 PM, Darrick J. Wong >> wrote: >> > On Tue, Sep 08, 2015 at 02:45:39PM -0700, Andy Lutomirski wrote: >> >>

Re: [PATCH v1 0/8] VFS: In-kernel copy system call

On Wed, Sep 9, 2015 at 1:09 PM, Chris Mason wrote: > On Tue, Sep 08, 2015 at 04:08:43PM -0700, Andy Lutomirski wrote: >> On Tue, Sep 8, 2015 at 3:39 PM, Darrick J. Wong >> wrote: >> > On Tue, Sep 08, 2015 at 02:45:39PM -0700, Andy Lutomirski wrote: >> >>

Re: [PATCH v1 0/8] VFS: In-kernel copy system call

On Wed, Sep 09, 2015 at 04:26:58PM -0400, Trond Myklebust wrote: > On Wed, Sep 9, 2015 at 4:09 PM, Chris Mason wrote: > > On Tue, Sep 08, 2015 at 04:08:43PM -0700, Andy Lutomirski wrote: > >> On Tue, Sep 8, 2015 at 3:39 PM, Darrick J. Wong > >> wrote: > >>

Re: [PATCH v1 0/8] VFS: In-kernel copy system call

On 09/09/2015 04:38 PM, Chris Mason wrote: > On Wed, Sep 09, 2015 at 04:26:58PM -0400, Trond Myklebust wrote: >> On Wed, Sep 9, 2015 at 4:09 PM, Chris Mason wrote: >>> On Tue, Sep 08, 2015 at 04:08:43PM -0700, Andy Lutomirski wrote: On Tue, Sep 8, 2015 at 3:39 PM, Darrick J.

Re: [PATCH v1 0/8] VFS: In-kernel copy system call

On Wed, Sep 09, 2015 at 01:37:44PM -0700, Andy Lutomirski wrote: > On Wed, Sep 9, 2015 at 1:09 PM, Chris Mason wrote: > > On Tue, Sep 08, 2015 at 04:08:43PM -0700, Andy Lutomirski wrote: > >> On Tue, Sep 8, 2015 at 3:39 PM, Darrick J. Wong > >> wrote: > >>

Re: [PATCH v1 9/8] copy_file_range.2: New page documenting copy_file_range()

On Wed, Sep 09, 2015 at 07:38:14AM -0400, Austin S Hemmelgarn wrote: > On 2015-09-08 16:39, Darrick J. Wong wrote: > >On Tue, Sep 08, 2015 at 11:04:03AM -0400, Anna Schumaker wrote: > >>On 09/04/2015 05:38 PM, Darrick J. Wong wrote: > >>>On Fri, Sep 04, 2015 at 04:17:03PM -0400, Anna Schumaker

Re: [PATCH v1 9/8] copy_file_range.2: New page documenting copy_file_range()

On 09/09/2015 01:17 PM, Darrick J. Wong wrote: > On Wed, Sep 09, 2015 at 07:38:14AM -0400, Austin S Hemmelgarn wrote: >> On 2015-09-08 16:39, Darrick J. Wong wrote: >>> On Tue, Sep 08, 2015 at 11:04:03AM -0400, Anna Schumaker wrote: On 09/04/2015 05:38 PM, Darrick J. Wong wrote: > On Fri,

Re: Unmountable btrfs after power failure

uOn Wed, Sep 09, 2015 at 10:30:33AM -0500, Jon Keane wrote: > I recently had a power failure, and ever since I have been unable to > mount one of my btrfs drives (data is the one that is failing to > mount, store is fine). I’m running: > > jkeane@bet:~$ uname -a > > Linux bet 3.8.0-33-generic

Re: Unmountable btrfs after power failure

On Wed, 9 Sep 2015 17:19:51 + Hugo Mills wrote: >The bug you've hit is almost certainly fixed in more recent > kernels. I can't recommend stongly enough that you upgrade it (or > contact your vendor's support department to find out how they will > support your use of

Re: [PATCH v1 9/8] copy_file_range.2: New page documenting copy_file_range()

On Wed, Sep 09, 2015 at 01:31:24PM -0400, Anna Schumaker wrote: > On 09/09/2015 01:17 PM, Darrick J. Wong wrote: > > On Wed, Sep 09, 2015 at 07:38:14AM -0400, Austin S Hemmelgarn wrote: > >> On 2015-09-08 16:39, Darrick J. Wong wrote: > >>> On Tue, Sep 08, 2015 at 11:04:03AM -0400, Anna Schumaker

Re: [PATCH v1 0/8] VFS: In-kernel copy system call

On Tue, Sep 08, 2015 at 04:08:43PM -0700, Andy Lutomirski wrote: > On Tue, Sep 8, 2015 at 3:39 PM, Darrick J. Wong > wrote: > > On Tue, Sep 08, 2015 at 02:45:39PM -0700, Andy Lutomirski wrote: > >> What I meant by this was: if you ask for "regular copy", you may end > >>

Re: [PATCH v1 9/8] copy_file_range.2: New page documenting copy_file_range()

On 09/09/2015 02:12 PM, Darrick J. Wong wrote: > On Wed, Sep 09, 2015 at 01:31:24PM -0400, Anna Schumaker wrote: >> On 09/09/2015 01:17 PM, Darrick J. Wong wrote: >>> On Wed, Sep 09, 2015 at 07:38:14AM -0400, Austin S Hemmelgarn wrote: On 2015-09-08 16:39, Darrick J. Wong wrote: > On Tue,

Re: [PATCH v1 0/8] VFS: In-kernel copy system call

On Wed, Sep 09, 2015 at 02:52:08PM -0400, Anna Schumaker wrote: > On 09/08/2015 06:39 PM, Darrick J. Wong wrote: > > On Tue, Sep 08, 2015 at 02:45:39PM -0700, Andy Lutomirski wrote: > >> On Tue, Sep 8, 2015 at 2:29 PM, Darrick J. Wong > >> wrote: > >>> On Tue, Sep 08,

Re: Unmountable btrfs after power failure

Thank you all for the quick response! For anyone running into similar issues: I updated my kernel, and then ran btrfs-zero-log. Everything worked fine, and the drive is mountable with no issues so far. -Jon On Wed, Sep 9, 2015 at 12:27 PM, Roman Mamedov wrote: > On Wed, 9

Re: [PATCH v1 0/8] VFS: In-kernel copy system call

On Wed, Sep 09, 2015 at 04:41:34PM -0400, Anna Schumaker wrote: > On 09/09/2015 04:38 PM, Chris Mason wrote: > > On Wed, Sep 09, 2015 at 04:26:58PM -0400, Trond Myklebust wrote: > >> On Wed, Sep 9, 2015 at 4:09 PM, Chris Mason wrote: > >>> On Tue, Sep 08, 2015 at 04:08:43PM -0700,