On Fri, Oct 3, 2014 at 9:54 AM, Josef Bacik wrote:
> We can deal with corrupt items by deleting them in a few cases. Fsck can
> easily
> recover from a missing extent item or a dir index item. So if we notice a
> item
> is completely bogus and it is of a key that we know we can repair then jus
On Tue, Aug 19, 2014 at 11:21 AM, M G Berberich
wrote:
> Hello,
>
> we are thinking about using BtrFS on standard hardware for a
> fileserver with about 50T (100T raw) of storage (25×4TByte).
>
I would recommend carefully reading this thread titled: "1 week to
rebuid 4x 3TB raid10 is a long time!
On Sat, Aug 9, 2014 at 11:21 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> But from rc5 on thru rc7 or 8 and
> release, unless you're one of the ones still waiting on a bug found
> earlier to be fixed, it's generally quite stable and boring.
>
> So by the time of actual .0 release, it really is
On Mon, Aug 4, 2014 at 9:47 AM, Russell Coker wrote:
> If you regularly run a scrub with options such as "-dusage=50 -musage=10" then
> the amount of free space in metadata chunks will tend to be a lot greater than
> that in data chunks.
>
Just to clarify for posterity, I'm pretty sure you meant
On Sat, Aug 2, 2014 at 6:35 PM, Peter Waller wrote:
> Hi All,
>
> My TL;DR questions are at the bottom, before the stack trace.
>
> I'm running Ubuntu 14.04. I wonder if this problem is related to the
> thread titled "Machine lockup due to btrfs-transaction on AWS EC2
> Ubuntu 14.04" which I start
On Thu, Jun 5, 2014 at 2:53 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Timofey Titovets posted on Thu, 05 Jun 2014 19:13:08 +0300 as excerpted:
>
>> 2014-06-05 18:52 GMT+03:00 Igor M :
>>> One more question. Is there any other way to find out file
>>> fragmentation ?
>>> I just copied 35Gb file on
On Sat, May 31, 2014 at 6:48 PM, Philip Worrall
wrote:
> LZ4 is a lossless data compression algorithm that is focused on
> compression and decompression speed. LZ4 gives a slightly worse
> compression ratio compared with LZO (and much worse than Zlib)
> but compression speeds are *generally* simil
as a
"must-have" capability for nearly everybody using btrfs. But, the
more I look at my work load and common practices with btrfs, the more
I am wondering just how often snapshot-aware defrag was actually doing
something for me.
I use a lot of snapshots. But for the most part, once I touch
On Wed, May 7, 2014 at 3:52 AM, Marc MERLIN wrote:
> On Wed, May 07, 2014 at 09:29:41AM +0100, Hugo Mills wrote:
>> On Wed, May 07, 2014 at 01:18:40AM -0700, Marc MERLIN wrote:
>> > On Tue, May 06, 2014 at 07:39:12PM +, Duncan wrote:
>> > > That appears to be a very good use of either -d raid0
On Sat, Apr 19, 2014 at 2:45 PM, Marcel Partap wrote:
> This is the BTRFS development list, right? Someone here should know how
> to achieve this I hope?
> #Regards
>
>> On 01/03/14 02:21, Marcel Partap wrote:
>>> Dear BTFRS devs,
>>> I have a 1TB btrfs volume mounted read-only since two years bec
On Tue, Apr 15, 2014 at 11:50 AM, David Sterba wrote:
> There's a case which clone does not handle and used to BUG_ON instead,
> (testcase xfstests/btrfs/035), now returns EINVAL. This error code is
> confusing to the ioctl caller, as it normally signifies errorneous
> arguments.
>
> Change it to
On Mon, Feb 24, 2014 at 7:38 PM, Wang Shilong
wrote:
> Hi Mitch,
>
>
> On 02/25/2014 07:03 AM, Mitch Harder wrote:
>>
>> On Mon, Feb 24, 2014 at 5:55 AM, Wang Shilong
>> wrote:
>>>
>>> We found btrfsck will output backrefs mismatch while the file
thing in btrfs-progs. All WARN_ONs are treated the same
as BUG_ONs, and the program is halted.
Should we convert all our btrfs-progs WARN_ONs to BUG_ONs to
allow us to implement a true WARN_ON functionality?
Signed-off-by: Mitch Harder
---
kerncompat.h | 14 --
1 file changed, 12 i
On Mon, Feb 24, 2014 at 5:55 AM, Wang Shilong
wrote:
> We found btrfsck will output backrefs mismatch while the filesystem
> is defenitely ok.
>
> The problem is that check_block() don't return right value,which
> makes btrfsck won't walk all tree blocks thus we don't get a consistent
> filesystem
for max_inline=0.
This patch will allow the the max_inline mount option to accept non-zero
values as indicated in the documentation.
Signed-off-by: Mitch Harder
---
fs/btrfs/super.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
index
The function call that set the ret parameter evaluated in this
BUG_ON was removed in a previous commit:
11be10f71e1af5256f221feb9e91300b3e28bbef
Btrfs-progs: make fsck fix certain file extent inconsistencies
Signed-off-by: Mitch Harder
---
cmds-check.c | 1 -
1 file changed, 1 deletion(-)
diff
could be returned while processing the leaf.
The only caller of this function (walk_down_tree) would ignore
the return value anyway. But this patch will correct the
behaviour in case future changes intend to utilize the return
value.
Signed-off-by: Mitch Harder
---
cmds-check.c | 5 -
1
Change the definition of BUG() to use assert instead of abort to
provide information about the location of the issue.
Signed-off-by: Mitch Harder
---
kerncompat.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kerncompat.h b/kerncompat.h
index 1fc2b34..f370cd8 100644
--- a
On Thu, Feb 6, 2014 at 3:22 PM, David Sterba wrote:
> On Thu, Feb 06, 2014 at 12:34:08PM -0600, Mitch Harder wrote:
>> Convert the instances of BUG() to BUG_ON(1) to provide information
>> about the location of the abort.
>
> kerncompat.h:
>
> #define BUG() abort()
&
Convert the instances of BUG() to BUG_ON(1) to provide information
about the location of the abort.
Signed-off-by: Mitch Harder
---
btrfs-debug-tree.c | 4 ++--
ctree.c| 20 ++--
ctree.h| 2 +-
disk-io.c | 4 ++--
extent-tree.c | 6
On Thu, Jan 16, 2014 at 8:03 PM, Mitch Harder
wrote:
> I received a btrfs page allocation failure on my 3.12.7 kernel which
> is merged with Chris' for-linus branch for the 3.13_rc kernel.
>
> I have several btrfs partitions mounted, but I believe this error is
> on my
I received a btrfs page allocation failure on my 3.12.7 kernel which
is merged with Chris' for-linus branch for the 3.13_rc kernel.
I have several btrfs partitions mounted, but I believe this error is
on my btrfs root partition.
Several things were going on at the same time on this partition. I
On Mon, Jan 13, 2014 at 6:37 PM, Chris Murphy wrote:
>
> On Jan 13, 2014, at 3:58 PM, Holger Brandsmeier wrote:
>>
>> Currently btrfsck failes to repair my partition, I get the output:
>>
>> [root@ho-think bholger]# btrfsck --repair /dev/sda5
>
> This is almost the last resort and you probably sh
On Tue, Sep 17, 2013 at 10:21 AM, David Sterba wrote:
> The command has been moved and we should rename the files accordingly,
> so the entry point is now in cmds-rescue.c and the core functionality
> in it's own file.
>
> Return codes of btrfs_recover_chunk_tree have been simplified not to
> requ
On Fri, Aug 23, 2013 at 4:03 AM, Miao Xie wrote:
> On fri, 23 Aug 2013 10:34:42 +0200, Stefan Behrens wrote:
>> Mitch Harder noticed that the patch 3c64a1a mentioned in the subject
>> line was causing a kernel BUG() on snapshot deletion.
>>
>> The patch was wrong. It
On Fri, Aug 23, 2013 at 3:48 AM, Stefan Behrens
wrote:
> On Wed, 21 Aug 2013 08:44:55 -0500, Mitch Harder wrote:
>> I've had a hard time assembling a portable reproducer for this issue.
>>
>> I discovered that my reproducer was highly dependent on a local
>> a
On Thu, Aug 22, 2013 at 1:47 AM, Nicholas Lee wrote:
> [ 45.914275] [ cut here ]
> [ 45.914406] kernel BUG at fs/btrfs/volumes.c:4417!
> [ 45.914489] invalid opcode: [#1] PREEMPT SMP
I can't say if this will fix your problem or not, but the 3.10.x
kernel has a
On Thu, Aug 15, 2013 at 12:29 PM, Mitch Harder
wrote:
> I'm running into a curious problem.
>
> In the process of making my script portable, I am breaking the ability
> to replicate the error.
>
> I'm trying to isolate the aspect of my local script that is trig
I'm running into a curious problem.
In the process of making my script portable, I am breaking the ability
to replicate the error.
I'm trying to isolate the aspect of my local script that is triggering
the error. No firm insights yet.
On Tue, Aug 13, 2013 at 11:03 AM, Mitch Har
Let me work on making that script more portable, and hopefully quicker
to reproduce.
On Tue, Aug 13, 2013 at 9:15 AM, Josef Bacik wrote:
> On Mon, Aug 12, 2013 at 11:06:27PM -0500, Mitch Harder wrote:
>> I'm hitting a btrfs Kernel BUG running a snapshot stress script with
>&
I'm hitting a btrfs Kernel BUG running a snapshot stress script with
linux-3.11.0-rc5.
I'm running with lzo compression, autodefrag, and the partition is
formated with 16k leafsize/inodesize.
[ 72.170431] device fsid 8a6be667-d041-4367-80f7-e4cb42356e85 devid
1 transid 4 /dev/sda7
[ 72.297512
On Fri, Aug 9, 2013 at 9:46 AM, David Sterba wrote:
> On Fri, Aug 09, 2013 at 01:47:24PM +0800, Miao Xie wrote:
>> On thu, 8 Aug 2013 22:45:48 +0100, Filipe David Borba Manana wrote:
>> > 8MiB is way too large and likely set by mistake. This is not
>> > a significant issue as in practice the max a
There's been a parallel effort to incorporate a general set of lz4
patches in the kernel.
I see these patches are currently queued up in the linux-next tree, so
we may see them in the 3.11 kernel.
It looks like lz4 and lz4hc will be provided.
So, instead of btrfs having it's own implementation o
I'm running into a problem with the btrfs-cleaner thread becoming
blocked on xfstests 068.
The test locks up indefinitely without completing (normally it
finished in about 45 seconds on my test box).
I've replicated the issue on 3.10.0_rc5 and the for-linus branch of 3.9.0.
I ran a git bisect on
We had a discussion on this topic in another thread.
I'd be happy to be corrected, but I think the conclusion was that you
probably need to be on a really modern version of Linux to work with
the latest version of btrfs-progs that is in the kernel git
repository.
The mkfs.btrfs version in the ke
On 4/3/13, Chris Murphy wrote:
>
> On Mar 29, 2013, at 9:42 AM, Mitch Harder
> wrote:
>
>> On Fri, Mar 29, 2013 at 1:21 AM, Chris Murphy
>> wrote:
>>>
>>> mkfs.btrfs -l 8192 with kernel 3.9.0 creates a file system mountable by
>>> 3.9.0 and onl
On Fri, Mar 29, 2013 at 1:21 AM, Chris Murphy wrote:
> Chris Murphy wrote:
>> On Mar 29, 2013, at 12:04 AM, cwillu wrote:
>>
>>> commit 1a72afaa "btrfs-progs: mkfs support for extended inode refs"
>>> unconditionally enables extended irefs (which permits more than 4k
>>> links to the same inode).
On Wed, Mar 27, 2013 at 4:22 PM, Marc MERLIN wrote:
> On Wed, Mar 27, 2013 at 04:12:27PM -0500, Mitch Harder wrote:
>> On Wed, Mar 27, 2013 at 11:53 AM, Marc MERLIN wrote:
>> >
>> > Is my feeling of slower boot wrong, or is zlib also noticeably slower than
>
On Wed, Mar 27, 2013 at 11:53 AM, Marc MERLIN wrote:
>
> Is my feeling of slower boot wrong, or is zlib also noticeably slower than
> lzo to read and decompress?
>
Lzo compression should be faster in every aspect than zlib, especially
for reading.
But having said that, btrfs won't recompress any
On Thu, Mar 21, 2013 at 1:56 PM, Ask Bjørn Hansen wrote:
> Hello,
>
> A few weeks ago I replaced a ZFS backup system with one backed by btrfs. A
> script loops over a bunch of hosts rsyncing them to each their own subvolume.
> After each rsync I snapshot the "host-specific" subvolume.
>
> The "
On Thu, Mar 21, 2013 at 4:46 PM, Avi Miller wrote:
> Hi,
>
> On 22/03/2013, at 8:11 AM, Joseph Moore wrote:
>
>> [root@ol6 btrfs-progs]# uname -a
>> Linux ol6.localdomain 2.6.39-400.17.2.el6uek.x86_64 #1 SMP Wed Mar 13
>> 12:31:05 PDT 2013 x86_64 x86_64 x86_64 GNU/Linux
>
>
> This is the currentl
On Thu, Mar 7, 2013 at 12:10 PM, Swâmi Petaramesh wrote:
> Le 07/03/2013 19:06, Jérôme Poulin a écrit :
>> mkfs.btrfs tries to lookup loop devices by their filenames and fails
>> if any loop device file is missing.
>
> Hmm Why would mkfs.btrfs want to lookup anything else but the device
> we'r
On Thu, Feb 21, 2013 at 7:26 AM, Chris Mason wrote:
> On Thu, Feb 21, 2013 at 02:48:22AM -0700, Miao Xie wrote:
>> When running the 083th case of xfstests on the filesystem with
>> "compress-force=lzo", the following WARNINGs were triggered.
>> WARNING: at fs/btrfs/inode.c:7908
>> WARNING: at
I'm getting a series of kernel WARNING messages when testing Josef's
btrfs-next and Chris' next branch running xfstests 083 when mounted
with compress-force=lzo.
I'm not seeing any other indications of problems other than the
WARNINGs on xfstests 083, so this may be some sort of false positive.
H
of droping inode, we
> don't keep snap/subvol's cache inode in memory till end so that we can
> add snap/subvol into dead roots list in time.
>
> Reported-by: Mitch Harder
> Signed-off-by: Liu Bo
> ---
> fs/btrfs/inode.c |3 ++-
> fs/btrfs/ioctl.c |6
I've encountered an issue where the space from previously deleted
snapshots is not being freed up by the cleaner thread.
I'm only encountering this issue when I mount with the inode_cache option.
I've reproduced this on a 3.7.9 kernel merged with the latest
for-linus branch. No additional patche
On Fri, Feb 8, 2013 at 8:53 AM, David Sterba wrote:
> On Thu, Feb 07, 2013 at 11:17:46PM -0600, Mitch Harder wrote:
>> On Thu, Feb 7, 2013 at 6:28 PM, David Sterba wrote:
>> > On Thu, Feb 07, 2013 at 03:38:34PM -0600, Mitch Harder wrote:
>> >> --- a/fs/btrfs/rel
On Thu, Feb 7, 2013 at 6:28 PM, David Sterba wrote:
> On Thu, Feb 07, 2013 at 03:38:34PM -0600, Mitch Harder wrote:
>> --- a/fs/btrfs/relocation.c
>> +++ b/fs/btrfs/relocation.c
>> @@ -144,7 +144,7 @@ struct tree_block {
>> unsigned int key_ready:1;
>>
place to ease the RAM required when spreading compression
across several CPUs, and to make sure the amount of IO required
to do a random read is reasonably small.
Signed-off-by: Mitch Harder
---
Changelog v1 -> v2:
- Use more self-documenting variable name:
compressed_extent_s
On Wed, Feb 6, 2013 at 12:46 PM, Zach Brown wrote:
>> + unsigned compressed_extent_size;
>
> It kind of jumps out that this mentions neither that it's the max nor
> that it's in KB. How about max_compressed_extent_kb?
>
>> + fs_info->compressed_extent_size = 128;
>
> I'd put a DEFAULT_MAX
Provide for modification of the limit of compressed extent size
utilizing mount-time configuration settings.
The size of compressed extents was limited to 128K, which
leads to fragmentation of the extents (although the extents
themselves may still be located contiguously). This limit is
put in pl
On Mon, Jan 28, 2013 at 9:52 PM, Chris Mason wrote:
> On Mon, Jan 28, 2013 at 08:22:10PM -0700, Liu Bo wrote:
>> While running snapshot testscript created by Mitch and David,
>> the race between autodefrag and snapshot deletion can lead to
>> corruption of dead_root list so that we can get crash o
all we need to do is to take the lock to protect 'read root and get inode',
> since we synchronize to wait for the rcu grace period before adding something
> to the global dead_roots list.
>
> Reported-by: Mitch Harder
> Signed-off-by: Liu Bo
I'm still seeing seeing issues wi
On Sun, Jan 27, 2013 at 6:41 AM, Liu Bo wrote:
>
> Hi Mitch,
>
> Many thanks for testing it!
>
> Well, after some debugging, I finally figure out the whys:
>
> (1) btrfs_ioctl_snap_destroy() will free the inode of snapshot and set
> root's refs to zero(btrfs_set_root_refs()), if this inode happens
On Fri, Jan 25, 2013 at 9:42 AM, Liu Bo wrote:
> On Fri, Jan 25, 2013 at 08:55:58AM -0600, Mitch Harder wrote:
>> On Wed, Jan 23, 2013 at 6:52 PM, Liu Bo wrote:
>> > On Wed, Jan 23, 2013 at 10:05:04AM -0600, Mitch Harder wrote:
>> >> On Wed, Jan 23, 2013 at 1:51 AM,
On Wed, Jan 23, 2013 at 6:52 PM, Liu Bo wrote:
> On Wed, Jan 23, 2013 at 10:05:04AM -0600, Mitch Harder wrote:
>> On Wed, Jan 23, 2013 at 1:51 AM, Liu Bo wrote:
>> > On Tue, Jan 22, 2013 at 11:41:19AM -0600, Mitch Harder wrote:
>> >> On Thu, Jan 17, 2013 at 8:42
On Wed, Jan 23, 2013 at 1:51 AM, Liu Bo wrote:
> On Tue, Jan 22, 2013 at 11:41:19AM -0600, Mitch Harder wrote:
>> On Thu, Jan 17, 2013 at 8:42 AM, Mitch Harder
>> wrote:
>> > On Wed, Jan 16, 2013 at 6:36 AM, Liu Bo wrote:
>> >> This comes from one o
On Thu, Jan 17, 2013 at 8:42 AM, Mitch Harder
wrote:
> On Wed, Jan 16, 2013 at 6:36 AM, Liu Bo wrote:
>> This comes from one of btrfs's project ideas,
>> As we defragment files, we break any sharing from other snapshots.
>> The balancing code will preserve the sharing
On Fri, Jan 18, 2013 at 6:19 AM, David Sterba wrote:
> On Thu, Jan 17, 2013 at 08:42:46AM -0600, Mitch Harder wrote:
>> [16028.160002] RAX: dead00200200 RBX: 8800 RCX:
>> 00018e20
>> [16028.160002] RDX: dead00100100 RSI: 001b RDI:
On Thu, Jan 17, 2013 at 6:53 PM, Liu Bo wrote:
> On Thu, Jan 17, 2013 at 08:42:46AM -0600, Mitch Harder wrote:
>> On Wed, Jan 16, 2013 at 6:36 AM, Liu Bo wrote:
>> > This comes from one of btrfs's project ideas,
>> > As we defragment files, we break any sharin
On Wed, Jan 16, 2013 at 6:36 AM, Liu Bo wrote:
> This comes from one of btrfs's project ideas,
> As we defragment files, we break any sharing from other snapshots.
> The balancing code will preserve the sharing, and defrag needs to grow this
> as well.
>
> Now we're able to fill the blank with thi
On Tue, Jan 15, 2013 at 8:49 AM, Marc MERLIN wrote:
> On Mon, Jan 14, 2013 at 10:48:50PM -0800, David Brown wrote:
>> Why not make a snapshot of the root volume, and then delete the files
>> you want to move from the original root, and delete the rest of root
>> from the snapshot?
>
> Are a snapsh
On Fri, Jan 11, 2013 at 12:13 PM, Chris Carlin wrote:
> I have a week-old filesystem that is reported clean by btrfsck and
> scrub, but that fails under operations ranging from du to sync and
> umount (but no failures if mounted readonly).
>
> My problem sounds similar to a few other reports (e.g.
On Sat, Dec 29, 2012 at 5:28 AM, Hendrik Friedel wrote:
> Hello,
>
> I re-send this message, hoping that someone can give me a hint?
>
> Regards,
> Hendrik
>
Two possibilities come to mind (although there may be others).
(1) The file still exists, but it is somewhere you did not expect.
(2) Y
On Fri, Dec 28, 2012 at 3:33 AM, Liu Bo wrote:
> We forgot to reset the path lock state to zero after we unlock the path block,
> and this can lead to the ASSERT checker in tree unlock API.
>
> Reported-by: Slava Barinov
> Signed-off-by: Liu Bo
> ---
> fs/btrfs/extent-tree.c |2 ++
> 1 file
On Sat, Dec 15, 2012 at 1:40 PM, Hendrik Friedel wrote:
> Hello Mitch, hello all,
>
>
>> Since btrfs has significant improvements and fixes in each kernel
>>
>> release, and since very few of these changes are backported, it is
>> recommended to use the latest kernels available.
>
>
> Ok, it's 3.7
I've been testing Josef's btrfs-next master branch using a test that
loops through creation, manipulation and destruction of snapshots of
kernel git sources.
The version of btrfs-next I'm using was built as of Friday, December
14th, and the top commit is:
Btrfs: don't take inode delalloc mutex if
On Thu, Nov 1, 2012 at 6:21 AM, Liu Bo wrote:
> On Thu, Nov 01, 2012 at 08:08:52PM +0900, Itaru Kitayama wrote:
>> Hi Liubo,
>>
>> I couldn't apply your V4 patch against the btrfs-next HEAD. Do you have
>> a github branch which I can checkout?
>>
>
> The current btrfs-next HEAD actually have inclu
On Wed, Dec 12, 2012 at 11:12 AM, wrote:
>
> So there is no way to have filesystem encryption, while keeping
> snapshots?
>
>
I run btrfs on top of LUKS encryption on my laptop. You should be
able to do the same.
You could then run rsync through ssh. However, rsync will have no
knowledge of a
On Sun, Dec 9, 2012 at 1:06 PM, Hendrik Friedel wrote:
> Dear Mich,
>
> thanks for your help and suggestion:
>
>> It might be interesting for you to try a newer kernel, and use scrub
>> on this volume if you have the two disks RAIDed.
>
> I have now scrubbed the Disk:
> ./btrfs scrub status /mnt/o
On Wed, Dec 5, 2012 at 2:50 PM, Hendrik Friedel wrote:
> Dear all,
>
> thanks for developing btrfsck!
> Now, I'd like to contribute -as far as I can. I'm not a developer, but I do
> have some linux-experience.
> I've been using btrfsck on two 3TB HDDs (mirrored) for a while now under
> Kernel 3.0.
One of my Btrfs partitions ran into a severe slowdown recently.
Operations that would normally complete in 20-30 seconds were now
requiring hours.
There were no errors or warnings in dmesg (Alt-SysRq-W is below, but
shows nothing out of the ordinary). And if I took the partition
offline, it would
On Mon, Oct 29, 2012 at 8:20 PM, Liu Bo wrote:
> On 10/30/2012 04:06 AM, Mitch Harder wrote:
>> On Sat, Oct 27, 2012 at 5:28 AM, Liu Bo wrote:
>>> This comes from one of btrfs's project ideas,
>>> As we defragment files, we break any sharing from other snapsh
On Tue, Oct 30, 2012 at 6:04 AM, ching wrote:
> Hi all,
>
> I am testing my btrfs root partition with "max_inline=0", and 64k leaf size
> for weeks and it seems that it is fine.
>
>
> AFAIK btrfs inline small files into metadata by default, I am curious why?
>
> If there is only a few small files
On Sat, Oct 27, 2012 at 5:28 AM, Liu Bo wrote:
> This comes from one of btrfs's project ideas,
> As we defragment files, we break any sharing from other snapshots.
> The balancing code will preserve the sharing, and defrag needs to grow this
> as well.
>
> Now we're able to fill the blank with thi
On Mon, Oct 1, 2012 at 1:28 AM, Roman Mamedov wrote:
> Hello,
>
> On a 3.6.0-rc7 kernel, I launched:
>
> # btrfs fi balance start -f -mconvert=single /mnt/tmp/
>
> Current situation:
>
> # df -h /mnt/tmp/
> Filesystem Size Used Avail Use% Mounted on
> /dev/mapper/alpha-lv1 3.6T 2.
I've run across two issues with the delayed cleaner process running a
kernel based on the 3.6.0 btrfs-next branch in Josef's git repository.
(1) I'm getting an error when trying to list my subvolumes whenever
the cleaner thread is running:
# btrfs su li /mnt/benchmark/
ERROR: Failed to lookup pa
On Mon, Oct 8, 2012 at 8:19 AM, Chris Mason wrote:
> On Mon, Oct 08, 2012 at 06:18:26AM -0600, Liu Bo wrote:
>> On 10/03/2012 10:02 PM, Chris Mason wrote:
>> > On Tue, Sep 25, 2012 at 07:07:53PM -0600, Liu Bo wrote:
>> >> On 09/26/2012 01:39 AM, Mitch Harder wrote:
On Thu, Oct 4, 2012 at 9:22 AM, Liu Bo wrote:
> On 10/03/2012 10:02 PM, Chris Mason wrote:
>> On Tue, Sep 25, 2012 at 07:07:53PM -0600, Liu Bo wrote:
>>> On 09/26/2012 01:39 AM, Mitch Harder wrote:
>>>> On Mon, Sep 17, 2012 at 4:58 AM, Liu Bo wrote:
>>>&g
On Wed, Oct 3, 2012 at 5:11 PM, Øystein Sættem Middelthun
wrote:
> On 10/03/2012 07:29 PM, Mitch Harder wrote:
>>
>> If you do not have a suitable backup for these files, please make an
>> effort to do what you can with restore. Some of the repair methods
>> out there
On Wed, Oct 3, 2012 at 11:35 AM, Øystein Sættem Middelthun
wrote:
> Hi!
>
> I have a broken btrfs unable to mount because it is unable to find the tree
> root. Using find-root I find the following:
>
> Well block 14102764707840 seems great, but generation doesn't match,
> have=109268, want=109269
Remove a comment that was orphaned by a previous commit which
removed the function associated with the comment.
See commit efd049fb26a162c3830fd3cb1001fdc09b147f3b
This left the comment in a confusing context that seemed to be
associated with another function.
Signed-off-by: Mitch Harder
On Mon, Sep 17, 2012 at 4:58 AM, Liu Bo wrote:
> This comes from one of btrfs's project ideas,
> As we defragment files, we break any sharing from other snapshots.
> The balancing code will preserve the sharing, and defrag needs to grow this
> as well.
>
> Now we're able to fill the blank with thi
On Thu, Sep 20, 2012 at 2:03 PM, Josef Bacik wrote:
> Hello,
>
> I'm going to look at fixing some of the performance issues that crop up
> because
> of our reservation system. Before I go and do a whole lot of work I want some
> feedback.
When I was trying to figure out the problem with gzip EN
On Thu, Aug 2, 2012 at 6:46 AM, David Sterba wrote:
...
>
> Fsck spits lots of errors:
>
> ref mismatch on [1133031424 4096] extent item 1, found 0
> Backref 1133031424 root 5 not referenced back 0x7d1f40
> Incorrect global backref count on 1133031424 found 1 wanted 0
> backpointer mismatch on [11
(condition) \
220 break; \
221 __wait_event(wq, condition);\
222 } while (0)
Tested-by: Mitch Harder
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
I've been trying out different leafsize/nodesize settings by
benchmarking some typical operations.
These changes had more impact than I expected. Using a
leafsize/nodesize of either 8192 or 16384 provided a noticeable
improvement in my limited testing.
These results are similar to some that Chri
On Tue, Jul 31, 2012 at 2:37 PM, Mitch Harder
wrote:
> I've been working on running down intermittent ENOSPC issues.
>
> I can only seem to replicate ENOSPC errors when running zlib
> compression. However, I have been seeing similar ENOSPC errors to a
> lesser extent when pl
On Fri, Aug 17, 2012 at 12:20 AM, Marc MERLIN wrote:
> On Thu, Aug 16, 2012 at 09:20:00PM -0700, james northrup wrote:
>> dunno if this thread is dead, but im inclined to patch in cp --reflink
>> to "fdupes" prog. It currently does provide a poor-man's dedupe via
>> md5sum and hardlink, or delet
On Thu, Aug 16, 2012 at 5:17 PM, Andi Kleen wrote:
> On Thu, Aug 16, 2012 at 11:55:06AM -0700, james northrup wrote:
>> looks like ARM results are inconclusive from a lot of folks without
>> bandwidth to do a write-up, what about just plain STAGING status for ARM so
>> the android tweakers can bea
On Tue, Aug 14, 2012 at 3:22 PM, Josef Bacik wrote:
> Swinging this pendulum back the other way. We've been allocating chunks up
> to 2% of the disk no matter how much we actually have allocated. So instead
> fix this calculation to only allocate chunks if we have more than 80% of the
> space av
On Wed, Aug 8, 2012 at 3:37 PM, Josef Bacik wrote:
> On Wed, Aug 08, 2012 at 01:49:06PM -0600, Arne Jansen wrote:
>> run_clustered_refs runs all delayed refs for one head one by one. During
>> the runs, the delayed_refs->lock is released. In this window, the ref_mod
>> from the head does not match
On Mon, Aug 6, 2012 at 3:18 PM, Arne Jansen wrote:
> Commit a168650c introduced a waiting mechanism to prevent busy waiting in
> btrfs_run_delayed_refs. This can deadlock with btrfs_run_ordered_operations,
> where a tree_mod_seq is held while waiting for the io to complete, while
> the end_io call
On Wed, Aug 1, 2012 at 7:21 PM, Mitch Harder
wrote:
> On Wed, Aug 1, 2012 at 3:25 PM, Josef Bacik wrote:
>> We need an smb_mb() before waitqueue_active to avoid missing wakeups.
>> Before Mitch was hitting a deadlock between the ordered flushers and the
>> transaction commi
On Wed, Aug 1, 2012 at 3:25 PM, Josef Bacik wrote:
> We need an smb_mb() before waitqueue_active to avoid missing wakeups.
> Before Mitch was hitting a deadlock between the ordered flushers and the
> transaction commit because the ordered flushers were waiting for more refs
> and were never woken
I've been working on running down intermittent ENOSPC issues.
I can only seem to replicate ENOSPC errors when running zlib
compression. However, I have been seeing similar ENOSPC errors to a
lesser extent when playing with the LZ4HC patches.
I apologize for not following up on this sooner, but I
Certain architectures or platforms or combinations of CONFIG options
require an explicit #include .
Signed-off-by: Mitch Harder
---
fs/btrfs/send.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/send.c b/fs/btrfs/send.c
index bf232c8..118e76d 100644
--- a/fs
with
other send/receive fixes.
Mitch Harder (1):
Btrfs: Explicitly include vmalloc.h in send.c
fs/btrfs/send.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
--
1.7.8.6
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message
compression and when setting the default subvolume.
Signed-off-by: Mitch Harder
---
v1->v2
- Remove extraneous formatting change.
v2->v3
- Consolidate into a single patch
- Convert helper function to a static inline function.
v3->v4
- Per feedback from Li Zefan, change function name from _chk_
compression.
Signed-off-by: Mitch Harder
---
v1->v2
- Remove extraneous formatting change.
v2->v3
- Consolidate into a single patch
- Convert helper function to a static inline function.
fs/btrfs/ctree.h | 13 +
fs/btrfs/ioctl.c |7 +--
fs/btrfs/super.c |1 +
3 files c
1 - 100 of 240 matches
Mail list logo
