Hi Linus,
Geert and James both sent this one in, sorry guys.
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
Geert Uytterhoeven (1) commits (+1/-0):
btrfs/raid56: Add missing #include linux/vmalloc.h
Total: (1) commits (+1/-0)
fs/btrfs/raid56.c | 1 +
1 file
On Sun, Mar 03, 2013 at 06:40:50AM -0700, Alex Lyakas wrote:
Greetings all,
I have an extent tree that looks like follows:
item 22 key (27059916800 EXTENT_ITEM 16384) itemoff 2656 itemsize 24
extent refs 1 gen 164 flags 1
item 23 key (27059916800 EXTENT_ITEM 98304)
On Sun, Mar 03, 2013 at 03:33:30AM -0700, Brendan Hide wrote:
On 2013/02/13 12:33 PM, Holger Hoffstaette wrote:
- raise the leaf size to 16k
- use single metadata profile
...
the difference in behaviour on a single disk is *very* noticeable.
Did you try an isolated change of leaf
On Sun, Mar 03, 2013 at 06:57:41AM -0700, Michael Schmitt wrote:
Hi list,
some rather unexpected btrfs-oopses for my taste. I use btrfs for some
time now (mostly on external harddisks) and these oopses happened
during some simple file and folder deletion operation on that device. It
is a
varargs in __btrfs_std_error (+7/-7)
btrfs: list_entry can't return NULL (+0/-2)
Chris Mason (7) commits (+561/-30):
Btrfs: reduce CPU contention while waiting for delayed extent operations
(+70/-5)
Btrfs: remove conflicting check for minimum number of devices in raid56
(+0/-8)
Btrfs
On Sat, Mar 02, 2013 at 05:45:41PM -0700, Linus Torvalds wrote:
On Sat, Mar 2, 2013 at 7:15 AM, Chris Mason chris.ma...@fusionio.com wrote:
Our set of btrfs features, fixes and cleanups are in my for-linus
branch:
I *really* wish that big pull requests like this would come in earlier
On Fri, Mar 01, 2013 at 08:03:00AM -0700, David Sterba wrote:
The stripe hash table is large, starting with allocation order 4 and can go as
high as order 7 in case lock debugging is turned on and structure padding
happens.
Thanks Dave, I had this on my todo list but it dropped off. We don't
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 fs/btrfs/inode.c:7909
WARNING: at fs/btrfs/inode.c:7911
On Thu, Feb 21, 2013 at 08:20:37AM -0700, Filipe Brandenburger wrote:
Hi Josef,
Please remove the following patch:
Btrfs: move fs/btrfs/ioctl.h to include/uapi/linux/btrfs.h
(55e301fd57a6239ec14b91a1cf2e70b3dd135194 in your btrfs-next.git)
It's not fully cooked and I'm working on a
On Wed, Feb 20, 2013 at 08:35:30AM -0700, Alex Lyakas wrote:
Hi Josef,
can you please consider including these two patches from Jan 28:
https://patchwork.kernel.org/patch/2057051/
https://patchwork.kernel.org/patch/2057071/
I realize they have V2 label, although the cover letter had V3,
into account the number of copies of the data we had but
what they really should be doing is comparing against the logical
size of the chunk we're creating.
This moves the code around a little to use the count of data stripes
from raid5/6.
Signed-off-by: Chris Mason chris.ma...@fusionio.com
diff
On Mon, Feb 18, 2013 at 04:20:58PM -0700, Tony Plack wrote:
Chris and team, hats off on the RAID5/6 being at least experimental.
I have been following your work for a year now, and waiting for these
days.
I am trying to get my head rapped around the architecture for BTRFS
before I jump in
On Wed, Feb 13, 2013 at 06:31:37AM -0700, Chris Mason wrote:
On Wed, Feb 13, 2013 at 06:10:44AM -0700, Richard W.M. Jones wrote:
On Wed, Feb 13, 2013 at 11:00:33AM +, Richard W.M. Jones wrote:
Will try the btrfsprogs patch next.
I applied this patch:
https://git.kernel.org/?p
either. mkfs is putting the super into the
page cache, there's no reason to invalidate at this point.
Signed-off-by: David Sterba dste...@suse.cz
Signed-off-by: Chris Mason chris.ma...@fusionio.com
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 5cbb7f4..5349e17 100644
On Thu, Feb 14, 2013 at 11:30:03AM -0700, Eric Sandeen wrote:
The core of this is shamelessly stolen from xfsprogs.
Use blkid to detect an existing filesystem or partition
table on any of the target devices. If something is found,
require the '-f' option to overwrite it, hopefully avoiding
On Wed, Feb 13, 2013 at 06:10:44AM -0700, Richard W.M. Jones wrote:
On Wed, Feb 13, 2013 at 11:00:33AM +, Richard W.M. Jones wrote:
Will try the btrfsprogs patch next.
I applied this patch:
On Tue, Feb 12, 2013 at 08:16:49AM -0700, Kaspar Schleiser wrote:
Hey Chris,
On 02/02/2013 05:02 PM, Chris Mason wrote:
Btrfs -- 604MB/s
MD-- 162MB/s
MD -- 800MB/s very little system time
Btrfs -- 3.8GB/s one CPU mostly pegged
Btrfs -- 380MB/s seen by fio
MD-- 174MB
On Tue, Feb 12, 2013 at 11:54:49AM -0700, Richard W.M. Jones wrote:
Btrfs has been broken for me for ages. I first reported it on this
list 5 months ago[1]. Below is a very simple reproducer that anyone
can run.
*NB* before you run this, adjust /dev/sda /dev/sda1 to point to an
unused
On Tue, Feb 12, 2013 at 02:05:35PM -0700, Richard W.M. Jones wrote:
Yes, this is inside a very recent KVM (qemu 1.3.0), using virtio-scsi
as the backing disk.
Ok, can you please run this on your virtio device file? It will
overwrite the first 256K, so don't do this on a file you care about.
On Sun, Feb 10, 2013 at 03:35:05PM -0700, Gordon Manning wrote:
Hi,
Is the BTRFS raid code susceptible to RAID-5 write holes? �I think with
the original plan, the problem was avoided by always giving full stripe
writes to the raid layers. �Does the current plan deal with the hole
On Thu, Feb 07, 2013 at 03:12:07AM -0700, Miao Xie wrote:
The deadlock problem happened when running fsstress(a test program in LTP).
Steps to reproduce:
# mkfs.btrfs -b 100M partition
# mount partition mnt
# Path/fsstress -p 3 -n 1000 -d mnt
The reason is:
btrfs_direct_IO()
On Thu, Feb 07, 2013 at 08:52:43AM -0700, Eric Sandeen wrote:
On 2/6/13 6:08 PM, David Sterba wrote:
On Tue, Jan 29, 2013 at 02:41:08PM -0600, Eric Sandeen wrote:
The manpage for the -r option simply says that
it will copy the path specified to -r into the newly
made filesystem.
On Tue, Feb 05, 2013 at 05:49:07PM -0700, Zach Brown wrote:
Hi gang,
Eric and I went through the warnings that a Coverity scan raised against
the reasonably recent btrfs-progs that's in Fedora. We tried to tackle
the lowest hanging fruit: these are the most obvious and least risky
fixes.
in btrfs_delalloc_reserve_metadata
Liu Bo (1) commits (+38/-9):
Btrfs: fix race between snapshot deletion and getting inode
Chris Mason (1) commits (+4/-1):
Btrfs: move d_instantiate outside the transaction during mksubvol
Eric Sandeen (1) commits (+2/-1):
btrfs: don't try to notify udev about
in btrfs_file_aio_write() (+2/-1)
Jan Schmidt (1) commits (+10/-12):
Btrfs: fix EDQUOT handling in btrfs_delalloc_reserve_metadata
Liu Bo (1) commits (+38/-9):
Btrfs: fix race between snapshot deletion and getting inode
Chris Mason (1) commits (+4/-1):
Btrfs: move d_instantiate outside
On Tue, Feb 05, 2013 at 03:16:34AM -0700, Tomasz Kusmierz wrote:
On 16/01/13 09:21, Bernd Schubert wrote:
On 01/16/2013 12:32 AM, Tom Kusmierz wrote:
p.s. bizzare that when I fill ext4 partition with test data everything
check's up OK (crc over all files), but with Chris tool it gets
On Tue, Feb 05, 2013 at 07:22:36AM -0700, Tomasz Torcz wrote:
Hi,
I believe XOR_BLOCKS must be selected, otherwise build fails with:
ERROR: xor_blocks [fs/btrfs/btrfs.ko] undefined!
diff --git a/fs/btrfs/Kconfig b/fs/btrfs/Kconfig
index 4f5dc93..5f583c8 100644
--- a/fs/btrfs/Kconfig
On Mon, Feb 04, 2013 at 02:42:24PM -0700, H. Peter Anvin wrote:
@@ -1389,6 +1392,14 @@ int btrfs_rm_device(struct btrfs_root *root, char
*device_path)
}
btrfs_dev_replace_unlock(root-fs_info-dev_replace);
+ if ((all_avail (BTRFS_BLOCK_GROUP_RAID5 |
+
On Sun, Feb 03, 2013 at 10:34:27AM -0700, Eric Sandeen wrote:
raid6.c was failing to build for Goffredo and me due to
__attribute_const__ being undefined.
Thanks, I've pushed this along with an extra #ifndef into the raid56
experimental branch.
-chris
--
To unsubscribe from this list: send the
Hi Arnd,
First things first, nospace_cache is a safe thing to use. It is slow
because it's finding free extents, but it's just a cache and always safe
to discard. With your other errors, I'd just mount it readonly
and then you won't waste time on atime updates.
I'll take a look at the BUG you
Hi everyone,
I've uploaded an experimental release of the raid5/6 support to git, in
branches named raid56-experimental. This is based on David Woodhouse's
initial implementation (thanks Dave!).
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git
raid56-experimental
On Wed, Jan 30, 2013 at 02:59:05PM -0700, Ilya Dryomov wrote:
On Wed, Jan 30, 2013 at 10:11:44PM +0100, Ian Kumlien wrote:
On Wed, Jan 30, 2013 at 12:33:42PM -0800, Filipe Brandenburger wrote:
Hi Ian,
On Tue, Jan 29, 2013 at 3:03 PM, Ian Kumlien po...@demius.net wrote:
This patch
On Tue, Jan 29, 2013 at 04:13:47AM -0700, Miao Xie wrote:
Hi, everyone.
About 1 years ago, we implemented the chunk tree recover function,
but it has not been applied till now because that implementation
need change the disk format.
(http://marc.info/?l=linux-btrfsm=129914269932543w=2
On Mon, Jan 28, 2013 at 03:03:08PM -0700, David Sterba wrote:
On Mon, Jan 28, 2013 at 03:07:13PM +0100, polack christian wrote:
i did use btrfsck to recover it
i got the tool from
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git
and i got this error message:
...
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 on
btrfs_clean_old_snapshots().
Really nice. Thanks to
On Tue, Jan 22, 2013 at 05:48:33PM -0700, Chris Mason wrote:
Hi Linus,
My for-linus branch has our batch of btrfs fixes:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
We've been hammering away at a crc corruption as well, which I was
really hoping to get
On Thu, Jan 24, 2013 at 03:09:53PM -0700, Goffredo Baroncelli wrote:
On 01/24/2013 08:42 PM, Eric Sandeen wrote:
On 1/24/13 11:57 AM, Goffredo Baroncelli wrote:
On 01/24/2013 10:23 AM, Stefan Behrens wrote:
On Wed, 23 Jan 2013 22:39:29 -0600, Eric Sandeen wrote:
instead of renaming
On Thu, Jan 24, 2013 at 12:42:38PM -0700, Zach Brown wrote:
+ if (sv_id == 5) {
+ printf(%s is btrfs root\n, fullpath);
+ close(fd);
+ close(mntfd);
+ free(mnt);
+ free(fullpath);
+ return 1;
Just wondering, at this point
Hi Linus,
My for-linus branch has our batch of btrfs fixes:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
It turns out that we had two crc bugs when running fsx-linux in a
loop. Many thanks to Josef, Miao Xie, and Dave Sterba for nailing it
all down. Miao also
On Wed, Jan 23, 2013 at 08:21:07AM -0700, David Sterba wrote:
On Wed, Jan 23, 2013 at 12:01:08PM +0100, David Sterba wrote:
Survived a few hours of Chris' test and I'm running the full xfstests
again now.
After 4.5 hours of the same testsuite as before, this popped up in
syslog:
On Tue, Jan 22, 2013 at 07:26:15AM -0700, David Sterba wrote:
On Fri, Jan 04, 2013 at 01:50:59PM +0100, David Sterba wrote:
I've noticed a few csum mismatch messages, and a few failed xfstests:
They're still there, we're on rc4, so I started looking for potential
patches to revert, but
On Thu, Jan 17, 2013 at 10:47:21AM -0700, David Sterba wrote:
Hi Chris,
please pull a few more fixes to the 0.20-rc series. I have reviewed and
verified them where possible. There are the long awaited ARM fixes, help
updates and unsorted code fixes.
On Tue, Jan 15, 2013 at 04:32:10PM -0700, Tom Kusmierz wrote:
Chris all,
Sorry for not replying for that long but Chris old friend stress.sh
have proven that all my storage is affected with this bug and first
thing was to bring everything down before corruptions will spread any
further.
On Mon, Jan 14, 2013 at 04:09:47AM -0700, Tomasz Kusmierz wrote:
Hi,
Since I had some free time over Christmas, I decided to conduct few
tests over btrFS to se how it will cope with real life storage for
normal gray users and I've found that filesystem will always mess up
your files that
On Mon, Jan 14, 2013 at 08:22:36AM -0700, Tomasz Kusmierz wrote:
On 14/01/13 14:59, Chris Mason wrote:
On Mon, Jan 14, 2013 at 04:09:47AM -0700, Tomasz Kusmierz wrote:
Hi,
Since I had some free time over Christmas, I decided to conduct few
tests over btrFS to se how it will cope
On Mon, Jan 14, 2013 at 09:32:25AM -0700, Tomasz Kusmierz wrote:
On 14/01/13 15:57, Chris Mason wrote:
On Mon, Jan 14, 2013 at 08:22:36AM -0700, Tomasz Kusmierz wrote:
On 14/01/13 14:59, Chris Mason wrote:
On Mon, Jan 14, 2013 at 04:09:47AM -0700, Tomasz Kusmierz wrote:
Hi,
Since I
On Mon, Jan 07, 2013 at 04:10:37AM -0700, David Sterba wrote:
Hi,
On Mon, Jan 07, 2013 at 01:51:21AM +0100, Tom Gundersen wrote:
I ran into a bug today with 3.8-rc2 [0], following an make
modules_install make install of the kernel.
I have been using the same kernel without problems
Thanks Dave,
On Fri, Jan 04, 2013 at 05:50:59AM -0700, David Sterba wrote:
Hi,
I've noticed a few csum mismatch messages, and a few failed xfstests:
- 3.8.0-rc1
- defautl mkfs options
- MOUNT_OPTIONS -- -o space_cache,noatime,inode_cache
- test device:40G
- scratch device: 10G
On Wed, Dec 19, 2012 at 10:43:28PM -0700, Steve Leung wrote:
I'm getting some kernel warnings from a btrfs raid1 filesystem that's
serving up nfs4 to a couple of other computers on a small home network.
I ran 3.6.x for several weeks before upgrading and didn't see any warnings
like this.
Hi Linus,
I had missed that for two of the patches in my last pull, we had
included different fixes during 3.7. My for-linus has them reverted:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
Chris Mason (2) commits (+6/-8):
Revert Btrfs
inode_list in __merge_refs
Chris Mason (1) commits (+95/-2):
Btrfs: fix hash overflow handling
Masanari Iida (1) commits (+2/-2):
Btrfs: Fix typo in fs/btrfs
jeff.liu (1) commits (+1/-4):
Btrfs: Remove the invalid shrink size check up from btrfs_shrink_dev()
Total: (115) commits (+5423
to root_item_lock
Alexander Block (1) commits (+11/-2):
Btrfs: merge inode_list in __merge_refs
Chris Mason (1) commits (+95/-2):
Btrfs: fix hash overflow handling
Masanari Iida (1) commits (+2/-2):
Btrfs: Fix typo in fs/btrfs
jeff.liu (1) commits (+1/-4):
Btrfs: Remove the invalid
On Mon, Dec 17, 2012 at 04:09:07PM -0700, Zach Brown wrote:
I was flipping through the code recently and noticed that we still have
the double whammy of allocating dir entry positions with
parent_dir-counter++ and that weird setting of f_pos to 2^31-1.
So after enough creates (and deletes
On Mon, Dec 17, 2012 at 04:50:39PM -0700, Zach Brown wrote:
On Mon, Dec 17, 2012 at 06:28:40PM -0500, Chris Mason wrote:
On Mon, Dec 17, 2012 at 04:09:07PM -0700, Zach Brown wrote:
1) The fundamental fix is to re-use deleted entry positions. Do we add
another cache to index unlinked
On Mon, Dec 17, 2012 at 06:33:24AM -0700, Alexander Block wrote:
I did some research on deduplication in the past and there are some
problems that you will face. I'll try to list some of them (for sure
not all).
Thanks Alexander for writing all of this up. There are a lot of great
points
On Thu, Dec 13, 2012 at 03:07:27PM -0700, Chris Mason wrote:
On Thu, Dec 13, 2012 at 02:34:30PM -0700, David Sterba wrote:
On Thu, Dec 13, 2012 at 03:52:08PM -0500, Chris Mason wrote:
Thanks for taking the time to write this up. As far as I can tell, the
looping was actually fixed
On Wed, Dec 12, 2012 at 04:41:50PM -0700, Zach Brown wrote:
On Thu, Dec 13, 2012 at 04:50:54AM +0530, Nirbheek Chauhan wrote:
On Thu, Dec 13, 2012 at 4:21 AM, Hugo Mills h...@carfax.org.uk wrote:
Two things:
*nod*
I think Zach was asking about the userspace tools, not the kernel
[ adding linux-btrfs ]
On Thu, Dec 13, 2012 at 05:56:37AM -0700, Pascal Junod wrote:
Hello folk,
The btrfs file system, part of the linux kernel, is vulnerable to a
trivial hash-DoS attack. More details can be found here:
http://crypto.junod.info/2012/12/13/hash-dos-and-btrfs/
Hi Pascal,
On Thu, Dec 13, 2012 at 12:50:40PM -0700, Zach Brown wrote:
On Thu, Dec 13, 2012 at 09:56:10AM -0500, Chris Mason wrote:
Yes, I've got the big raid56 push ready to go out, and I've just been
trying to test it all. I'll put that in a raid branch and get the fixes
onto master.
Thanks
On Thu, Dec 13, 2012 at 02:34:30PM -0700, David Sterba wrote:
On Thu, Dec 13, 2012 at 03:52:08PM -0500, Chris Mason wrote:
Thanks for taking the time to write this up. As far as I can tell, the
looping was actually fixed in an older kernel and I just misread our
version string in your
On Mon, Dec 03, 2012 at 12:34:06AM -0700, Chris Murphy wrote:
When creating a btrfs volume with mkfs.btrfs, I'm noticing that the
first 64KB are completely blank. Is this gap expressly intended for
installing a boot manager/loader? e.g. GRUB 2 allows installation of
boot.img + core.img into a
On Tue, Nov 20, 2012 at 06:34:13AM -0700, Jan Schmidt wrote:
I found a race condition in the way scrub interacts with btrfs workers:
Please carefully distinguish workers as struct btrfs_workers from worker
as
struct btrfs_worker_thread.
Process A: umount
Process B: scrub-workers
On Tue, Nov 06, 2012 at 09:38:18AM -0700, Stefan Behrens wrote:
This patch series adds support for replacing disks at runtime.
It replaces the following steps in case a disk was lost:
mount ... -o degraded
btrfs device add new_disk
btrfs device delete missing
Or in case a
On Thu, Nov 01, 2012 at 06:34:54AM -0600, Josef Bacik wrote:
A user reported a problem where all of his block groups had invalid used
counts in the block group item. This patch walks the extent tree and counts
up the used amount for each block group. If the user specifies repair we
can set
On Sat, Oct 27, 2012 at 04:28:41AM -0600, Liu Bo wrote:
This feature works on our crucial write endio path, so if we've got
lots of fragments to process, it will be kind of a disaster to the
performance, so I make such a change.
One can benifit from it while mounting with '-o
On Thu, Nov 01, 2012 at 09:01:24AM -0600, Jan Schmidt wrote:
Hi everybody,
We made a bad mistake with btrfs send command line arguments and we'd
better fix it before it's being widely used (read: *now*).
Ok, I do agree that -i was confusing. I didn't end up using it in my
backup scripts
On Thu, Nov 01, 2012 at 09:48:25AM -0600, Jan Schmidt wrote:
On Thu, November 01, 2012 at 16:07 (+0100), Chris Mason wrote:
On Thu, Nov 01, 2012 at 09:01:24AM -0600, Jan Schmidt wrote:
Hi everybody,
We made a bad mistake with btrfs send command line arguments and we'd
better fix
On Fri, Oct 26, 2012 at 12:35:43AM -0600, Jan Schmidt wrote:
Hi,
while running extensive qgroup and tree mod log tests I got to the following
BUG, which is probably not related to tree mod log:
So our keys are out of order...are you able to reproduce this?
-chris
--
To unsubscribe from this
On Fri, Oct 26, 2012 at 06:30:06AM -0600, Jan Schmidt wrote:
On Fri, October 26, 2012 at 14:19 (+0200), Chris Mason wrote:
On Fri, Oct 26, 2012 at 12:35:43AM -0600, Jan Schmidt wrote:
Hi,
while running extensive qgroup and tree mod log tests I got to the
following
BUG, which
Hi Linus,
My for-linus branch:
git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus
Has our series of fixes for the next rc. The biggest batch is from Jan
Schmidt, fixing up some problems in our subvolume quota code and fixing
btrfs send/receive to work with the new
On Mon, Oct 22, 2012 at 12:41:49AM -0600, Arne Jansen wrote:
On 15.10.2012 16:32, Chris Mason wrote:
On Sat, Oct 13, 2012 at 09:41:28AM -0600, David Sterba wrote:
On Sat, Oct 13, 2012 at 09:08:57AM +0100, Rory Campbell-Lange wrote:
Perhaps BTRFS Incremental Stream or Backup Incremental
On Thu, Oct 18, 2012 at 05:29:50AM -0600, Marguerite Su wrote:
Hi, all,
I ran into a situation that no useful information can be found over
the internet...
I'm using 3.6.2 + btrfs git compiled using dkms, and I have a 300GB
btrfs /home and 50GB btrfs /:
Usually when btrfs is slow to
On Sat, Oct 13, 2012 at 09:41:28AM -0600, David Sterba wrote:
On Sat, Oct 13, 2012 at 09:08:57AM +0100, Rory Campbell-Lange wrote:
Perhaps BTRFS Incremental Stream or Backup Incremental Stream should
be considered, with the file extension .bis.
From the brainstorming we had about the name,
On Thu, Oct 11, 2012 at 01:28:21AM -0600, Richard W.M. Jones wrote:
Well the bad news is that the bug happened again overnight, even
though we were definitely using btrfs-progs with the 6eba90029 patch
added, _and_ it was doing a sync + fsync between the mkfs and the
mount.
This is good just
On Thu, Oct 11, 2012 at 02:43:48AM -0600, Sergei Trofimovich wrote:
From: Sergei Trofimovich sly...@gentoo.org
[from 0.20-rc1 tarball]
Before the patch:
$ ./btrfs --version
Btrfs Btrfs v0.19
After the patch:
$ ./btrfs --version
Btrfs v0.20-rc1
Thanks!
-chris
--
To
On Tue, Oct 09, 2012 at 03:00:12AM -0600, David Sterba wrote:
On Tue, Oct 09, 2012 at 08:33:57AM +0100, Richard W.M. Jones wrote:
On Tue, Oct 09, 2012 at 08:20:02AM +0100, Richard W.M. Jones wrote:
On Mon, Oct 08, 2012 at 08:00:51PM -0400, Chris Mason wrote:
Ok, what's a rough idea
On Wed, Oct 10, 2012 at 01:38:53PM -0600, Richard W.M. Jones wrote:
On Wed, Oct 10, 2012 at 08:38:08AM -0400, Chris Mason wrote:
On Tue, Oct 09, 2012 at 03:00:12AM -0600, David Sterba wrote:
On Tue, Oct 09, 2012 at 08:33:57AM +0100, Richard W.M. Jones wrote:
On Tue, Oct 09, 2012 at 08:20
On Mon, Oct 08, 2012 at 07:26:15AM -0600, Wang Sheng-Hui wrote:
In csum_dirty_buffer, we first get eb from page-private.
Then we check if the page is the first page of eb. Later
we check it again. Remove the repeated check here.
You had the right idea here, two checks and one has a warning, so
inode ref iteration (+138/-37)
btrfs: extended inode refs (+710/-79)
Wei Yongjun (2) commits (+3/-6):
Btrfs: fix possible memory leak in scrub_setup_recheck_block() (+1/-0)
Btrfs: using for_each_set_bit_from to simplify the code (+2/-6)
Chris Mason (2) commits (+38/-16):
Btrfs: fix
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 Mon, Sep 17, 2012 at 4:58 AM, Liu Bo bo.li@oracle.com wrote:
This comes from one
On Mon, Oct 08, 2012 at 08:16:42AM -0600, Richard W.M. Jones wrote:
I'm tracking this bug here:
https://bugzilla.redhat.com/show_bug.cgi?id=863978
Since approx. last week I'm seeing lots of failures in btrfs. The
common factor seems to be that the filesystem is created (mkfs.btrfs
On Mon, Oct 08, 2012 at 08:17:13AM -0600, Christian Hesse wrote:
Hello everybody,
man pages for btrfs-progs are compressed by gzip by default. In Makefile the
variable GZIP is use, this evaluates to 'gzip gzip' on my system. From man
gzip:
The environment variable GZIP can hold a set of
On Mon, Oct 08, 2012 at 08:30:31AM -0600, Christian Hesse wrote:
Chris Mason chris.ma...@fusionio.com on Mon, 2012/10/08 10:29:
On Mon, Oct 08, 2012 at 08:17:13AM -0600, Christian Hesse wrote:
Hello everybody,
man pages for btrfs-progs are compressed by gzip by default. In Makefile
On Mon, Oct 08, 2012 at 08:57:30AM -0600, Richard W.M. Jones wrote:
On Mon, Oct 08, 2012 at 10:27:57AM -0400, Chris Mason wrote:
On Mon, Oct 08, 2012 at 08:16:42AM -0600, Richard W.M. Jones wrote:
I'm tracking this bug here:
https://bugzilla.redhat.com/show_bug.cgi?id=863978
On Mon, Oct 08, 2012 at 09:15:14AM -0600, Richard W.M. Jones wrote:
On Mon, Oct 08, 2012 at 11:04:19AM -0400, Chris Mason wrote:
On Mon, Oct 08, 2012 at 08:57:30AM -0600, Richard W.M. Jones wrote:
On Mon, Oct 08, 2012 at 10:27:57AM -0400, Chris Mason wrote:
On Mon, Oct 08, 2012 at 08:16
On Mon, Oct 08, 2012 at 03:22:30PM -0600, Richard W.M. Jones wrote:
I have now reproduced this bug locally.
Adding sync() + fsync of each /dev/sd* device after the mkfs command
does appear to fix the problem.
However it's a little bit difficult to know for sure because I might
just be
On Fri, Oct 05, 2012 at 06:51:59AM -0600, Josef Bacik wrote:
On Fri, Aug 10, 2012 at 07:38:35AM -0600, Stefan Behrens wrote:
So far the return code of barrier_all_devices() is ignored, which
means that errors are ignored. The result can be a corrupt
filesystem which is not consistent.
wrong.
Can you see any reason for EIOs to come back from cache flushes when we
might not want to declare a metadata emergency?
[ more context below ]
-chris
On Fri, Oct 05, 2012 at 08:05:13AM -0600, Stefan Behrens wrote:
On Fri, 5 Oct 2012 09:09:11 -0400, Chris Mason wrote:
On Fri, Oct 05
On Wed, Oct 03, 2012 at 12:22:06AM -0600, Goffredo Baroncelli wrote:
On Wed, Oct 3, 2012 at 1:46 AM, Chris Mason chris.ma...@fusionio.com wrote:
[...]
I like it, thanks. Could you please update btrfs fi df to show this
instead of adding a new command though?
Hi Chris,
no problem
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 bo.li@oracle.com wrote:
This comes from one of btrfs's project ideas,
As we defragment files, we break any sharing from other snapshots.
The
On Tue, Oct 02, 2012 at 12:36:08PM -0600, Goffredo Baroncelli wrote:
Hi all,
This serie of patches adds a new command called btrfs filesystem
disk-usage. I added this command because it is not so easy to get
the information about the disk usage from the command fi df and fi show.
From the
On Tue, Oct 02, 2012 at 05:27:07AM -0600, David Sterba wrote:
Hi Chris,
please pull a few fixes to the 0.20-rc series, these are easy to review and
fix
problems that people reported. There are more fixes in the mailinglist, but
they do not IMHO fit current -rc period, the crowd is waiting
On Tue, Sep 18, 2012 at 04:35:25AM -0600, Miao Xie wrote:
We want 'btrfs subvolume list' only to list readonly subvolumes, this patch
set
introduces a new option 'r' to implement it.
You can use the command like that:
btrfs subvolume list -r mnt
Changelog v3 - v4:
- modify the
On Thu, Aug 02, 2012 at 04:14:37AM -0600, Miao Xie wrote:
From: Chen Yang chenyang.f...@cn.fujitsu.com
This patch adds the function to check correspondence between block group,
chunk and device extent.
Excellent, thank you. Could you please put this into a git tree? I'm
having trouble with
On Mon, Aug 20, 2012 at 02:29:17PM -0600, Mark Fasheh wrote:
Testing wise, the basic namespace operations work well (link, unlink, etc).
The rest has gotten less debugging (and I really don't have a great way of
testing the code in tree-log.c) Attached to this e-mail are btrfs-progs
patches
On Mon, Sep 24, 2012 at 12:19:20PM -0600, Arne Jansen wrote:
On 09/24/12 20:11, Josef Bacik wrote:
The reason we offload csumming is because it is CPU intensive, except it is
not on modern intel CPUs. So check to see if we support hardware crc32c,
and if we do just do the csumming in our
On Mon, Sep 17, 2012 at 02:45:08AM -0600, Casper Bang wrote:
Abstract
For database testing purposes, a COW filesystem was needed in order to
facilitate snapshotting and rollback, such as to provide mirrors of
our production database at fixed intervals (every night and by
demand).
Thanks for
On Mon, Sep 17, 2012 at 10:25:54AM -0600, Alan Cox wrote:
ctree.c:btrfs_insert_some_items()
{
...
if (total_size + data_size[i]+ ...
{
break;
nr = i;
}
Hi Alan,
Definitely not right ;) It's
.
Chris Mason (1):
Revert Btrfs: fix some error codes in btrfs_qgroup_inherit()
fs/btrfs/qgroup.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More
On Tue, Sep 04, 2012 at 08:23:20AM -0600, Christophe Varoqui wrote:
Hi list,
OpenSVC = 120904.1516 now contains a replication driver for the btrfs
send/receive mecanism. This new driver adds up to the zfs, rsync, dds,
netapp, datacore and drbd existing drivers.
It is no more mature than
901 - 1000 of 2192 matches
Mail list logo
