Did you already try this?? [1]:
btrfs fi balance start -dusage=5 /mnt/nas3
Cheers, dan
[1]
https://btrfs.wiki.kernel.org/index.php/Problem_FAQ#I_get_.22No_space_left_on_device.22_errors.2C_but_df_says_I.27ve_got_lots_of_space
On Sun, Feb 16, 2014 at 2:58 PM, Goswin von Brederlow wrote:
> H
On Sun, Feb 16, 2014 at 09:08:57PM +, Filipe David Manana wrote:
> I'll see if I come up with other ways of getting into that issue.
If you're collecting them, I found another bug, although it might not
matter to most: if I put my laptop in S3 sleep during a send/receive, it
reliably breaks th
PTR_RET is deprecated. Use PTR_ERR_OR_ZERO instead. While at it
also include missing err.h header.
Signed-off-by: Sachin Kamat
---
fs/btrfs/root-tree.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/root-tree.c b/fs/btrfs/root-tree.c
index 1389b69059de..38bb47e
Chris Murphy posted on Sun, 16 Feb 2014 12:54:44 -0700 as excerpted:
> On Feb 16, 2014, at 12:18 PM, Hendrik Friedel
> wrote:
[On balance converting to single from raidN:]
>> I think it didn't work.
>>
>> btrfs balance start -dconvert=single -mconvert=single -sconvert=single
>> --force /mnt/B
On Tue, Feb 11, 2014 at 08:01:08PM +0100, Koen De Wit wrote:
> On 02/10/2014 11:04 PM, Dave Chinner wrote:
> >On Mon, Feb 10, 2014 at 10:39:22PM +0100, Koen De Wit wrote:
> >>+
> >>+_test_illegal_leafsize() {
> >>+_scratch_mkfs -l $1 >>$seqres.full 2>&1
> >>+[ $? -ne 0 ] || _fail "'
On Mon, Feb 17, 2014 at 01:36:02AM +, Filipe David Manana wrote:
> On Monday, February 17, 2014, Dave Chinner wrote:
>
> > On Mon, Feb 17, 2014 at 12:20:38AM +, Filipe David Borba Manana wrote:
> > > Test for a btrfs incremental send issue where we end up sending a
> > > wrong section of
On Mon, Feb 17, 2014 at 1:19 AM, Dave Chinner wrote:
> On Mon, Feb 17, 2014 at 12:20:38AM +, Filipe David Borba Manana wrote:
>> Test for a btrfs incremental send issue where we end up sending a
>> wrong section of data from a file extent if the corresponding file
>> extent is compressed and t
On Mon, Feb 17, 2014 at 1:17 AM, Dave Chinner wrote:
> On Sun, Feb 16, 2014 at 11:43:17PM +, Filipe David Manana wrote:
>> On Sun, Feb 16, 2014 at 11:08 PM, Dave Chinner wrote:
>> > On Sat, Feb 15, 2014 at 03:36:13PM +, Filipe David Borba Manana wrote:
>> >> Test for a btrfs incremental s
On Fri, 2014-02-14 at 18:30 +0100, David Sterba wrote:
> On Thu, Feb 13, 2014 at 11:16:38AM +0800, Gui Hecheng wrote:
> > @@ -6460,6 +6460,7 @@ int cmd_check(int argc, char **argv)
> > !extent_buffer_uptodate(info->dev_root->node) ||
> > !extent_buffer_uptodate(info->chunk_root->nod
On Mon, Feb 17, 2014 at 12:20:38AM +, Filipe David Borba Manana wrote:
> Test for a btrfs incremental send issue where we end up sending a
> wrong section of data from a file extent if the corresponding file
> extent is compressed and the respective file extent item has a non
> zero data offset
On Sun, Feb 16, 2014 at 11:43:17PM +, Filipe David Manana wrote:
> On Sun, Feb 16, 2014 at 11:08 PM, Dave Chinner wrote:
> > On Sat, Feb 15, 2014 at 03:36:13PM +, Filipe David Borba Manana wrote:
> >> Test for a btrfs incremental send issue where we end up sending a
> >> wrong section of d
Test for a btrfs data corruption when using compressed files/extents.
Under certain cases, it was possible for reads to return random data
(content from a previously used page) instead of zeroes. This also
caused partial updates to those regions that were supposed to be filled
with zeroes to save r
Regression test for btrfs incremental send issue where an rmdir
instruction was sent multiple times for the same target directory.
The number of times depended on the number of hardlinks against
the same inode inside the target directory. That inode must have
had the highest number of all the inode
Regression test for a btrfs incremental send issue related to renaming of
directories. If at the time of the initial send we have a directory that is
a child of a directory with a higher inode number, and then later after the
initial full send we rename both the child and parent directories, but
wi
Test for a btrfs incremental send issue where we end up sending a
wrong section of data from a file extent if the corresponding file
extent is compressed and the respective file extent item has a non
zero data offset.
Fixed by the following linux kernel btrfs patch:
Btrfs: use right clone root
On Sun, Feb 16, 2014 at 11:08 PM, Dave Chinner wrote:
> On Sat, Feb 15, 2014 at 03:36:13PM +, Filipe David Borba Manana wrote:
>> Test for a btrfs incremental send issue where we end up sending a
>> wrong section of data from a file extent if the corresponding file
>> extent is compressed and
On Sat, Feb 15, 2014 at 03:36:13PM +, Filipe David Borba Manana wrote:
> Test for a btrfs incremental send issue where we end up sending a
> wrong section of data from a file extent if the corresponding file
> extent is compressed and the respective file extent item has a non
> zero data offset
On Sun, Feb 16, 2014 at 5:23 PM, Marc MERLIN wrote:
> On Sun, Feb 16, 2014 at 03:38:18PM +, Filipe David Manana wrote:
>> On Sun, Feb 16, 2014 at 2:23 PM, Marc MERLIN wrote:
>> > Hi Fillipe, I see you have another fix for btrfs send (attached below),
>> > as ell as your other patch on Jan 21s
Regression test for btrfs incremental send issue where an rmdir
instruction was sent multiple times for the same target directory.
The number of times depended on the number of hardlinks against
the same inode inside the target directory. That inode must have
had the highest number of all the inode
When doing an incremental send, if we delete a directory that has N > 1
hardlinks for the same file and that file has the highest inode number
inside the directory contents, an incremental send would send N times an
rmdir operation against the directory. This made the btrfs receive command
fail on
Simplest way to do it is to make the directories that you don't want to
replicate be separate subvolumes. I do this to keep from replicating
copies of snapshot directories.
Example:
mv /home/GEO/.cache /home/GEO/.cache.tmp
btrfs sub create /home/GEO/.cache
cp -a --reflink=always /home/GEO/.cac
On 16 February 2014 20:07, GEO <1g2e...@gmail.com> wrote:
> Hi,
>
> I have been experimenting with btrfs send/receive for incremental backups, but
> could not figure out how to exclude certain directories from
> subvolumes/snapshots. For example, I want to backup my data in home, but I am
> not int
Hi,
I have been experimenting with btrfs send/receive for incremental backups, but
could not figure out how to exclude certain directories from
subvolumes/snapshots. For example, I want to backup my data in home, but I am
not interested in backing up hidden directories like .cache too.
Is it c
On Sun, Feb 16, 2014 at 06:18:38PM +, Duncan wrote:
> Goswin von Brederlow posted on Sun, 16 Feb 2014 14:58:08 +0100 as
> excerpted:
>
> > As you can see there are still 270GiB free and plenty of block groups
> > free on the device too.
> >
> > So why isn't btrfs allocating a new block group
On Feb 16, 2014, at 12:18 PM, Hendrik Friedel wrote:
> Hi Chris,
>
> thanks for your hint.
> >> No. You said you need to recreate the file system, and only have these two
> >> devices and therefore must remove one device. You can't achieve that with
> >> raid1 which requires minimum two devic
Hi Chris,
thanks for your hint.
>> No. You said you need to recreate the file system, and only have
these two devices and therefore must remove one device. You can't
achieve that with raid1 which requires minimum two devices.
-dconvert=single -mconvert=dup -sconvert=dup
Actually, I'm remind
Goswin von Brederlow posted on Sun, 16 Feb 2014 14:58:08 +0100 as
excerpted:
> As you can see there are still 270GiB free and plenty of block groups
> free on the device too.
>
> So why isn't btrfs allocating a new block group to store more data?
I saw this on a much (much) smaller filesystem a
On Sun, Feb 16, 2014 at 03:38:18PM +, Filipe David Manana wrote:
> On Sun, Feb 16, 2014 at 2:23 PM, Marc MERLIN wrote:
> > Hi Fillipe, I see you have another fix for btrfs send (attached below),
> > as ell as your other patch on Jan 21st (neither are in my 3.12.7).
>
> Hi Marc,
> Some replies
I got this error when deleting around a hundred snapshots with kernel
3.13.0 and btrfs-progs 3.12:
[ 831.628833] [sched_delayed] sched: RT throttling activated
[ 858.586718] BUG: soft lockup - CPU#1 stuck for 22s! [btrfs-transacti:643]
[ 858.586721] Modules linked in: ipt_MASQUERADE xt_CHECKSUM
On Sun, Feb 16, 2014 at 2:23 PM, Marc MERLIN wrote:
> Hi Fillipe, I see you have another fix for btrfs send (attached below),
> as ell as your other patch on Jan 21st (neither are in my 3.12.7).
Hi Marc,
Some replies below inlined.
>
> From my error below,
>> ERROR: rmdir o1845158-142-0 failed.
On Fri, 14 Feb 2014 15:33:10 +0100, Saint Germain
wrote :
> On 11 February 2014 03:30, Saint Germain wrote:
> >> > I am experimenting with BTRFS and RAID1 on my Debian Wheezy (with
> >> > backported kernel 3.12-0.bpo.1-amd64) using a a motherboard with
> >> > UEFI.
> >>
> >> > I have installed D
Hello,
I wonder if there is any known way to get the mount point directory name
with in the btrfs-kernel ?
Thanks, Anand
--
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.o
Hi Fillipe, I see you have another fix for btrfs send (attached below),
as ell as your other patch on Jan 21st (neither are in my 3.12.7).
>From my error below,
> ERROR: rmdir o1845158-142-0 failed. No such file or directory
can you tell if I'm having a different problem than the two patches
you
Hi,
I'm getting a ENOSPC error from btrfs despite there still being plenty
of space left:
% df -m /mnt/nas3
Filesystem 1M-blocks Used Available Use% Mounted on
/dev/mapper/nas3-a 19077220 18805132270773 99% /mnt/nas3
% btrfs fi show
Label: none uuid: 4b18f84e-2499-41ca-81ff-fe
Regression test for a btrfs incremental send issue related to renaming of
directories. If at the time of the initial send we have a directory that is
a child of a directory with a higher inode number, and then later after the
initial full send we rename both the child and parent directories, but
wi
This fixes yet one more case not caught by the commit titled:
Btrfs: fix infinite path build loops in incremental send
In this case, even before the initial full send, we have a directory
which is a child of a directory with a higher inode number. Then we
perform the initial send, and after we
Hi Linus,
We have a small collection of fixes in my for-linus branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
The big thing that stands out is a revert of a new ioctl. Users haven't
shipped yet in btrfs-progs, and Dave Sterba found a better way to export
th
37 matches
Mail list logo
