On Tue, Nov 1, 2011 at 3:36 AM, Stephane CHAZELAS
wrote:
> Hiya,
>
> trying to restore a FS from a backup (tgz) on a freshly made
> btrfs this morning, I got ENOSPCs after about 100MB out of 4GB
> have been extracted. strace indicates that the ENOSPC are upon
> the open(O_WRONLY).
>
> Restoring wi
On Wed, Nov 2, 2011 at 6:40 PM, Chris Mason wrote:
> On Thu, Nov 03, 2011 at 12:02:31AM +0100, David Sterba wrote:
>> This one happened again, exactly same sequence of warnings and the crash
>> at the end (same stack traces). It was in integration-scrub branch, ie.
>> with all fixes on top.
>>
>>
On Sat, Nov 5, 2011 at 6:46 AM, Chris Mason wrote:
> On Fri, Nov 04, 2011 at 08:47:56PM -0400, Chris Mason wrote:
>> On Fri, Nov 04, 2011 at 05:18:54PM -0400, Josef Bacik wrote:
>> > V1->V2: I stupidly thought I could get away with some flushing if we needed
>> > space but I was wrong, we could de
On Thu, Dec 15, 2011 at 1:44 PM, 810d4rk <810d...@gmail.com> wrote:
> Is anyone there trying to reproduce the bug??
>
I've been using btrfs and luks encryption on my Acer netbook for about
a year now. I haven't had an unmountable corruption on that computer
yet.
What are your goals now?
Are you
I've recently run into a kernel "NULL pointer dereference" while
scrubbing a partition that had picked up error.
I'm running kernel 3.2.0-rc7. I'd had a power outage, and noticed an
error in a partition when running btrfsck after reboot:
# ./btrfsck /dev/sdb5
root 5 inode 19772 errors 400
found
2012/1/5 Miao Xie :
> Reproduce steps:
> # mkfs.btrfs /dev/sdb5
> # mount /dev/sdb5 -o compress=lzo /mnt
> # dd if=/dev/zero of=/mnt/tmpfile bs=128K count=1
> # sync
> # truncate -s 64K /mnt/tmpfile
> root 5 inode 257 errors 400
Is this patch set intended to address the general case of btrfs
Lately, I've been running into a sharp increase in btrfsck inode 400
corruptions after an unclean shutdown.
The shutdowns have resulted from multiple sources (power outage, Xorg
keyboard misconfiguration, etc...). I have not made any systematic
study of btrfs' robustness to corruption after an un
2012/1/10 Michal Suba :
> Hello
>
> we are currently investigating performance issue on system runing above
> btrs filesystem. Is it possible, that performance is impacted by lack of
> free space? Also, how to get info about real free space on btrfs volume?
>
> # btrfs-show /dev/sdb1
> Label: opt
On Tue, Jan 3, 2012 at 11:35 AM, Mitch Harder
wrote:
> I've recently run into a kernel "NULL pointer dereference" while
> scrubbing a partition that had picked up error.
>
I'm no longer getting the NULL pointer panic on this partition.
I'm running into a new B
On Tue, Jan 17, 2012 at 3:24 AM, Miao Xie wrote:
> When we did sysbench test for inline files, enospc error happened easily
> though
> there was lots of free disk space which could be allocated for new chunks.
>
> Reproduce steps:
> # mkfs.btrfs -b $((2 * 1024 * 1024 * 1024))
> # mount /mnt
>
On Mon, Jan 16, 2012 at 6:10 PM, Mitch Harder
wrote:
> On Tue, Jan 3, 2012 at 11:35 AM, Mitch Harder
> wrote:
>> I've recently run into a kernel "NULL pointer dereference" while
>> scrubbing a partition that had picked up error.
>>
>
> I'
On Tue, Jan 17, 2012 at 10:41 AM, Jan Schmidt wrote:
> On 17.01.2012 17:35, Mitch Harder wrote:
>> I've been able to clear this BUG_ON() after applying Miao Xie's
>> "[PATCH] Btrfs: fix enospc error caused by wrong checks of the chunk"
>> on top of th
On Tue, Jan 17, 2012 at 10:39 AM, Chris Mason wrote:
> On Tue, Jan 17, 2012 at 10:31:00AM -0600, Mitch Harder wrote:
>> On Tue, Jan 17, 2012 at 3:24 AM, Miao Xie wrote:
>>
>> After applying this patch to the re-based integration branch, I was
>> able to clear an EFB
I have a Btrfs partition that is reliably reproducing premature ENOSPC
when restoring the disk from a tar file, but it is only happening with
zlib compression (lzo or no compression proceeds normally).
I've had the same issue at least back through the 3.1 kernel series,
and I've been having interm
On Thu, Jan 19, 2012 at 8:42 AM, Vincent Vanackere
wrote:
> Hi,
>
> With the most current git kernel (90a4c0f51e8e44111a926be6f4c87af3938a79c3)
> I'm still getting the same reproducible kernel panic when trying to read a
> particular file stored on a btrfs filesystem (as seen in the log there are
On Fri, Jan 20, 2012 at 10:48 AM, Vincent Vanackere
wrote:
> On 01/19/2012 05:24 PM, Mitch Harder wrote:
>>
>> On Thu, Jan 19, 2012 at 8:42 AM, Vincent Vanackere
>> wrote:
>>>
>>> Hi,
>>>
>>> With the most current git kernel
>>>
On Tue, Jan 24, 2012 at 10:24 AM, Vincent Vanackere
wrote:
> On 01/20/2012 09:54 PM, Mitch Harder wrote:
>>
>> On Fri, Jan 20, 2012 at 10:48 AM, Vincent Vanackere
>> wrote:
>>>
>>> On 01/19/2012 05:24 PM, Mitch Harder wrote:
>>>>
>
-by: Mitch Harder
---
fs/btrfs/extent_io.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c
index 9d09a4f..fcf77e1 100644
--- a/fs/btrfs/extent_io.c
+++ b/fs/btrfs/extent_io.c
@@ -3909,6 +3909,8 @@ int extent_range_uptodate(str
On Mon, Jan 30, 2012 at 3:41 PM, Vincent Vanackere
wrote:
> On Wed, Jan 25, 2012 at 20:03, Mitch Harder
> wrote:
>> A user has encountered a NULL pointer kernel oops in btrfs when
>> encountering media errors. The problem has been identified
>> as an unhandled NU
On Tue, Jan 31, 2012 at 12:04 PM, Thomas Weber
wrote:
> Hello,
>
> this morning my laptop with btrfs crashed. It is an ssd drive.
>
> It is a Linux aramis 3.2.2-1-ARCH #1 SMP PREEMPT Thu Jan 26 08:40:20 CET
> 2012 x86_64 Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz GenuineIntel
> GNU/Linux
>
> Regar
On Tue, Jan 31, 2012 at 11:20 PM, Thomas Weber
wrote:
> Hello Mitch,
>
> I have good news for you. I looked through all log files and found in the
> everything.log the following:
>
> Regards,
> Thomas
>
>
> Jan 31 05:12:24 localhost kernel: [87276.968049] btrfs memmove bogus
> src_offset 1870 move
On Sat, Feb 4, 2012 at 5:40 AM, Kai Krakow wrote:
> Kai Krakow schrieb:
>
>> Just happened while writing a huge avi file to my usb3 backup disk:
>>
>> [356036.596292] [ cut here ]
>> [356036.596300] kernel BUG at fs/btrfs/inode.c:1588!
> [...]
>>
>> btrfsck now finds many
On Tue, Feb 7, 2012 at 8:04 AM, Ryan C. Underwood
wrote:
>
>> > Unfortunately, I am going to have to give up on btrfs if it
>> > is really so fragile.
>>
>> However, complaining about the fragility of a still in development
>> and
>> marked experimental filesystem would seem disingenuous at best.
On Wed, Jan 18, 2012 at 10:13 AM, Mitch Harder
wrote:
> I have a Btrfs partition that is reliably reproducing premature ENOSPC
> when restoring the disk from a tar file, but it is only happening with
> zlib compression (lzo or no compression proceeds normally).
>
> I've h
On Wed, Feb 8, 2012 at 8:14 PM, Liu Bo wrote:
> On 02/09/2012 05:01 AM, Mitch Harder wrote:
>> On Wed, Jan 18, 2012 at 10:13 AM, Mitch Harder
>> wrote:
>>> I have a Btrfs partition that is reliably reproducing premature ENOSPC
>>> when restoring the disk from a t
rected before returning an error to the caller.
It is also interesting for highlighting all the places in Btrfs where an
ENOSPC can be generated.
Signed-off-by: Mitch Harder
---
fs/btrfs/delayed-inode.c| 10
fs/btrfs/extent-tree.c | 84 +
On Fri, Feb 10, 2012 at 3:33 AM, Jan Schmidt wrote:
> Hi Mitch,
>
> having this patch on the list is a good idea. I've two remarks, just in
> case it will be included sometimes:
>
> On 09.02.2012 22:38, Mitch Harder wrote:
>> diff --git a/fs/btrfs/delayed-inode
On Thu, Jan 12, 2012 at 6:28 PM, Andi Kleen wrote:
> From: Andi Kleen
>
> This is a C port of the google snappy compressor. It has roughly
> comparable compression to LZO, but is significantly faster on many file
> types. For example it beats all other compressors on already
> compressed data.
>
On Tue, Feb 14, 2012 at 1:52 PM, Andi Kleen wrote:
>
>> (BTW: If you're ever reworking this patch set, I'd like to make an ad
>> hoc request for slightly different names for fs/btrfs/snappy.c and
>> lib/snappy.c)
>
>
> Why?
>
It's not a big deal, I just found it confusing at first to see
"snappy
I've been trying to test the snappy compression patches, but I'm
getting corruptions when trying to use snappy as built on my system.
I'm checking out the Linux 3.2.6 kernel, merging that with the latest
'for-linus' branch on Chris Mason's kernel.org repo, and then
integrating the snappy and lz4 p
On Wed, Feb 15, 2012 at 5:03 PM, Duncan <1i5t5.dun...@cox.net> wrote:
> Mitch Harder posted on Wed, 15 Feb 2012 16:46:00 -0600 as excerpted:
>
>> I've been trying to test the snappy compression patches, but I'm getting
>> corruptions when trying to use snapp
On Wed, Feb 15, 2012 at 8:06 PM, Li Zefan wrote:
> Mitch Harder wrote:
>> When I copy directory containing a kernel sources git repository to a
>> freshly formated partition mounted with snappy, I get a corrupted
>> copy. If I mount with lzo or lz4 compression, I don
Just to add another data point, I built Chris Mason's 'snappy' branch
from git.kernel.org as-is (a 3.2.0 kernel plus the snappy patches)
with no additional patches.
This 3.2.0 snappy kernel also exhibits the problem copying the kernel
sources to a snappy-compressed partition.
--
To unsubscribe fro
I'm consistently hitting the BUG_ON in the new get_restripe_target
function that was added by "[PATCH 4/8] Btrfs: add
get_restripe_target() helper" when trying to initially mount a btrfs
partition.
Lines fs/btrfs/extent-tree.c:3161-3162:
BUG_ON(!mutex_is_locked(&fs_info->volume_mutex) &&
On Fri, Apr 6, 2012 at 10:43 AM, David Sterba wrote:
> On Fri, Apr 06, 2012 at 10:33:04AM -0500, Mitch Harder wrote:
>> I'm consistently hitting the BUG_ON in the new get_restripe_target
>> function that was added by "[PATCH 4/8] Btrfs: add
>> get_restripe_
On Thu, Apr 5, 2012 at 11:51 AM, Ilya Dryomov wrote:
> On Thu, Apr 05, 2012 at 12:23:01PM -0400, Bobby Powers wrote:
>> On Wed, Apr 4, 2012 at 10:04 PM, Bobby Powers wrote:
>> > spin_is_locked always returns 0 on non-SMP systems, which causes btrfs
>> > to fail the mount. There is documentation
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 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 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 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 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 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
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
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
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
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
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
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 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
On Sun, Jun 17, 2012 at 3:04 AM, rupert THURNER
wrote:
> On Sun, Jun 17, 2012 at 7:19 AM, Andrei Popa wrote:
>> On Sun, 2012-06-17 at 06:14 +0200, rupert THURNER wrote:
>>> >> Will result in anything reported in 'dmesg' output?
>>> > [ 6431.514454] device label 388gb-data devid 1 transid 1086 /de
On Thu, Jun 28, 2012 at 10:40 AM, David Sterba wrote:
> On Tue, Jun 26, 2012 at 08:48:37AM +0200, Arnd Hannemann wrote:
>> How show should we proceed to get above mentioned patch
>> (or the similar patch from Andrei Popa) merged?
>
> Josef picked the patch into btrfs-next, I see not problem to inc
On Wed, Jul 18, 2012 at 8:28 PM, David Sterba wrote:
> On Fri, Jul 13, 2012 at 10:19:14AM -0500, Mitch Harder wrote:
>> I was testing the lz4(hc) patches, and I found the the compression
>> INCOMPAT flags are not being updated using the method in this patch.
>>
>> The
ssion ("btrfs: Allow to specify compress method when defrag")
in ioctl.c.
The second patch uses the new function in the above referenced
existing check for lzo INCOMPAT performed when defragmenting
with explicit lzo compression. This patch provides no
functional changes.
Mitch Harder (2):
In support of the recently added capability to remount with lzo
compression, check the compression INCOMPAT flags when remounting
with lzo compression, and set the flags if necessary.
Signed-off-by: Mitch Harder
---
fs/btrfs/ctree.h |1 +
fs/btrfs/super.c | 21 -
2
When defragmenting with explicit lzo compression, simplify
the check for lzo INCOMPAT by using the new common function
introduced to support remounting with lzo compression.
Signed-off-by: Mitch Harder
---
fs/btrfs/ioctl.c |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
diff
In support of the recently added capability to remount with lzo
compression, check the compression INCOMPAT flags when remounting
with lzo compression, and set the flags if necessary.
Signed-off-by: Mitch Harder
---
v1-v2:
- Remove extraneous formatting change.
fs/btrfs/ctree.h |1 +
fs
When defragmenting with explicit lzo compression, simplify
the check for lzo INCOMPAT by using the new common function
introduced to support remounting with lzo compression.
Signed-off-by: Mitch Harder
---
fs/btrfs/ioctl.c |7 +--
1 files changed, 1 insertions(+), 6 deletions(-)
diff
on ("btrfs: Allow to specify compress method when defrag")
in ioctl.c.
Based on feedback on IRC, the two patch version presented in the
previous version has been consolidated into a single patch, and
the helper function was converted to a static inline function.
Mitch Harder (1):
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
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_
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
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
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
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
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 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 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 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 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 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 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
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
(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
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
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 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
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 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
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 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 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:
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 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.
Since the 2.6.32 kernel is one of the long-term stable kernels, and
since a few projects (such as OpenVZ) and distros (such as Debian) are
using the 2.6.32 kernel, I've put together an experimental git branch
to backport later btrfs patches to the 2.6.32 kernel.
Let me know if there's any interest
I've been testing this patch (as well as the accompanying patch to btrfs-progs).
It seems to save a decent amount of space (maybe 10-20% according to
df in my testing, YMMV), but I was also noticing a performance penalty
of maybe 5-15%, depending on the application (in my case, I was timing
the un
On Thu, Oct 21, 2010 at 5:09 PM, Diego Calleja wrote:
> On Jueves, 21 de Octubre de 2010 17:46:58 David Nicol escribió:
>> Does this mixing constitute a forbidden change of on-disk format, and
>> if not how not?
>
> It doesn't need a format change. The difference between a data and
> a metadata bl
I was Googling around for ways to check fragmentation on Btrfs, and I
came across the 'filefrag' command.
Even though it is a ext2/3 command, it seems to work on Btrfs files
since it uses the FIEMAP ioctl to determine the number of extents.
>From a bash prompt, I found I could examine large secti
My apologies if I missed it, but this looks like the most recent
version of this patch ([PATCH] Btrfs-progs: add support for mixed
data+metadata block groups V3), and this version needs updating to
take into account that BTRFS_FEATURE_INCOMPAT_SPACE_CACHE is no longer
needed.
The kernel btrfs code
So alot of crazy people (I'm looking at you Meego) want to use btrfs
on phones and such with small devices. Unfortunately the way we split
out metadata/data chunks it makes space usage inefficient for volumes
that are smaller than 1gigabyte. So add a -M option for mixing
metadata+data, and defaul
Update the mkfs.btrfs man page for the -M option to mix data and
metadata chunks.
Signed-off-by: Mitch Harder
---
man/mkfs.btrfs.8.in |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/man/mkfs.btrfs.8.in b/man/mkfs.btrfs.8.in
index 1e14c6c..c23dddc 100644
--- a/man
On Wed, Nov 10, 2010 at 8:10 PM, Josef Bacik wrote:
> On Wed, Nov 10, 2010 at 12:02:18PM -0600, Mitch Harder wrote:
>> Update the mkfs.btrfs man page for the -M option to mix data and
>> metadata chunks.
>>
>> Signed-off-by: Mitch Harder
>> ---
>> man/m
On Fri, Nov 12, 2010 at 4:44 AM, Mike Fedyk wrote:
> On Thu, Nov 11, 2010 at 11:41 PM, Josef Bacik wrote:
>> On Fri, Nov 12, 2010 at 05:47:14PM +1100, Chris Samuel wrote:
>>> On 11/11/10 23:52, Josef Bacik wrote:
>>>
>>> > This feature incurs a performance penalty in larger filesystems, it is
>>>
On Fri, Nov 12, 2010 at 10:56 AM, Mike Fedyk wrote:
> On Fri, Nov 12, 2010 at 6:28 AM, Marek Otahal wrote:
>> On Friday 12 of November 2010 18:44:12 you wrote:
>>> On Thu, Nov 11, 2010 at 11:41 PM, Josef Bacik wrote:
>>> > On Fri, Nov 12, 2010 at 05:47:14PM +1100, Chris Samuel wrote:
>>> >> On 1
Update the mkfs.btrfs man page for the -M option to mix data and
metadata chunks.
---
man/mkfs.btrfs.8.in |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/man/mkfs.btrfs.8.in b/man/mkfs.btrfs.8.in
index 1e14c6c..432db1b 100644
--- a/man/mkfs.btrfs.8.in
+++ b/man/mkfs.
On Mon, Oct 25, 2010 at 9:34 PM, Li Zefan wrote:
> Chris Mason wrote:
>> On Mon, Oct 25, 2010 at 03:11:22PM +0800, Li Zefan wrote:
>>> Lzo is a much faster compression algorithm than gzib, so would allow
>>> more users to enable transparent compression, and some users can
>>> choose from compressi
On Mon, Nov 15, 2010 at 6:57 PM, Li Zefan wrote:
> Mitch Harder wrote:
>> On Mon, Oct 25, 2010 at 9:34 PM, Li Zefan wrote:
>>> Chris Mason wrote:
>>>> On Mon, Oct 25, 2010 at 03:11:22PM +0800, Li Zefan wrote:
>>>>> Lzo is a much faster compression a
I've been getting a compile error when building the 'next-rc' branch
of btrfs-unstable.
CC fs/btrfs/disk-io.o
fs/btrfs/disk-io.c: In function ‘btree_migratepage’:
fs/btrfs/disk-io.c:716: error: called object ‘0u’ is not a function
make[2]: *** [fs/btrfs/disk-io.o] Error 1
make[1]: *** [fs/b
2010/12/29 Miao Xie :
> Hello, Chris
>
> I have a bunch of random fixes of the space management in
>
> git://repo.or.cz/linux-btrfs-devel.git space-manage
>
> They are the ENOSPC fixes, as well as fixes for df command.
> The first one and the last one fixed the wrong free space information reported
2011/1/5 Miao Xie :
> Hello, Chris
>
> I have a bunch of random fixes of the space management in
>
> git://repo.or.cz/linux-btrfs-devel.git space-manage
>
> They are the ENOSPC fixes, as well as fixes for df command.
> The first one and the last one fixed the wrong free space information reported
>
On Tue, Jan 18, 2011 at 9:22 AM, C Anthony Risinger wrote:
> On Tue, Jan 18, 2011 at 4:14 AM, Felix Blanke wrote:
>> Hi,
>>
>> just slap me if the question is stupid, but when will all those new features
>> be added
>> to the btrfs-progs?
>>
>> The last commit is at
>> "git://git.kernel.org/pub/
1 - 100 of 240 matches
Mail list logo
