Hi Alex,
On Mon, January 28, 2013 at 17:11 (+0100), Alex Lyakas wrote:
> Hi Jan,
> I have a set of unit tests (part of the larger system) for the
> send-receive functionality, with which I am able to hit this error:
>
> Jan 28 18:01:00 687-dev kernel: [16968.451358] btrfs: ERROR did not
> find ba
fs_info->generation is a 64bit variant, and it can be accessed by
multi-task, if there is no lock or other methods to protect it, we
might get the wrong number, especially on 32bit machine.
For example, Assuming ->generation is 0x at the
beginning, then we increase it by 1, ->ge
fs_info->last_trans_committed is a 64bit variant, and it can be
accessed by multi-task, if there is no lock or other methods to
protect it, we might get the wrong number, especially on 32bit
machine.(Even on 64bit machine, it is possible that the compiler
may split a 64bit operation into two 32bit
fs_info->last_trans_log_full_commit is a 64bit variant, and it
can be accessed by multi-task, if there is no lock or other methods
to protect it, we might get the wrong number, especially on 32bit
machine.(Even on 64bit machine, it is possible that the compiler
may split a 64bit operation into two
Though ->max_inline is a 64bit variant, and may be accessed by
multi-task, but it is just suggestive number, so we needn't add
anything to protect fs_info->max_inline, just add a comment to
explain wny we don't use a lock to protect it.
Signed-off-by: Miao Xie
---
Changelog v1 -> v2:
- modify the
fs_info->alloc_start is a 64bits variant, can be accessed by
multi-task, but it is not protected strictly, it can be changed
while we are accessing it. On 32bit machine, we will get wrong
value because we access it by two instructions.(In fact, it is
also possible that the same problem happens on t
->dirty_metadata_bytes is accessed very frequently, so use percpu
counter instead of the u64 variant to reduce the contention of
the lock.
This patch also fixed the problem that we access it without
lock protection in __btrfs_btree_balance_dirty(), which may
cause we skip the dirty pages flush.
S
fs_info->delalloc_bytes is accessed very frequently, so use percpu
counter instead of the u64 variant for it to reduce the lock
contention.
This patch also fixed the problem that we access the variant
without the lock protection.At worst, we would not flush the
delalloc inodes, and just return ENO
We need not use a global lock to protect the delalloc_bytes of the
inode, just use its own lock. In this way, we can reduce the lock
contention and ->delalloc_lock will just protect delalloc inode
list.
Signed-off-by: Miao Xie
---
Changelog v1 -> v2:
- none.
---
fs/btrfs/btrfs_inode.h | 1 +
fs
There is no lock to protect
fs_info->avail_{data, metadata, system}_alloc_bits,
it may introduce some problem, such as the wrong profile
information, so we add a seqlock to protect them.
Signed-off-by: Zhao Lei
Signed-off-by: Miao Xie
---
Changelog v1 -> v2:
- none.
---
fs/btrfs/ctree.h
There is no lock to protect fs_info->fs_state, it will introduce
some problems, such as the value may be covered by the other task
when several tasks modify it. For example:
Task0 - CPU0Task1 - CPU1
mov %fs_state rax
or $0x1 rax
mo
On Tue, 29 Jan 2013 14:24:13 +0800, Jeff Liu wrote:
> Clean btrfslabel.[c|h] out of the source tree and move those related
> functions to utils.[c|h].
>
> Signed-off-by: Jie Liu
> CC: David Sterba
> CC: Gene Czarcinski
> ---
> Makefile |4 +-
> btrfslabel.c | 178
>
On 01/29/2013 06:26 PM, Stefan Behrens wrote:
> On Tue, 29 Jan 2013 14:24:13 +0800, Jeff Liu wrote:
>> Clean btrfslabel.[c|h] out of the source tree and move those related
>> functions to utils.[c|h].
>>
>> Signed-off-by: Jie Liu
>> CC: David Sterba
>> CC: Gene Czarcinski
>> ---
>> Makefile
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-btrfs&m=129914269932543&w=2
http://marc.info/?l=linux-btrfs&m=130976668006281&w=2
http://marc.
Hi,
> To improve the code reuse its better to have btrfs_list_subvols
> just return list of subvols witout printing
>
> Signed-off-by: Anand Jain
> ---
> btrfs-list.c | 28 ++--
> btrfs-list.h | 2 +-
> cmds-subvolume.c | 4 ++--
> 3 files changed, 21 insertions(
Hi Eric,
On Fri, Jan 25, 2013 at 5:57 PM, Eric Sandeen wrote:
> It looks to me like the logic in these two if statements are
> overlapping.
>
> The test for flags & BTRFS_BLOCK_GROUP_SYSTEM in the 2nd case
> should never get triggered, because it would have triggered
> on the first case, right?
>
On Mon, Jan 28, 2013 at 07:30:09PM -0700, Liu Bo wrote:
> On Mon, Jan 28, 2013 at 04:23:31PM -0500, Josef Bacik wrote:
> > On Thu, Jan 03, 2013 at 11:44:46AM -0700, Jim Schutt wrote:
> > > Hi Josef,
> > >
> > > Thanks for the patch - sorry for the long delay in testing...
> > >
> >
> > Jim,
> >
On Tue, Jan 29, 2013 at 08:47:30AM -0500, Josef Bacik wrote:
> On Mon, Jan 28, 2013 at 07:30:09PM -0700, Liu Bo wrote:
> > On Mon, Jan 28, 2013 at 04:23:31PM -0500, Josef Bacik wrote:
> > > On Thu, Jan 03, 2013 at 11:44:46AM -0700, Jim Schutt wrote:
> > > > Hi Josef,
> > > >
> > > > Thanks for the
On Tue, Jan 29, 2013 at 12:31:53AM +0100, Ian Kumlien wrote:
> This means that dists are striping binaries...
> In which case it would be no problem to have then build the static target,
> perhaps we could try to verify if they are available and build btrfs.static
> and btrfsck.static if possible..
On Mon, Jan 28, 2013 at 05:12:12PM -0700, Sage Weil wrote:
> A ceph user observed a incorrect i_size on btrfs. The pattern looks like
> this:
>
> - some writes at low file offsets
> - a write to 4185600 len 8704 (i_size should be 4MB)
> - more writes to low offsets
> - a write to 4181504 len 409
On Tue, Jan 29, 2013 at 02:24:12PM +0800, Jeff Liu wrote:
> --- a/utils.c
> +++ b/utils.c
> @@ -1122,17 +1122,21 @@ char *pretty_sizes(u64 size)
>-1if the label is too long
>-2if the label contains an invalid character
> */
> -int check_label(char *input)
> +static int che
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-btrfs&m=129914269932543&w=
i know that the proposed ctree.c file is from a kernel source but
btrfsck is user space only, since the btrfs-next is newer than
btrfs-prog i was hoping for a commit of this change for the user-space
version.
since this file-system have been created prior kernel 3.2 there is no
tree root backup
btrfs can use generic_file_read_iter(). Base btrfs_file_write_iter()
on btrfs_file_aio_write(), then have the latter call the former.
Signed-off-by: Dave Kleikamp
Cc: Zach Brown
Cc: Chris Mason
Cc: linux-btrfs@vger.kernel.org
---
fs/btrfs/file.c | 42 ++
On Tue, Jan 29, 2013 at 08:50:34AM -0500, Josef Bacik wrote:
> On Tue, Jan 29, 2013 at 08:47:30AM -0500, Josef Bacik wrote:
> > 251 [not run] FSTRIM is not supported
> >
> > Are you sure its 251? Thanks,
>
> Sorry it's early, I need a device that does trim. /me waits for his fusion
> card
On Tue, Jan 29, 2013 at 05:43:31PM +0100, David Sterba wrote:
> On Tue, Jan 29, 2013 at 08:50:34AM -0500, Josef Bacik wrote:
> You can use scsi_debug device with
>
> parm: lbpu:enable LBP, support UNMAP command (def=0) (int)
Also, loop device with a file backed by a filesystem with hole
On 01/29/2013 11:19 PM, David Sterba wrote:
> On Tue, Jan 29, 2013 at 02:24:12PM +0800, Jeff Liu wrote:
>> --- a/utils.c
>> +++ b/utils.c
>> @@ -1122,17 +1122,21 @@ char *pretty_sizes(u64 size)
>>-1if the label is too long
>>-2if the label contains an invalid character
>>
On 01/28/2013 02:23 PM, Josef Bacik wrote:
> On Thu, Jan 03, 2013 at 11:44:46AM -0700, Jim Schutt wrote:
>> Hi Josef,
>>
>> Thanks for the patch - sorry for the long delay in testing...
>>
>
> Jim,
>
> I've been trying to reason out how this happens, could you do a btrfs fi df on
> the filesystem
On Tue, Jan 29, 2013 at 11:41:10AM -0700, Jim Schutt wrote:
> On 01/28/2013 02:23 PM, Josef Bacik wrote:
> > On Thu, Jan 03, 2013 at 11:44:46AM -0700, Jim Schutt wrote:
> >> Hi Josef,
> >>
> >> Thanks for the patch - sorry for the long delay in testing...
> >>
> >
> > Jim,
> >
> > I've been tryin
Commit 605e806166847872bb91831b397d58f95027975a broke the
mkfs.btrfs -r option, because it calls make_btrfs
without ever setting dev_block_count, in the -r case,
so we tell it to make a filesystem of size 0.
Then we wander into ENOSPC land and segfault.
As a quick one-line-fix, just set the dev_b
On 01/29/2013 01:04 PM, Josef Bacik wrote:
> On Tue, Jan 29, 2013 at 11:41:10AM -0700, Jim Schutt wrote:
>> On 01/28/2013 02:23 PM, Josef Bacik wrote:
>>> On Thu, Jan 03, 2013 at 11:44:46AM -0700, Jim Schutt wrote:
Hi Josef,
Thanks for the patch - sorry for the long delay in testing.
The manpage for the "-r" option simply says that
it will copy the path specified to -r into the newly
made filesystem.
There's not a lot of reason to treat that option as differently
as it is now - today it ignores discard, fs size, and mixed
options, for example. It also failed to check whether
On 01/29/2013 01:04 PM, Josef Bacik wrote:
> On Tue, Jan 29, 2013 at 11:41:10AM -0700, Jim Schutt wrote:
>> > On 01/28/2013 02:23 PM, Josef Bacik wrote:
>>> > > On Thu, Jan 03, 2013 at 11:44:46AM -0700, Jim Schutt wrote:
> >> Hi Josef,
> >>
> >> Thanks for the patch - sorry for the l
NOTE: in order to apply this patch you should:
git mv btrfsck.c cmd-fsck.c
This patch moves btrfsck in to "btrfs fsck".
It also adds support for symlinks to the btrfs binary to
retain compablity, =)
I think something should be done to the help description but i'm not
sure what... Anyway,
This patch includes fsck as a subcommand of btrfs, but if you rename
the binary to btrfsck (or, preferably, use a symlink) it will act like
the old btrfs command.
It will also handle fsck.btrfs which currently is a noop.
---
Makefile| 4 ++--
btrfs.c | 68
Hi,
a few build warning fixes, unaligned access fix #2 and finally support
for the 'device stats' and device 'replace' commands!
Please test, worked for me here, but not tested extensively. If
everything goes well I'll send a pull request with this branch in a few
days.
git://repo.or.cz/btrfs-
On Wed, Jan 30, 2013 at 01:24:28AM +0100, David Sterba wrote:
> git://repo.or.cz/btrfs-progs-unstable/devel.git integration-20130130
>
> (top commit 78b35a43988163dbf71d9)
Shortlog:
Anand Jain (1):
Btrfs-progs: move open_file_or_dir() to utils.c
Ben Peddell (1):
btrfs-progs: fix u
37 matches
Mail list logo
