On Sun, June 30, 2013 at 15:55 (+0200), Josef Bacik wrote:
On Sun, Jun 30, 2013 at 10:25:05AM +0200, Jan Schmidt wrote:
On 30.06.2013 05:17, Josef Bacik wrote:
We need to hold the tree mod log lock in __tree_mod_log_rewind since we walk
forward in the tree mod entries, otherwise we'll end up
On Mon, Jul 01, 2013 at 11:56:30PM +0100, Peter Chant wrote:
Sirs,
my recently slowing file system is now going read only after trying
a defrag or other operation. I'm wondering whether this is the
result of a hardware failure or a btrfs or some other issue. Output
of dmesg:
[snip]
[
On Mon, July 01, 2013 at 22:25 (+0200), Josef Bacik wrote:
Previously we held the tree mod lock when adding stuff because we use it to
check and see if we truly do want to track tree modifications. This is
admirable, but GFP_ATOMIC in a critical area that is going to get hit pretty
hard and
(resent to list)
On Mon, July 01, 2013 at 22:12 (+0200), Josef Bacik wrote:
There is another bug in the tree mod log stuff in that we're calling
tree_mod_log_free_eb every single time a block is cow'ed. The problem with
this
is that if this block is shared by multiple snapshots we will call
This testscript creates reflinks to files on different subvolumes, overwrites
the original files and reflinks, and moves reflinked files between subvolumes.
Originally submitted as testcase 302, changes are made based on comments from
Eric: http://oss.sgi.com/archives/xfs/2013-03/msg00231.html
Thanks Eric for reviewing and improving testcases btrfs/306, 309, 310 and 311 !
I had just one comment: on line 70 the output was redirected to $seqres.fll
instead of $seqres.full. Corrected patch below.
# Check if creating a sparse copy (reflink) of a file on btrfs
# expectedly fails when it's
Seg, 2013-07-01 às 17:50 +0200, Stefan Behrens escreveu:
What you are trying to do is not possible, it is not supported.
Btrfs send/receive can be used to create backups. The use case to
restore from backups is not addressed.
Ok, I see, but then I think I don't understand how btrfs send
On Tue, Jul 02, 2013 at 11:27:51AM +0200, Koen De Wit wrote:
This testscript creates reflinks to files on different subvolumes, overwrites
the original files and reflinks, and moves reflinked files between subvolumes.
Originally submitted as testcase 302, changes are made based on comments
On Tue, 02 Jul 2013 10:56:18 +0100, Miguel Negrão wrote:
Seg, 2013-07-01 às 17:50 +0200, Stefan Behrens escreveu:
What you are trying to do is not possible, it is not supported.
Btrfs send/receive can be used to create backups. The use case to
restore from backups is not addressed.
Ok, I
Dave,
Thanks for the review. I will clean up the commit message and do a full
mail-to-myself-and-test-patch round trip to avoid errors like the wrong test
numbers in the golden output. I'm sorry for this.
About cutting out file names from the output. I did this in the first version
of the
My recent truncate patch uncovered this bug, but I can reproduce it without the
truncate patch. If you mount with -o compress-force, do a direct write to some
area, do a buffered write to some other area, and then do a direct read you will
get the wrong data for where you did the buffered write.
On Tuesday, July 02, 2013 01:00:29 PM Duncan wrote:
Just to be clear, your system, your call. I'd never /dream/ of
interfering with that due to the implications for my own system (which is
certainly highly customized even matched against a peer-group of other
gentoo installs =:^). That
On Jul 2, 2013, at 10:28 AM, Koen De Wit koen.de@oracle.com wrote:
Dave,
Thanks for the review. I will clean up the commit message and do a full
mail-to-myself-and-test-patch round trip to avoid errors like the wrong test
numbers in the golden output. I'm sorry for this.
About
On Sun, Jun 30, 2013 at 2:36 PM, Josef Bacik jba...@fusionio.com wrote:
On Sun, Jun 30, 2013 at 11:29:14AM +0300, Alex Lyakas wrote:
Hi Josef,
On Wed, Jun 26, 2013 at 5:16 PM, Alex Lyakas
alex.bt...@zadarastorage.com wrote:
Hi Josef,
Can you please help me with another question.
I am
That's a good cleanup, please send the kernel version as well.
david
--
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.org/majordomo-info.html
On 07/02/2013 08:29 AM, Hugo Mills wrote:
This is usually an indication that you have bad hardware -- I'd
suggest testing RAM, PSU, CPU in that order. I'm not sure what, if
anything, can be done to fix the error on the disk right now.
Thanks, appreciated.
Hmm. I've got one stick of ram out
On Wed, Jun 26, 2013 at 01:27:08PM +0800, Qu Wenruo wrote:
--- a/btrfs-convert.c
+++ b/btrfs-convert.c
@@ -1802,7 +1802,7 @@ static int prepare_system_chunk_sb(struct
btrfs_super_block *super)
btrfs_set_stack_chunk_num_stripes(chunk, 1);
btrfs_set_stack_chunk_sub_stripes(chunk,
On Tue, Jul 02, 2013 at 06:36:48PM +0100, Peter Chant wrote:
On 07/02/2013 08:29 AM, Hugo Mills wrote:
This is usually an indication that you have bad hardware -- I'd
suggest testing RAM, PSU, CPU in that order. I'm not sure what, if
anything, can be done to fix the error on the disk right
This is similar to a previous fix I sent. 1 gig makes us do mixed file block
groups for btrfs, so these enospc tests will usually fail because we don't have
space for metadata, which is the case for this test. So jack the size up to
1.5gig so that btrfs can do its normal thing and pass the test.
On 07/02/2013 06:48 PM, Hugo Mills wrote:
So the damage probably happened then, if that stick is bad.
Filesystems have this irritating habit of remembering things done to
them across reboots. :) Hugo.
The previous action to the defrag was to delete 48 hours worth of
hourly snapshots. I was
于 2013年07月03日 01:36, David Sterba 写道:
On Wed, Jun 26, 2013 at 01:27:08PM +0800, Qu Wenruo wrote:
--- a/btrfs-convert.c
+++ b/btrfs-convert.c
@@ -1802,7 +1802,7 @@ static int prepare_system_chunk_sb(struct
btrfs_super_block *super)
btrfs_set_stack_chunk_num_stripes(chunk, 1);
于 2013年07月03日 01:26, David Sterba 写道:
That's a good cleanup, please send the kernel version as well.
david
I'll send the kernel patch asap.
--
-
Qu Wenruo
Development Dept.I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
No. 6 Wenzhu
I've upgraded to linux 3.10 and enabled extended inode refs and skinny
metadata extent refs with these commands:
btrfstune -r /dev/sdc1
btrfstune -x /dev/sdc1
Since then, I have WARNING: at fs/btrfs/backref.c:903
find_parent_nodes+0x616/0x815 [btrfs]() showing up like crazy:
# grep -c
On Mon, Jul 01, 2013 at 04:12:27PM -0400, Josef Bacik wrote:
There is another bug in the tree mod log stuff in that we're calling
tree_mod_log_free_eb every single time a block is cow'ed. The problem with
this
is that if this block is shared by multiple snapshots we will call this
multiple
further, you need to free device-label as well.
static int device_list_add(const char *path,
struct btrfs_super_block *disk_super,
u64 devid, struct btrfs_fs_devices **fs_devices_ret)
{
::
device-label = kstrdup(disk_super-label,
Sorry for multiple emails, however looking closely it appears
this will make btrfs_close_devices should be the last thing
in the thread, which means thread can not use the list after
calling btrfs_close_devices(). That would confuse.
Further not all threads using device_list_add()
26 matches
Mail list logo
