Wang Shilong | 26 Jul 18:49 2014
Picon

[PATCH] Btrfs-progs: fix some build warnings on 32bit platform

Fix following build warnings on 32bit platform:

...
utils.c:1708:3: warning: left shift count >= width of
type [enabled by default]
   if (x << i & (1UL << 63))
   ^
qgroup-verify.c:393:9: warning: cast to pointer from integer
of different size [-Wint-to-pointer-cast]
  return (struct tree_block *)unode->aux;
         ^
qgroup-verify.c:407:38: warning: cast from pointer to integer
of different size [-Wpointer-to-int-cast]
   if (ulist_add(tree_blocks, bytenr, (unsigned long long)block, 0) >= 0)
                                      ^
cmds-restore.c:120:4: warning: format %lu expects argument of type
long unsigned int, but argument 3 has type size_t [-Wformat=]
    fprintf(stderr, "bad compress length %lu\n", in_len);
...

BTW, this patch also switches other castings with new helpers.

Signed-off-by: Wang Shilong <wangshilong1991 <at> gmail.com>
---
 cmds-inspect.c  | 4 ++--
 cmds-restore.c  | 2 +-
 extent-tree.c   | 3 +--
 kerncompat.h    | 4 ++++
 qgroup-verify.c | 4 ++--
 utils.c         | 2 +-
(Continue reading)

Nick Krause | 26 Jul 01:16 2014
Picon

Help with Project on brtfs wiki

Hey brtfs devolopers.
I am new so I think this project,Implement new FALLOC_FL_* modes needs
more information for me to
write if for you guys. I am wondering what is fallocate and how you
want me to write this, define statements
or as functions in a certain file? I am not asking to hold my hand
just point me to some documentation somewhere
and I will read it when I have time as I am working on directory speed
work for ext4.
Cheers Nick
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Anand Jain | 25 Jul 14:33 2014
Picon

[PATCH not for integration] btrfs-devlist: dumps btrfs_device and btrfs_fs_devices from kernel

This would dump the following info:

fs_address dev_address dev_root_addr root_fsid
fsid name uuid (seed_fsid <at> seed_addr sprout_fsid <at> sprout_addr) 
	(fs_num_devices fs_open_devices fs_rw_devices fs_missing_devices fs_total_devices)
fs_total_rw_bytes fs_num_can_discard
	devid gen total_bytes disk_total_bytes bytes_used type io_align io_width sector_size fmode 
	not_fs_Mounted|not_fs_Seeding|not_fs_Rotating
	not_Writable|not_MD|not_Missing|not_Discard|not_Replace_tgt|not_Run_pending|not_Nobarriers|not_Stat_valid|not_Bdev

Applies on Chris integration branch now

Anand Jain (1):
  btrfs: introduce BTRFS_IOC_GET_DEVS

 fs/btrfs/super.c           |  86 +++++++++++++++++++++++++++
 fs/btrfs/volumes.c         | 145 +++++++++++++++++++++++++++++++++++++++++++++
 fs/btrfs/volumes.h         |   3 +
 include/uapi/linux/btrfs.h |  53 ++++++++++++++++-
 4 files changed, 286 insertions(+), 1 deletion(-)

Anand Jain (1):
  btrfs-progs: introduce btrfs-devlist

 .gitignore      |   1 +
 Makefile        |   4 +-
 btrfs-devlist.c | 268 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 ioctl.h         |  52 +++++++++++
 4 files changed, 323 insertions(+), 2 deletions(-)
 create mode 100644 btrfs-devlist.c
(Continue reading)

Torbjørn | 25 Jul 13:37 2014

Re: BTRFS hang with 3.16-rc5 (and also with 3.16-rc4)

On 25. juli 2014 13:09, Torbjørn wrote:
> On 25. juli 2014 12:22, Torbjørn wrote:
>> On 25. juli 2014 11:28, Liu Bo wrote:
>>> Hi Torbjørn,
>>>
>>> On Fri, Jul 25, 2014 at 06:51:44AM +0200, Torbjørn wrote:
>>>> On 07/24/2014 04:58 PM, Chris Mason wrote:
>>>>> <snip>
>>>>> Liu Bo has a promising patch:
>>>>>
>>>>> https://patchwork.kernel.org/patch/4618421/
>>>>>
>>>>> Please give it a shot.  There's a second deadlock reading the free 
>>>>> space
>>>>> cache, I'm still working on that one too.
>>>>>
>>>>> -chris
>>>> I (as expected, my hang was with free space cache) still get hangs
>>>> with this applied on top of 3.16-rc6.
>>>> Looking forward to the free space cache patch.
>>>>
>>>> I have not been able to trigger the same hang as I had with 3.15 on
>>>> any of the 3.16-rc6 kernels so far.
>>> Seems that you can run into the hang quite stably, I have a stupid 
>>> debugging
>>> patch here with adding a WARN_ON() to __load_free_space_inode(), 
>>> would you
>>> please give it a shot and show us the output of dmesg?
>>>
>>> (This may make 'dmesg' a mess, but it will show who the hell holds 
(Continue reading)

Torbjørn | 25 Jul 12:22 2014

Re: BTRFS hang with 3.16-rc5 (and also with 3.16-rc4)

On 25. juli 2014 11:28, Liu Bo wrote:
> Hi Torbjørn,
>
> On Fri, Jul 25, 2014 at 06:51:44AM +0200, Torbjørn wrote:
>> On 07/24/2014 04:58 PM, Chris Mason wrote:
>>> <snip>
>>> Liu Bo has a promising patch:
>>>
>>> https://patchwork.kernel.org/patch/4618421/
>>>
>>> Please give it a shot.  There's a second deadlock reading the free space
>>> cache, I'm still working on that one too.
>>>
>>> -chris
>> I (as expected, my hang was with free space cache) still get hangs
>> with this applied on top of 3.16-rc6.
>> Looking forward to the free space cache patch.
>>
>> I have not been able to trigger the same hang as I had with 3.15 on
>> any of the 3.16-rc6 kernels so far.
> Seems that you can run into the hang quite stably, I have a stupid debugging
> patch here with adding a WARN_ON() to __load_free_space_inode(), would you
> please give it a shot and show us the output of dmesg?
>
> (This may make 'dmesg' a mess, but it will show who the hell holds the free
> space inode's page just at the time before hang)
>
> thanks,
> -liubo
>
(Continue reading)

Hugo Mills | 25 Jul 11:13 2014
Picon

Re: BTRFS hang with 3.16-rc5 (and also with 3.16-rc4)

[this time, to the mailing list as well]

On Fri, Jul 25, 2014 at 09:02:44AM +0100, Hugo Mills wrote:
> On Thu, Jul 24, 2014 at 11:06:34PM -0400, Nick Krause wrote:
> > On Thu, Jul 24, 2014 at 10:32 PM, Duncan <1i5t5.duncan <at> cox.net> wrote:
> [snip]
> > Hey Duncan and others ,
> > I have read this and this seems to need some working on.
> > If you want my help please ask , I am new to the kernel
> > so I may ask a dumb question or two but if that's fine with
> > you I have no problem helping out here. I would like
> > a log of printk statements leading to the hand if that's
> > not too much work in order for me to trace this back.
> 
>    Note that btrfs is complex -- there's something around 100k lines
> of code in it. My first piece of kernel work in btrfs was simply
> documenting the way that the on-disk data structures related to each
> other[1]. That on its own took me two to three weeks of solid
> full-time effort, reading the code to find where each structure was
> used and how its elements related to other structures. You can't just
> wander up and dive in without putting in the effort of learning first.
> Whilst people will help you (come over to #btrfs on Freenode for more
> real-time interaction), they can't do the basic work of sitting down
> and understanding the code in detail for you.
> 
>    Chris, who designed and wrote the filesystem, has spent the last
> couple of weeks tracking down this particular problem. Do you think
> it's appropriate to leap into the middle of the discussion on this
> subtle bug as someone with absolutely no experience in the area?
> 
(Continue reading)

Satoru Takeuchi | 25 Jul 10:07 2014

[PATCH] btrfs: use IS_ALIGNED() for assertion in btrfs_lookup_csums_range() for simplicity

From: Satoru Takeuchi <takeuchi_satoru <at> jp.fujitsu.com>

btrfs_lookup_csums_range() uses ALIGN() to check if "start"
and "end + 1" are aligned to "root->sectorsize". It's better to
replace these with IS_ALIGNED() for simplicity.

Signed-off-by: Satoru Takeuchi <takeuchi_satoru <at> jp.fujitsu.com>

---
 fs/btrfs/file-item.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/file-item.c b/fs/btrfs/file-item.c
index f46cfe4..4b9e40f 100644
--- a/fs/btrfs/file-item.c
+++ b/fs/btrfs/file-item.c
 <at>  <at>  -329,8 +329,8  <at>  <at>  int btrfs_lookup_csums_range(struct btrfs_root *root, u64 start, u64 end,
 	u64 csum_end;
 	u16 csum_size = btrfs_super_csum_size(root->fs_info->super_copy);

-	ASSERT(start == ALIGN(start, root->sectorsize) &&
-	       (end + 1) == ALIGN(end + 1, root->sectorsize));
+	ASSERT(IS_ALIGNED(start, root->sectorsize) &&
+	       IS_ALIGNED(end + 1, root->sectorsize));

 	path = btrfs_alloc_path();
 	if (!path)
--

-- 
1.9.3

(Continue reading)

Satoru Takeuchi | 25 Jul 08:17 2014

[PATCH 2/2] btrfs-progs: Unify the messy error message formats

From: Satoru Takeuchi <takeuchi_satoru <at> jp.fujitsu.com>

- There are many format to show snapshot name in error messages,
  "'%s'", "'%s", "%s", "('%s')", and "('%s)". Since it's messy,
  unify these to "'%s'" format.
- Fix a type: s/uncorrect/incorrect/

Signed-off-by: Satoru Takeuchi <takeuchi_satoru <at> jp.fujitsu.com>

---
 cmds-subvolume.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/cmds-subvolume.c b/cmds-subvolume.c
index b7bfb3e..ce38503 100644
--- a/cmds-subvolume.c
+++ b/cmds-subvolume.c
 <at>  <at>  -140,14 +140,14  <at>  <at>  static int cmd_subvol_create(int argc, char **argv)
 	dstdir = dirname(dupdir);

 	if (!test_issubvolname(newname)) {
-		fprintf(stderr, "ERROR: uncorrect subvolume name ('%s')\n",
+		fprintf(stderr, "ERROR: incorrect subvolume name '%s'\n",
 			newname);
 		goto out;
 	}

 	len = strlen(newname);
 	if (len == 0 || len >= BTRFS_VOL_NAME_MAX) {
-		fprintf(stderr, "ERROR: subvolume name too long ('%s)\n",
(Continue reading)

Satoru Takeuchi | 25 Jul 08:16 2014

[PATCH 1/2] btrfs-progs: introduce test_issubvolname() for simplicity

From: Satoru Takeuchi <takeuchi_satoru <at> jp.fujitsu.com>

There are many duplicated codes to check if the given string is
correct subvolume name. Introduce test_issubvolname() for this
purpose for simplicity.

Signed-off-by: Satoru Takeuchi <takeuchi_satoru <at> jp.fujitsu.com>

---
 cmds-subvolume.c | 21 +++++++++++++++------
 1 file changed, 15 insertions(+), 6 deletions(-)

diff --git a/cmds-subvolume.c b/cmds-subvolume.c
index 639fb10..b7bfb3e 100644
--- a/cmds-subvolume.c
+++ b/cmds-subvolume.c
 <at>  <at>  -43,6 +43,18  <at>  <at>  static const char * const subvolume_cmd_group_usage[] = {
 };

 /*
+ * test if name is a correct subvolume name
+ * this function return
+ * 0-> name is not a correct subvolume name
+ * 1-> name is a correct subvolume name
+ */
+static int test_issubvolname(char *name)
+{
+	return name[0] != '\0' && !strchr(name, '/') &&
+		strcmp(name, ".") && strcmp(name, "..");
+}
(Continue reading)

Eric Sandeen | 25 Jul 06:27 2014
Picon

[PATCH] mkfs.btrfs: round all device sizes to sectorsize

make_btrfs() rounds down the first device size to a multiple of sectorsize:

	num_bytes = (num_bytes / sectorsize) * sectorsize;

but subsequent device adds don't.

This seems a bit odd & inconsistent, and it makes xfstest btrfs/011
_notrun(), because it explicitly checks that devices are the same size.

I don't know that there is anything inherently wrong with having
a few device bytes extend past the last block, but to be consistent,
it seems like btrfs_add_to_fsid() should round the size in the same
way.

And now btrfs/011 runs more consistently; the test devices don't
have to be sectorsize multiples in order for all mkfs'd device
sizes to match.

Signed-off-by: Eric Sandeen <sandeen <at> redhat.com>
---

ideally this might go into btrfs_device_size(), but we don't have
the chosen sector size anywhere near there...

diff --git a/utils.c b/utils.c
index e130849..4d7ee35 100644
--- a/utils.c
+++ b/utils.c
 <at>  <at>  -554,7 +554,7  <at>  <at>  int btrfs_add_to_fsid(struct btrfs_trans_handle *trans,
 	device->sector_size = sectorsize;
(Continue reading)

Jinghao Printing - CHINA | 25 Jul 05:31 2014
Picon

color box, display box, corrugated box, color card, blister card, color sleeve, hang tag, label

Hi, this is David Wu from Shanghai, China.
We are a printing company, we can print color box, corrugated box,
label, hang tag etc.
Please let me know if you need these.

I will send you the website then.

Best regards,
David Wu
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Gmane