[PATCH] explain filesystem resize devid option
Adds explanation to help message and man page how to use `filesystem resize'
to resize only a single device not all devices of a file system.
Signed-off-by: Hubert Kario ka...@wit.edu.pl
---
patch to apply cleanly requires my previous patches adding advanced help
functionality
btrfs.c| 10 +++---
man/btrfs.8.in |6 --
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/btrfs.c b/btrfs.c
index bd6f6f8..a28a573 100644
--- a/btrfs.c
+++ b/btrfs.c
@@ -98,10 +98,14 @@ static struct Command commands[] = {
NULL
},
{ do_resize, 2,
- filesystem resize, [+/-]newsize[gkm]|max filesystem\n
+ filesystem resize, [devid:][+|-]newsize[gkm]|max
filesystem\n
Resize the file system. If 'max' is passed, the filesystem\n
- will occupe all available space on the device.,
- NULL
+ will occupy all available space on the device.,
+ [devid:][+|-]newsize[gkm]|max filesystem\n
+Resize the file system. If no devid is specified, change
is\n
+applied to every device in file system. If devid is
specified\n
+the change in size is applied only to selected device.\n
+To get device numbers use `btrfs filesystem show\' command.
},
{ do_show_filesystem, 999,
filesystem show, [uuid|label]\n
diff --git a/man/btrfs.8.in b/man/btrfs.8.in
index cba2de1..afb9824 100644
--- a/man/btrfs.8.in
+++ b/man/btrfs.8.in
@@ -19,7 +19,7 @@ btrfs \- control a btrfs filesystem
.PP
\fBbtrfs\fP \fBfilesystem sync\fP\fI path \fP
.PP
-\fBbtrfs\fP \fBfilesystem resize\fP\fI [+/\-]size[gkm]|max filesystem\fP
+\fBbtrfs\fP \fBfilesystem resize\fP\fI [devid:][+|\-]size[gkm]|max
filesystem\fP
.PP
\fBbtrfs\fP \fBdevice scan\fP\fI [device [device..]]\fP
.PP
@@ -138,9 +138,11 @@ Force a sync for the filesystem identified by \fIpath\fR.
.\ Some wording are extracted by the resize2fs man page
.\
-\fBfilesystem resize\fR\fI [+/\-]size[gkm]|max path\fR
+\fBfilesystem resize\fR\fI [devid:][+|\-]size[gkm]|max path\fR
Resize a filesystem identified by \fIpath\fR.
The \fIsize\fR parameter specifies the new size of the filesystem.
+To change size of only one device the device id can be specified before
\fI:\fR.
+Device identifiers are printed by \fBfilesystem show\fR command.
If the prefix \fI+\fR or \fI\-\fR is present the size is increased or decreased
by the quantity \fIsize\fR.
If no units are specified, the unit of the \fIsize\fR parameter defaults to
--
1.7.4
--
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
warning in btrfs_free_block_groups
I suspect this might be related to previous btrfs errors I've had on
the same filesystem. See:
http://python.ca/nas/linux/btrfs_bug.txt
The most recent kernel message is:
WARNING: at fs/btrfs/extent-tree.c:8239
btrfs_free_block_groups+0x218/0x275()
Hardware name: MS-7388
Modules linked in: udf crc_itu_t isofs loop nls_iso8859_1 vboxnetflt
vboxdrv nls_utf8 nls_cp437 vfat fat kvm_amd kvm ipv6 fuse f71882fg
snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss
snd_mixer_oss snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq
snd_timer snd_seq_device snd soundcore r8169 i2c_piix4 snd_page_alloc usblp
Pid: 13197, comm: umount Tainted: GW 2.6.37-rc8 #54
Call Trace:
[810398d3] warn_slowpath_common+0x80/0x98
[81039900] warn_slowpath_null+0x15/0x17
[81155aec] btrfs_free_block_groups+0x218/0x275
[81164597] close_ctree+0x183/0x344
[810bc2c5] ? destroy_inode+0x38/0x4e
[810bc385] ? dispose_list+0xaa/0xc0
[8114a040] btrfs_put_super+0x18/0x27
[810ac3a2] generic_shutdown_super+0x66/0xe1
[810ac468] kill_anon_super+0x11/0x49
[810ab6fa] deactivate_locked_super+0x21/0x41
[810abba6] deactivate_super+0x40/0x44
[810bfcfe] mntput_no_expire+0xdd/0x10b
[810c0276] sys_umount+0x2d2/0x2fd
[810028bb] system_call_fastpath+0x16/0x1b
---[ end trace 3f9c8cf600895a9f ]---
space_info has 1751910400 free, is not full
space_info total=5377097728, used=3611955200, pinned=0, reserved=4843520,
may_use=0, readonly=8388608
The code is:
while(!list_empty(info-space_info)) {
space_info = list_entry(info-space_info.next,
struct btrfs_space_info,
list);
if (space_info-bytes_pinned 0 ||
space_info-bytes_reserved 0) {
WARN_ON(1);
dump_space_info(space_info, 0, 0);
}
list_del(space_info-list);
kfree(space_info);
}
return 0;
When I tried btrfsck, I get:
btrfsck: btrfsck.c:584: splice_shared_node: Assertion `!(src ==
src_node-root_cache)' failed.
I'm making heavy use of subvolume snapshots. The partition is
being used for backups and I use 'rsync --inplace' along with the
CoW feature to preserve space.
Regards,
Neil
--
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
Re: btrfs: issues with SUBVOL_SETFLAGS
Dan Rosenberg wrote: Commit 0caa102da82799efaba88e234484786a9591c797 introduced the SUBVOL_SETFLAGS ioctl, which contains the following check: if (flags ~BTRFS_SUBVOL_CREATE_ASYNC) Oops, should be: if (flags BTRFS_SUBVOL_CREATE_ASYNC) return -EINVAL; if (flags ~BTRFS_SUBVOL_RDONLY) return -EOPNOTSUPP; Is it intentional that 0 is the only acceptable flags value? In addition, there should probably be an inode ownership check before allowing setting subvolume flags. Thanks for pointing it out! Fix will be sent out soon. -- 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
Recovering data from disk with loose cable
We have a disk array behind two external SATA port multipliers (four disks on each multiplier) which has been running btrfs (RAID 1 for both data and metadata). Unfortunately, earlier today it seems one of the SATA cables came loose, resulting in the kernel (2.6.37) eventually OOPSing although apparently not before writing quite a bit of data. Upon reboot, I was met with the dreaded, disk-io.c:741: open_ctree_fd: Assertion `!(!tree_root-node)' failed. Unfortunately any attempt to run any of the btrfs-progs utilities (from git) met a similar end. There was recently a patch to try harder in recovering from this problem posted to the list[1], although unfortunately it is unable to find a root. Considering there are eight disks in the array and only four were affected by the loose cable, I find it very hard to believe there is no way to recover this volume. Any suggestions at all would be greatly appreciated. Recovering this data would mean a lot. Thanks, - Ben [1] https://patchwork.kernel.org/patch/506631/ [2] Output from patched btrfsck $ sudo ./btrfsck /dev/sdj trying potential super #0 at bytenr 65536 super #0 at bytenr 65536 has better generation 43887 than 0, using that trying potential super #1 at bytenr 67108864 super #1 at bytenr 67108864 has same generation 43887 than 43887, skipping warning: super #1 at bytenr 67108864 has different contents! trying potential super #2 at bytenr 274877906944 super #2 at bytenr 274877906944 has same generation 43887 than 43887, skipping warning: super #2 at bytenr 274877906944 has different contents! trying potential super #0 at bytenr 65536 super #0 at bytenr 65536 has better generation 43887 than 0, using that trying potential super #1 at bytenr 67108864 super #1 at bytenr 67108864 has same generation 43887 than 43887, skipping warning: super #1 at bytenr 67108864 has different contents! trying potential super #2 at bytenr 274877906944 super #2 at bytenr 274877906944 has same generation 43887 than 43887, skipping warning: super #2 at bytenr 274877906944 has different contents! trying potential super #0 at bytenr 65536 super #0 at bytenr 65536 has better generation 43887 than 0, using that trying potential super #1 at bytenr 67108864 super #1 at bytenr 67108864 has same generation 43887 than 43887, skipping warning: super #1 at bytenr 67108864 has different contents! trying potential super #2 at bytenr 274877906944 super #2 at bytenr 274877906944 has same generation 43887 than 43887, skipping warning: super #2 at bytenr 274877906944 has different contents! trying potential super #0 at bytenr 65536 super #0 at bytenr 65536 has better generation 43887 than 0, using that trying potential super #1 at bytenr 67108864 super #1 at bytenr 67108864 has same generation 43887 than 43887, skipping warning: super #1 at bytenr 67108864 has different contents! trying potential super #2 at bytenr 274877906944 super #2 at bytenr 274877906944 has same generation 43887 than 43887, skipping warning: super #2 at bytenr 274877906944 has different contents! trying potential super #0 at bytenr 65536 super #0 at bytenr 65536 has better generation 43887 than 0, using that trying potential super #1 at bytenr 67108864 super #1 at bytenr 67108864 has same generation 43887 than 43887, skipping warning: super #1 at bytenr 67108864 has different contents! trying potential super #2 at bytenr 274877906944 super #2 at bytenr 274877906944 has same generation 43887 than 43887, skipping warning: super #2 at bytenr 274877906944 has different contents! trying potential super #0 at bytenr 65536 super #0 at bytenr 65536 has better generation 43884 than 0, using that trying potential super #1 at bytenr 67108864 super #1 at bytenr 67108864 has same generation 43884 than 43884, skipping warning: super #1 at bytenr 67108864 has different contents! trying potential super #2 at bytenr 274877906944 super #2 at bytenr 274877906944 has same generation 43884 than 43884, skipping warning: super #2 at bytenr 274877906944 has different contents! trying potential super #0 at bytenr 65536 super #0 at bytenr 65536 has better generation 43884 than 0, using that trying potential super #1 at bytenr 67108864 super #1 at bytenr 67108864 has same generation 43884 than 43884, skipping warning: super #1 at bytenr 67108864 has different contents! trying potential super #2 at bytenr 274877906944 super #2 at bytenr 274877906944 has same generation 43884 than 43884, skipping warning: super #2 at bytenr 274877906944 has different contents! trying potential super #0 at bytenr 65536 super #0 at bytenr 65536 has better generation 43884 than 0, using that trying potential super #1 at bytenr 67108864 super #1 at bytenr 67108864 has same generation 43884 than 43884, skipping warning: super #1 at bytenr 67108864 has different contents! trying potential super #2 at bytenr 274877906944 super #2 at bytenr 274877906944 has same generation 43884 than 43884, skipping warning: super #2 at
New btrfsck status
Hey all, Over the last several months there have been many claims regarding the release of the rewritten btrfsck. Unfortunately, despite numerous claims that it will be released Real Soon Now(c), I have yet to see even a repository with preliminary code. Did I miss an announcement? There is something to be said for release early, release often. Is there a timeline for getting btrfsck into some sort of usable form? Cheers, - Ben -- 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
Re: New btrfsck status
On Wed, Feb 9, 2011 at 8:52 PM, Ben Gamari bgam...@gmail.com wrote: Hey all, Over the last several months there have been many claims regarding the release of the rewritten btrfsck. Unfortunately, despite numerous claims that it will be released Real Soon Now(c), I have yet to see even a repository with preliminary code. Did I miss an announcement? There is something to be said for release early, release often. Is there a timeline for getting btrfsck into some sort of usable form? I can't speak for the devs, but that's never stopped me before :p Speculative code to directly muck with known-to-be-corrupted data structures is not something that benefits from early releases. It's too easy to cause damage that _can't_ be fixed later, and no amount of warnings will prevent people from trying that code in desperation. Or would you have taken a full image of your 8 drives before trying it the first time? -- 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
Re: mkfs.btrfs - error checking /dev/sda5 mount status
Hallo, Lubos, Du meintest am 09.02.11: # cat /proc/mounts rootfs / rootfs rw 0 0 /dev/root / btrfs rw,noatime,compress,ssd 0 0 /dev/root is a symlink (which I don't like). rdev shows which real device is meant. Viele Gruesse! Helmut -- 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
