RAID10 can accept as much as half of its disks to be missing, as long as
each sub stripe still has a good mirror.
Thanks to the per-chunk degradable check, we can handle it pretty easily
now.
So Add this special check for RAID10, to allow user to be creative
(or crazy) using btrfs RAID10.
Signed
[BUG]
The following script can easily cause unexpected ENOSPC:
umount $dev &> /dev/null
umount $mnt &> /dev/null
mkfs.btrfs -b 1G -m single -d single $dev -f > /dev/null
mount $dev $mnt -o enospc_debug
for i in $(seq -w 0 511); do
xfs_io -f -c "pwrite 0 1m" $mnt/inline_$i > /de
On Wed, Jul 17, 2019 at 05:37:06PM +0200, David Sterba wrote:
> > This entire patch because of BTRFS maintainers, they didn't want the
> > explicit
> > casts. Maybe something has been changed, I dunno.
>
> No change on our side. The uuids are u8 in the on-disk structures, that
> will stay. The uu
Hi, (I'm not subscribed).
In btrfs-progs-v5.2 (and -v5.1.1, don't know about older versions), when
there is already balancing operation, then
btrfs balance status /path
reports its status. (OK)
But, there is no balancing operation, then it starts the balancing,
instead of reporting some "stat
On 17.07.19 г. 20:39 ч., Andrei Borzenkov wrote:
> 17.07.2019 14:19, Nikolay Borisov пишет:
>>
>> This is really odd... So this indeed seems to be a userspace problem.
>
>
> Of course it is user space problem.
>
> commit 0a0a03554aaf56a6e7245e74fa7d8b3c53f1c20f
> Author: Misono Tomohiro
> D
17.07.2019 14:19, Nikolay Borisov пишет:
>
> This is really odd... So this indeed seems to be a userspace problem.
Of course it is user space problem.
commit 0a0a03554aaf56a6e7245e74fa7d8b3c53f1c20f
Author: Misono Tomohiro
Date: Fri Mar 23 17:16:49 2018 +0900
btrfs-progs: mkfs: add uui
I lifted the btrfs label get/set ioctls to the vfs some time ago, but
never followed up to use those common definitions directly in btrfs.
This patch does that.
Signed-off-by: Eric Sandeen
---
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 56ae2f659b6d..65aeb418aa9d 100644
--- a/fs/btrf
On Wed, Jul 17, 2019 at 05:37:06PM +0200, David Sterba wrote:
> On Tue, Jul 16, 2019 at 06:22:22PM +0300, Andy Shevchenko wrote:
> > On Tue, Jul 16, 2019 at 05:11:33PM +0200, Christoph Hellwig wrote:
> > > On Tue, Jul 16, 2019 at 06:04:16PM +0300, Andy Shevchenko wrote:
> > > I hate this raw namin
On Tue, Jul 16, 2019 at 06:22:22PM +0300, Andy Shevchenko wrote:
> On Tue, Jul 16, 2019 at 05:11:33PM +0200, Christoph Hellwig wrote:
> > On Tue, Jul 16, 2019 at 06:04:16PM +0300, Andy Shevchenko wrote:
> > > +static inline void guid_copy_from_raw(guid_t *dst, const __u8 *src)
> > > +{
> > > + memc
On Tue, Jul 02, 2019 at 10:15:21PM +0800, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> fs/btrfs/volumes.c: In function __btrfs_map_block:
> fs/btrfs/volumes.c:6023:6: warning:
> variable offset set but not used [-Wunused-but-set-variable]
>
> It is not used any more sin
On Mon, Jul 15, 2019 at 03:16:12PM +0200, Johannes Thumshirn wrote:
> btrfs_get_io_geometry() calls btrfs_get_chunk_map() to acquire a reference
> on a extent_map, but on normal operation it does not drop this reference
> anymore.
>
> This leads to excessive kmemleak reports.
>
> Always call free
On Thu, Jul 11, 2019 at 05:23:04PM +0200, Johannes Thumshirn wrote:
> fs_info::csum_hash gets initialized in btrfs_init_csum_hash() which is
> called by open_ctree().
>
> But it only gets freed if open_ctree() fails, not on normal operation.
>
> This leads to a memory leak like the following foun
On Tue, Jul 16, 2019 at 03:40:56PM +0200, Johannes Thumshirn wrote:
> On Tue, Jul 16, 2019 at 04:29:27PM +0300, Andy Shevchenko wrote:
> > On Tue, Jul 16, 2019 at 4:28 PM Andy Shevchenko
> > wrote:
> > >
> > > The following commit broke compilation
> > >
> > > commit d5178578bcd461cc79118c7a139882
On Mon, Jul 08, 2019 at 06:43:23AM -0700, Guenter Roeck wrote:
> With CONFIG_BTRFS_FS=y and CONFIG_CRYPTO_CRC32C=m, we get:
>
> fs/btrfs/super.o: In function `btrfs_mount_root':
> fs/btrfs/super.c:1557: undefined reference to `crc32c_impl'
> fs/btrfs/super.o: In function `btrfs_print_mod_info':
>
On Fri, Jul 12, 2019 at 11:21:38AM +0200, Johannes Thumshirn wrote:
> On Fri, Jul 12, 2019 at 03:34:45PM +0800, Qu Wenruo wrote:
> > Not yet in upstream, thus I believe David could just fold this fix into
> > the original commit.
>
> Right, I just didn't know if David's gonna rebase his branch be
My name is Mr. Allen, I have a Business Proposal of Four million five hundred
thousand united states dollars for you to handle with me from my bank. I will
need you to assist me in executing this Business .
It's unlikely in-band dedupe is going to land so just remove any
leftovers - dedupe.h header as well as the 'dedupe' parameter to
btrfs_set_extent_delalloc.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/ctree.h | 2 +-
fs/btrfs/dedupe.h| 12
fs/btrfs/file.c
It was added in ba8b04c1d4ad ("btrfs: extend btrfs_set_extent_delalloc
and its friends to support in-band dedupe and subpage size patchset") as
a preparatory patch for in-band and subapge block size patchsets.
However neither of those are likely to be merged anytime soon and the
code has diverged s
From: Filipe Manana
Test that an incremental send operation works after deduplicating into the
same file in both the parent and send snapshots.
This currently fails on btrfs and a kernel patch to fix it was submitted
with the subject:
Btrfs: fix incremental send failure after deduplication
S
From: Filipe Manana
When doing an incremental send operation we can fail if we previously did
deduplication operations against a file that exists in both snapshots. In
that case we will fail the send operation with -EIO and print a message
to dmesg/syslog like the following:
BTRFS error (devic
This label is only executed if compress_file_range fails to create an
inline extent. So move its code in the semantically related inline
extent handling branch. No functional changes.
Signed-off-by: Nikolay Borisov
---
fs/btrfs/inode.c | 18 --
1 file changed, 8 insertions(+), 10
compress_file_range returns a void, yet uses a function parameter as a
return value. Make that more idiomatic by simply returning the number
of compressed extents directly. Also track such extents in more aptly
named variables. No functional changes
Signed-off-by: Nikolay Borisov
---
fs/btrfs/in
uuid_le_gen() is no used anymore, remove it for good.
Signed-off-by: Andy Shevchenko
---
include/linux/uuid.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/uuid.h b/include/linux/uuid.h
index 3780460a9a85..d41b0d3e9474 100644
--- a/include/linux/uuid.h
+++ b/include/linux/uuid
Sometimes we may need to import UUID from or export to the raw buffer,
which is provided outside of kernel and can't be declared as UUID type.
With current API this operation will require an explicit casting
to one of UUID types and length, that is always a constant derived as sizeof
the certain UU
There are new types and helpers that are supposed to be used in new code.
As a preparation to get rid of legacy types and API functions do
the conversion here.
Signed-off-by: Andy Shevchenko
---
fs/btrfs/disk-io.c | 6 +++---
fs/btrfs/ioctl.c | 4 +---
fs/btrfs/root-tree.c | 4 +---
In some cases we would like to generate a GUID and export it.
Though it would require either casting to internal kernel types or
an intermediate buffer. Instead we may achieve this by supplying
a pointer to raw buffer and make a complimentary API to existing one
for UUIDs.
Signed-off-by: Andy Shev
On 17.07.19 г. 13:29 ч., Andrei Borzenkov wrote:
> On Wed, Jul 17, 2019 at 1:14 PM Nikolay Borisov wrote:
>>
>>
>>
>> On 17.07.19 г. 12:11 ч., Ulli Horlacher wrote:
>>> On Wed 2019-07-17 (11:24), Nikolay Borisov wrote:
On 17.07.19 3. 2:24 G., Ulli Horlacher wrote:
> I th
On 2019-07-17 3:45 a.m., Bernhard Kühnel wrote:
>
> I believe the usual practice is to create snapshots with the -r flag and
> follow some naming convention (e.g. place them in a common .snapshots
> folder named by date), but you're free to switch between read-only and
> read-write mode for a sna
On Wed, Jul 17, 2019 at 1:14 PM Nikolay Borisov wrote:
>
>
>
> On 17.07.19 г. 12:11 ч., Ulli Horlacher wrote:
> > On Wed 2019-07-17 (11:24), Nikolay Borisov wrote:
> >>
> >>
> >> On 17.07.19 3. 2:24 G., Ulli Horlacher wrote:
> >>
> >>> I thought, I can recognize a snapshot when it has a Parent UUI
On 17.07.19 г. 12:11 ч., Ulli Horlacher wrote:
> On Wed 2019-07-17 (11:24), Nikolay Borisov wrote:
>>
>>
>> On 17.07.19 3. 2:24 G., Ulli Horlacher wrote:
>>
>>> I thought, I can recognize a snapshot when it has a Parent UUID, but this
>>> is not true for snapshots of toplevel subvolumes:
>>
>>
> -Original Message-
> From: linux-btrfs-ow...@vger.kernel.org
> [mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Ulli Horlacher
> Sent: Wednesday, July 17, 2019 6:07 PM
> To: linux-btrfs@vger.kernel.org
> Subject: Re: how do I know a subvolume is a snapshot?
>
> On Wed 2019-07-17
On Wed 2019-07-17 (11:24), Nikolay Borisov wrote:
>
>
> On 17.07.19 3. 2:24 G., Ulli Horlacher wrote:
>
> > I thought, I can recognize a snapshot when it has a Parent UUID, but this
> > is not true for snapshots of toplevel subvolumes:
>
> As you have asked this before - in my testing this is
On Wed 2019-07-17 (08:57), misono.tomoh...@fujitsu.com wrote:
> FYI, this problem should be fixed in mkfs.btrfs >= v4.16 since the top-level
> subvolume also gets non-empty UUID at mkfs time.
root@fex:~# lsb_release -d
Description:Ubuntu 18.04.2 LTS
root@fex:~# btrfs version
btrfs-progs v4.1
> -Original Message-
> From: linux-btrfs-ow...@vger.kernel.org
> [mailto:linux-btrfs-ow...@vger.kernel.org] On Behalf Of Hans van Kranenburg
> Sent: Wednesday, July 17, 2019 5:24 PM
> To: linux-btrfs@vger.kernel.org; Ulli Horlacher
>
> Subject: Re: how do I know a subvolume is a snapshot
Hi friends,
*Description:*
One LTP testcase, fs_fill.c, fails on btrfs with kernel error when
unlink files on Btrfs device:
"BTRFS warning (device loop0): could not allocate space for a
delete; will truncate on mount".
I found the loop block device formatted with btrfs roughl
On 17.07.19 г. 2:24 ч., Ulli Horlacher wrote:
> I thought, I can recognize a snapshot when it has a Parent UUID, but this
> is not true for snapshots of toplevel subvolumes:
As you have asked this before - in my testing this is not true. Looking
at the code it also seems snapshots get a parent
Hi,
On 7/17/19 1:24 AM, Ulli Horlacher wrote:
>
> I thought, I can recognize a snapshot when it has a Parent UUID, but this
> is not true for snapshots of toplevel subvolumes:
>
> root@trulla:/# btrfs version
> btrfs-progs v4.5.3+20160729
>
> root@trulla:/# btrfs subvolume show /mnt/tmp
> /mnt
On Wed 2019-07-17 (09:45), Bernhard Kühnel wrote:
> Am 17.07.2019 um 01:24 schrieb Ulli Horlacher:
>
> > How do I know that /mnt/tmp/ss is a snapshot?
> > I cannot see a snapshot identifier.
>
> From the btrfs-subvolume man page:
>
> > A snapshot is a subvolume like any other, with given i
Am 17.07.2019 um 01:24 schrieb Ulli Horlacher:
> How do I know that /mnt/tmp/ss is a snapshot?
> I cannot see a snapshot identifier.
>From the btrfs-subvolume man page:
> A snapshot is a subvolume like any other, with given initial
content. By default, snapshots are created
> read-wri
39 matches
Mail list logo
