Re: mkfs.btrfs - error checking /dev/sda5 mount status
Hallo, Lubos, Du meintest am 10.02.11: >>> /dev/root / btrfs rw,noatime,compress,ssd 0 0 > # ls -la /dev/root > ls: cannot access /dev/root: No such file or directory ls -la $(rdev) (but that's no simple way ...) 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
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
Re: mkfs.btrfs - error checking /dev/sda5 mount status
Chris Samuel, Thu, 10 Feb 2011 14:09:17 +1100: > On 10/02/11 07:12, Lubos Kolouch wrote: > >> /dev/root / btrfs rw,noatime,compress,ssd 0 0 > > My memory of the strace showed that there was no /dev/root when it tried > to open it - can you confirm whether or not that's the case please ? > > cheers! > Chris > -- > Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC Chris, You mean this? # ls -la /dev/root ls: cannot access /dev/root: No such file or directory Lubos -- 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
On 10/02/11 07:12, Lubos Kolouch wrote: > /dev/root / btrfs rw,noatime,compress,ssd 0 0 My memory of the strace showed that there was no /dev/root when it tried to open it - can you confirm whether or not that's the case please ? cheers! Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- 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 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
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
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 by
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
Re: mkfs.btrfs - error checking /dev/sda5 mount status
Goffredo Baroncelli, Wed, 09 Feb 2011 19:25:34 +0100: > On 02/08/2011 10:26 PM, Lubos Kolouch wrote: >> Goffredo Baroncelli, Tue, 08 Feb 2011 21:00:25 +0100: >> >>> On 02/08/2011 07:57 AM, Lubos Kolouch wrote: Hi, I'm hitting this issue - sda5 is a normal device, nothing to do with loop, encryption etc. # mkfs.btrfs /dev/sda5 WARNING! - Btrfs v0.19-35-g1b444cd-dirty IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using error checking /dev/sda5 mount status Is there something I can do to resolve this? >>> >>> Some months ago I posted a patch [*] which allows to create a >>> filesystem even if an integrity tests fail. >>> Anyway it would be interesting understand why mkfs.btrfs fails. It is >>> possible to have a strace of the command ? >>> >>> >> here ... http://paste.pocoo.org/show/334638/ but it is not in chroot, >> it is in "normal" system >> >> Lubos >> >> > Hi Lubos, > > Could you post also the output of "cat /proc/mounts" command and the > output of "btrfs filesystem show" command. I cannot understand what > should be the problem. Hi Goffredo, Sure, # cat /proc/mounts rootfs / rootfs rw 0 0 /dev/root / btrfs rw,noatime,compress,ssd 0 0 proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0 rc-svcdir /lib/rc/init.d tmpfs rw,nosuid,nodev,noexec,relatime,size=1024k,mode=755 0 0 sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0 debugfs /sys/kernel/debug debugfs rw,nosuid,nodev,noexec,relatime 0 0 udev /dev devtmpfs rw,nosuid,relatime,size=10240k,nr_inodes=217934,mode=755 0 0 fusectl /sys/fs/fuse/connections fusectl rw,relatime 0 0 none /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0 none /dev/shm tmpfs rw,relatime 0 0 /dev/sda1 /boot ext2 rw,relatime,errors=continue 0 0 none /var/tmp/portage tmpfs rw,relatime 0 0 binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,nosuid,nodev,noexec,relatime 0 0 /dev/mapper/_dev_sda6 /home btrfs rw,noatime,compress,ssd 0 0 # btrfs filesystem show Label: none uuid: fd070c17-e98b-4b50-9fa8-3453482aafa2 Total devices 1 FS bytes used 5.51GB devid1 size 18.64GB used 10.79GB path /dev/sda2 Label: none uuid: bf9a1b00-f8bd-44d3-b140-10eea088a60e Total devices 1 FS bytes used 6.73GB devid1 size 19.54GB used 19.54GB path /dev/sda5 Label: none uuid: ae0ba016-1945-4e7a-9fb4-e9311d199727 Total devices 1 FS bytes used 57.50GB devid1 size 78.91GB used 78.91GB path /dev/dm-0 # mkfs.btrfs /dev/sda5 WARNING! - Btrfs v0.19-35-g1b444cd-dirty IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using error checking /dev/sda5 mount status Also, I can mount it no problem - strange, isn't it Lubos -- 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
btrfs: issues with SUBVOL_SETFLAGS
Commit 0caa102da82799efaba88e234484786a9591c797 introduced the SUBVOL_SETFLAGS ioctl, which contains the following check: 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. Regards, Dan -- 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
On 02/08/2011 10:26 PM, Lubos Kolouch wrote: > Goffredo Baroncelli, Tue, 08 Feb 2011 21:00:25 +0100: > >> On 02/08/2011 07:57 AM, Lubos Kolouch wrote: >>> Hi, >>> >>> I'm hitting this issue - sda5 is a normal device, nothing to do with >>> loop, encryption etc. >>> >>> # mkfs.btrfs /dev/sda5 >>> >>> WARNING! - Btrfs v0.19-35-g1b444cd-dirty IS EXPERIMENTAL WARNING! - see >>> http://btrfs.wiki.kernel.org before using >>> >>> error checking /dev/sda5 mount status >>> >>> Is there something I can do to resolve this? >> >> Some months ago I posted a patch [*] which allows to create a filesystem >> even if an integrity tests fail. >> Anyway it would be interesting understand why mkfs.btrfs fails. It is >> possible to have a strace of the command ? >> > > here ... http://paste.pocoo.org/show/334638/ > but it is not in chroot, it is in "normal" system > > Lubos > Hi Lubos, Could you post also the output of "cat /proc/mounts" command and the output of "btrfs filesystem show" command. I cannot understand what should be the problem. > -- > 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 > . > -- 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: warning in btrfs_free_block_groups
Posted for posterity (pastebins aren't forever) 2.6.36-rc8 Oct 27 05:13:01 klonk kernel: device fsid a040b1bd002364c8-548ed98bdbee91b4 devid 1 transid 1450 /dev/sdb2 Oct 27 05:13:08 klonk kernel: btrfs allocation failed flags 1, wanted 4096 Oct 27 05:13:08 klonk kernel: space_info has 0 free, is full Oct 27 05:13:08 klonk kernel: space_info total=43933696, used=439336882176, pinned=0, reserved=12288, may_use=49152, readonly=65536 Oct 27 05:13:08 klonk kernel: block group 12582912 has 8388608 bytes, 8388608 used 0 pinned 0 reserved Oct 27 05:13:08 klonk kernel: block group has cluster?: no Oct 27 05:13:08 klonk kernel: 0 blocks of free space at or bigger than bytes is Oct 27 05:13:08 klonk kernel: block group 1103101952 has 1073741824 bytes, 1073741824 used 0 pinned 0 reserved Oct 27 05:13:08 klonk kernel: block group has cluster?: no Oct 27 05:13:08 klonk kernel: 0 blocks of free space at or bigger than bytes is Oct 27 05:13:08 klonk kernel: block group 2176843776 has 1073741824 bytes, 1073741824 used 0 pinned 0 reserved Oct 27 05:13:08 klonk kernel: block group has cluster?: no Oct 27 05:13:08 klonk kernel: 0 blocks of free space at or bigger than bytes is Oct 27 05:13:08 klonk kernel: block group 3250585600 has 1073741824 bytes, 1073741824 used 0 pinned 0 reserved Oct 27 05:13:08 klonk kernel: block group has cluster?: no [... many similar lines removed ...] Oct 27 05:13:09 klonk kernel: 0 blocks of free space at or bigger than bytes is Oct 27 05:13:09 klonk kernel: block group 443484733440 has 1073741824 bytes, 1073741824 used 0 pinned 0 reserved Oct 27 05:13:09 klonk kernel: block group has cluster?: no Oct 27 05:13:09 klonk kernel: 0 blocks of free space at or bigger than bytes is Oct 27 05:13:09 klonk kernel: block group 444558475264 has 168165376 bytes, 168165376 used 0 pinned 0 reserved Oct 27 05:13:09 klonk kernel: block group has cluster?: no Oct 27 05:13:09 klonk kernel: 0 blocks of free space at or bigger than bytes is Oct 27 05:13:09 klonk kernel: [ cut here ] Oct 27 05:13:09 klonk kernel: kernel BUG at fs/btrfs/inode.c:815! Oct 27 05:13:09 klonk kernel: invalid opcode: [#1] SMP Oct 27 05:13:09 klonk kernel: last sysfs file: /sys/devices/pci:00/:00:11.0/host1/target1:0:0/1:0:0:0/model Oct 27 05:13:09 klonk kernel: CPU 0 Oct 27 05:13:09 klonk kernel: Modules linked in: nls_cp437 vfat fat nls_iso8859_1 isofs udf crc_itu_t vboxnetadp vboxnetflt vboxdrv 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 r8169 i2c_piix4 usblp soundcore snd_page_alloc Oct 27 05:13:09 klonk kernel: Oct 27 05:13:09 klonk kernel: Pid: 9164, comm: flush-btrfs-1 Not tainted 2.6.36-rc8 #46 790XT-G45 (MS-7388)/MS-7388 Oct 27 05:13:09 klonk kernel: RIP: 0010:[] [] cow_file_range+0x1ab/0x2f4 Oct 27 05:13:09 klonk kernel: RSP: 0018:88005d3fd890 EFLAGS: 00010286 Oct 27 05:13:09 klonk kernel: RAX: ffe4 RBX: 88007f65e800 RCX: ffe4 Oct 27 05:13:09 klonk kernel: RDX: 0001 RSI: 5d3fd7a0 RDI: 880135d90f30 Oct 27 05:13:09 klonk kernel: RBP: 88005d3fd940 R08: 0031 R09: ff0a Oct 27 05:13:09 klonk kernel: R10: R11: R12: 3000 Oct 27 05:13:09 klonk kernel: R13: 880081314cf8 R14: 1000 R15: 1000 Oct 27 05:13:09 klonk kernel: FS: 7f8ebb25c710() GS:880001a0() knlGS: Oct 27 05:13:09 klonk kernel: CS: 0010 DS: ES: CR0: 8005003b Oct 27 05:13:09 klonk kernel: CR2: 7f0d8f414000 CR3: 000129bdc000 CR4: 06f0 Oct 27 05:13:09 klonk kernel: DR0: DR1: DR2: Oct 27 05:13:09 klonk kernel: DR3: DR6: 0ff0 DR7: 0400 Oct 27 05:13:09 klonk kernel: Process flush-btrfs-1 (pid: 9164, threadinfo 88005d3fc000, task 880007e2ceb0) Oct 27 05:13:09 klonk kernel: Stack: Oct 27 05:13:09 klonk kernel: 88005d3fd8f0 0001 88005d3fd948 Oct 27 05:13:09 klonk kernel: <0> 00542d416000 ea000297fb40 880081314b90 2fff Oct 27 05:13:09 klonk kernel: <0> 880081314ba0 8800c44e38a0 880081314b98 9000 Oct 27 05:13:09 klonk kernel: Call Trace: Oct 27 05:13:09 klonk kernel: [] run_delalloc_range+0xaf/0x31f Oct 27 05:13:09 klonk kernel: [] ? do_get_write_access+0x3b9/0x400 Oct 27 05:13:09 klonk kernel: [] __extent_writepage+0x1ba/0x5b3 Oct 27 05:13:09 klonk kernel: [] ? radix_tree_gang_lookup_tag_slot+0x84/0xa9 Oct 27 05:13:09 klonk kernel: [] T.847+0x15f/0x2a8 Oct 27 05:13:09 klonk kernel: [] extent_writepages+0x3e/0x56 Oct 27 05:13:09 klonk kernel: [] ? btrfs_get_extent+0x0/0x7e9 Oct 27 05:13:09 klonk kernel: [] ? bit_waitqueue+0x14/0x92 Oct 27 05:13:09 klonk kernel: [] btrfs_writepa
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:
[] warn_slowpath_common+0x80/0x98
[] warn_slowpath_null+0x15/0x17
[] btrfs_free_block_groups+0x218/0x275
[] close_ctree+0x183/0x344
[] ? destroy_inode+0x38/0x4e
[] ? dispose_list+0xaa/0xc0
[] btrfs_put_super+0x18/0x27
[] generic_shutdown_super+0x66/0xe1
[] kill_anon_super+0x11/0x49
[] deactivate_locked_super+0x21/0x41
[] deactivate_super+0x40/0x44
[] mntput_no_expire+0xdd/0x10b
[] sys_umount+0x2d2/0x2fd
[] 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: [PATCH] btrfs: prevent heap corruption in btrfs_ioctl_space_info()
> > Argh sorry I take it back, this is wrong, we can have multiple raid types per > space info, so you need to put the slot_count-- in the inner loop farther down > to count the actual slots we're adding. Thanks, > Good catch, thanks. Reviewed-by: Dan Rosenberg -Dan -- 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: [PATCH] btrfs: prevent heap corruption in btrfs_ioctl_space_info()
On Wed, Feb 09, 2011 at 10:51:33AM -0500, Josef Bacik wrote:
> On Wed, Feb 09, 2011 at 09:12:46AM -0500, Dan Rosenberg wrote:
> > Commit bf5fc093c5b625e4259203f1cee7ca73488a5620 refactored
> > btrfs_ioctl_space_info() and introduced several security issues.
> >
> > space_args.space_slots is an unsigned 64-bit type controlled by a
> > possibly unprivileged caller. The comparison as a signed int type
> > allows providing values that are treated as negative and cause the
> > subsequent allocation size calculation to wrap, or be truncated to 0.
> > By providing a size that's truncated to 0, kmalloc() will return
> > ZERO_SIZE_PTR. It's also possible to provide a value smaller than the
> > slot count. The subsequent loop ignores the allocation size when
> > copying data in, resulting in a heap overflow or write to ZERO_SIZE_PTR.
> >
> > The fix changes the slot count type and comparison typecast to u64,
> > which prevents truncation or signedness errors, and also ensures that we
> > don't copy more data than we've allocated in the subsequent loop. Note
> > that zero-size allocations are no longer possible since there is already
> > an explicit check for space_args.space_slots being 0 and truncation of
> > this value is no longer an issue.
> >
> > Signed-off-by: Dan Rosenberg
>
> Reviewed-by: Josef Bacik
>
Argh sorry I take it back, this is wrong, we can have multiple raid types per
space info, so you need to put the slot_count-- in the inner loop farther down
to count the actual slots we're adding. Thanks,
Signed-off-by: Josef Bacik
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index b72520b..89bfd41 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2203,7 +2203,7 @@ long btrfs_ioctl_space_info(struct btrfs_root *root, void
__user *arg)
int num_types = 4;
int alloc_size;
int ret = 0;
- int slot_count = 0;
+ u64 slot_count = 0;
int i, c;
if (copy_from_user(&space_args,
@@ -2242,7 +2242,7 @@ long btrfs_ioctl_space_info(struct btrfs_root *root, void
__user *arg)
goto out;
}
- slot_count = min_t(int, space_args.space_slots, slot_count);
+ slot_count = min_t(u64, space_args.space_slots, slot_count);
alloc_size = sizeof(*dest) * slot_count;
@@ -2262,6 +2262,9 @@ long btrfs_ioctl_space_info(struct btrfs_root *root, void
__user *arg)
for (i = 0; i < num_types; i++) {
struct btrfs_space_info *tmp;
+ if (!slot_count)
+ break;
+
info = NULL;
rcu_read_lock();
list_for_each_entry_rcu(tmp, &root->fs_info->space_info,
@@ -2283,7 +2286,10 @@ long btrfs_ioctl_space_info(struct btrfs_root *root,
void __user *arg)
memcpy(dest, &space, sizeof(space));
dest++;
space_args.total_spaces++;
+ slot_count--;
}
+ if (!slot_count)
+ break;
}
up_read(&info->groups_sem);
}
--
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: [PATCH] btrfs: prevent heap corruption in btrfs_ioctl_space_info()
On Wed, Feb 09, 2011 at 09:12:46AM -0500, Dan Rosenberg wrote: > Commit bf5fc093c5b625e4259203f1cee7ca73488a5620 refactored > btrfs_ioctl_space_info() and introduced several security issues. > > space_args.space_slots is an unsigned 64-bit type controlled by a > possibly unprivileged caller. The comparison as a signed int type > allows providing values that are treated as negative and cause the > subsequent allocation size calculation to wrap, or be truncated to 0. > By providing a size that's truncated to 0, kmalloc() will return > ZERO_SIZE_PTR. It's also possible to provide a value smaller than the > slot count. The subsequent loop ignores the allocation size when > copying data in, resulting in a heap overflow or write to ZERO_SIZE_PTR. > > The fix changes the slot count type and comparison typecast to u64, > which prevents truncation or signedness errors, and also ensures that we > don't copy more data than we've allocated in the subsequent loop. Note > that zero-size allocations are no longer possible since there is already > an explicit check for space_args.space_slots being 0 and truncation of > this value is no longer an issue. > > Signed-off-by: Dan Rosenberg Reviewed-by: Josef Bacik Thanks, Josef -- 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
[PATCH] btrfs: prevent heap corruption in btrfs_ioctl_space_info()
Commit bf5fc093c5b625e4259203f1cee7ca73488a5620 refactored
btrfs_ioctl_space_info() and introduced several security issues.
space_args.space_slots is an unsigned 64-bit type controlled by a
possibly unprivileged caller. The comparison as a signed int type
allows providing values that are treated as negative and cause the
subsequent allocation size calculation to wrap, or be truncated to 0.
By providing a size that's truncated to 0, kmalloc() will return
ZERO_SIZE_PTR. It's also possible to provide a value smaller than the
slot count. The subsequent loop ignores the allocation size when
copying data in, resulting in a heap overflow or write to ZERO_SIZE_PTR.
The fix changes the slot count type and comparison typecast to u64,
which prevents truncation or signedness errors, and also ensures that we
don't copy more data than we've allocated in the subsequent loop. Note
that zero-size allocations are no longer possible since there is already
an explicit check for space_args.space_slots being 0 and truncation of
this value is no longer an issue.
Signed-off-by: Dan Rosenberg
---
fs/btrfs/ioctl.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index 02d224e..f1a43df 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -2208,7 +2208,7 @@ long btrfs_ioctl_space_info(struct btrfs_root *root, void
__user *arg)
int num_types = 4;
int alloc_size;
int ret = 0;
- int slot_count = 0;
+ u64 slot_count = 0;
int i, c;
if (copy_from_user(&space_args,
@@ -2247,7 +2247,7 @@ long btrfs_ioctl_space_info(struct btrfs_root *root, void
__user *arg)
goto out;
}
- slot_count = min_t(int, space_args.space_slots, slot_count);
+ slot_count = min_t(u64, space_args.space_slots, slot_count);
alloc_size = sizeof(*dest) * slot_count;
@@ -2267,6 +2267,12 @@ long btrfs_ioctl_space_info(struct btrfs_root *root,
void __user *arg)
for (i = 0; i < num_types; i++) {
struct btrfs_space_info *tmp;
+ /* Don't copy in more than we allocated */
+ if (!slot_count)
+ break;
+
+ slot_count--;
+
info = NULL;
rcu_read_lock();
list_for_each_entry_rcu(tmp, &root->fs_info->space_info,
--
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
[PATCH] Btrfs - use %pU to print fsid
Get rid of FIXME comment. Uuids from dmesg are now the same as uuids
given by btrfs-progs.
Signed-off-by: Ilya Dryomov
---
fs/btrfs/volumes.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index 2636a05..83b789c 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -714,12 +714,8 @@ int btrfs_scan_one_device(const char *path, fmode_t flags,
void *holder,
transid = btrfs_super_generation(disk_super);
if (disk_super->label[0])
printk(KERN_INFO "device label %s ", disk_super->label);
- else {
- /* FIXME, make a readl uuid parser */
- printk(KERN_INFO "device fsid %llx-%llx ",
- *(unsigned long long *)disk_super->fsid,
- *(unsigned long long *)(disk_super->fsid + 8));
- }
+ else
+ printk(KERN_INFO "device fsid %pU ", disk_super->fsid);
printk(KERN_CONT "devid %llu transid %llu %s\n",
(unsigned long long)devid, (unsigned long long)transid, path);
ret = device_list_add(path, disk_super, devid, fs_devices_ret);
--
1.7.2.3
--
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
kernel panic (was: no space left on device)
Hallo, Erik, Du meintest am 08.02.11: >> Maybe that doesn't help now. I'm working with kernel 2.6.37 and >> kernel 2.6.38-rc2, and I've got big problems. > I had to install at least 2.6.37 to have a kernel with an advanced > enough balance feature to actually reclaim the free space and report > it correctly too. > Still, I had so much kernel crashes during this balance operation > that even after numerous retries I still hadn't once completed it (on > a FS of merely 300GB). Fortunately Zheng Yan coded a patch, which I > applied to 2.6.38-rc2, so that I could finally run - and finish - the > balance operation. Didn't help - sorry. You can take a look to the last lines of my system after crashing into "kernel panic" with blinkenlights: http://helmut.hullen.de/btrfs/ The screenshots are hard to read - sorry. 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
Re: bug#8001: cp (8.10) sparse handling fails on compressed btrfs (cp/fiemap-2)
On 08/02/11 03:53, Mike Frysinger wrote: > after upgrading from coreutils 8.9 to 8.10, the sparse handling in cp is > silently breaking on btrfs filesystems with the compressed option enabled. > using --sparse=never works fine, but "auto" or "always" tend to fail. the > cp/fiemap-2 test catches the issue nicely. > > to reproduce (i'm using linux-2.6.37): > file=btrfs.img > mntp=/mnt/tmp/ > dd if=/dev/zero of=$file bs=1M count=0 seek=1024 > mkfs.btrfs $file > mount -t btrfs -o compress $file $mntp > cd $mntp > tar xf ~/coreutils-8.10.tar.xz > cd coreutils-8.10/tests > ./cp/fiemap-2 > > and this last test shows: > FilesystemType 1K-blocks Used Available Use% Mounted on > /dev/loop0 btrfs 1048576 20420377028 6% /mnt/tmp > 0+0 records in > 0+0 records out > 0 bytes (0 B) copied, 2.7598e-05 s, 0.0 kB/s > k k2 differ: byte 1, line 1 Eek. That doesn't trigger here (2.6.35.10-72.fc14.i686) because I guess this kernel doesn't honor the compress attribute: dd if=/dev/zero of=test.size count=1000 # du -B512 test.size 1000test.size But on a general note, we may read more (or possibly less) than is stored in the extent. So how to detect that? I suppose one could use lseek() to get the current position and see if it's ext_start + ext_length, otherwise adjust accordingly. That would add a little overhead though. I also notice the FIEMAP_EXTENT_DATA_ENCRYPTED and FIEMAP_EXTENT_ENCODED flags, which could mean we only need to handle these extents specially. Does `filefrag -v` show those for you? I see nothing here. I don't suppose there is any facility to read the raw data to also avoid decompressing and compressing again (sendfile, mmap?). cheers, Pádraig. -- 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
[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
---
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", "[+/-][gkm]|max \n"
+ "filesystem resize", "[:][+|-][gkm]|max
\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.",
+ "[:][+|-][gkm]|max \n"
+"Resize the file system. If no 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", "[|]\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 \fP
.PP
-\fBbtrfs\fP \fBfilesystem resize\fP\fI [+/\-][gkm]|max \fP
+\fBbtrfs\fP \fBfilesystem resize\fP\fI [:][+|\-][gkm]|max
\fP
.PP
\fBbtrfs\fP \fBdevice scan\fP\fI [ [..]]\fP
.PP
@@ -138,9 +138,11 @@ Force a sync for the filesystem identified by \fI\fR.
.\" Some wording are extracted by the resize2fs man page
.\"
-\fBfilesystem resize\fR\fI [+/\-][gkm]|max \fR
+\fBfilesystem resize\fR\fI [:][+|\-][gkm]|max \fR
Resize a filesystem identified by \fI\fR.
The \fI\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 \fI\fR.
If no units are specified, the unit of the \fI\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
