similar to: mkfs.btrfs failure on ARM

$./mkfs.btrfs -f /dev/sdd -b 2M [...] mkfs.btrfs: volumes.c:845: btrfs_alloc_chunk: Assertion `!(ret)'' failed. Aborted (core dumped). We should return error to userspace instead of the above. Signed-off-by: Liu Bo <bo.li.liu@oracle.com> --- mkfs.c | 23 +++++++++++++++-------- volumes.c | 16 +++++++++++----- 2 files changed, 26 insertions(+), 13 deletions(-) diff --git

Some programs like btrfsck should not be run on a mounted filesystem. This patch adds a check in btrfs_open_devices() for the mount status of every device belonging to the filesystem. The function check_mount() gets improved support for loopback devices. It now detects if the program is run on the file that is being used by the loopback device. Signed-off-by: Andi Drebes

Dear All, Previously we have used CentOS4.4 release with Supported Cluster Suite and DRBD 8.0.0 Active/passive (failover) We have build the DRBD 8.0.0 Source in CentOS4.4 Setup We have configured the DRBD Resource with default OS installed LVM (/dev/mapper/vgroot-LogVol00 and /dev/mapper/vgroot-LogVol01) Partition and its working fine Partition Tables are listed below

Hello, I've been trying to kickstart a install centos from a USB memory stick. Everything with that is working fine, but I seem to be having a problem with the ks.cfg file. When I boot the install media from the usb drive, the the boot prompt I type linux ks=hd:/dev/uba1/ks.cfg Then I peek at the logs and it even says * getting kickstart file * getting kickstart file from harddrive *

Here are 3 patches to avoid undesired aborts of mkfs.btrfs. These are based on top of Chris''s btrfs-progs.git: git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git Thanks, H.Seto Hidetoshi Seto (3): btrfs-progs: error if device for mkfs is too small btrfs-progs: error if device have no space to make primary chunks btrfs-progs: calculate available

Hi All, There is some discrepancy between what quota reports and what du reports -bash-3.00$ cat /etc/redhat-release CentOS release 4.4 (Final) -bash-3.00$ pwd /home/corview -bash-3.00$ df . Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/vgroot-LogVol01 10095152 586932 8995404 7% /home -bash-3.00$ du -sh . 19M . -bash-3.00$

This deadlock comes from xfstests 251. We''ll hold the chunk_mutex throughout the whole of a chunk allocation. But if we find that we''ve used up system chunk space, we need to allocate a new system chunk, but this will lead to a recursion of chunk allocation and end up with a deadlock on chunk_mutex. So instead we need to allocate the system chunk first if we find we''re

When building from tmp branch I got this error: mkfs.c: In function ‘main’: mkfs.c:730:6: error: ‘ret’ may be used uninitialized in this function mkfs.c:841:43: error: ‘parent_dir_entry’ may be used uninitialized in this function make: *** [mkfs.o] Error 1 "git blame" shows the last commit for both lines was commit e3736c698e8b490bea1375576b718a2de6e89603 Author: Donggeun Kim

The current btrfs support did not handled multiple stripes stored in chunk items, hence skipping the physical addresses that were needed to do the mapping. Besides, the chunk tree may contain DEV_ITEM keys which store information on all of the underlying block devices, so we must skip them instead of finishing lookup. The bug was reproduced with btrfs-progs v4.2.2. Cc: Gene Cumm <gene.cumm

The current btrfs support did not handled multiple stripes stored in chunk items, hence skipping the physical addresses that were needed to do the mapping. Besides, the chunk tree may contain DEV_ITEM keys which store information on all of the underlying block devices, so we must skip them instead of finishing lookup. The bug was reproduced with btrfs-progs v4.2.2. Cc: Gene Cumm <gene.cumm

The current btrfs support did not handled multiple stripes stored in chunk items, hence skipping the physical addresses that were needed to do the mapping. Besides, the chunk tree may contain DEV_ITEM keys which store information on all of the underlying block devices, so we must skip them instead of finishing lookup. The bug was reproduced with btrfs-progs v4.2.2. Cc: Gene Cumm <gene.cumm

On Thu, Dec 24, 2015 at 8:58 AM, Paulo Alcantara <pcacjr at gmail.com> wrote: > The current btrfs support did not handled multiple stripes stored in > chunk items, hence skipping the physical addresses that were needed to > do the mapping. > > Besides, the chunk tree may contain DEV_ITEM keys which store > information on all of the underlying block devices, so we must skip

Hi, I''m having a filesystem that''s been a bit mangled by external causes, so I thought I''d see how much I could salvage (it''s not critical, though). Thus, I pulled btrfsck from git and ran: pannekake:~/btrfs-progs# ./btrfsck --repair /dev/mapper/pannekake-backup-btrfs It spit out a ton of warnings like these (I can get the whole log if you''re

If there is no free space, the free space allocator will try to get space from the block group with the degenerated profile. For example, if there is no free space in the RAID1 block groups, the allocator will try to allocate space from the DUP block groups. And besides that, the space reservation has the similar behaviour: if there is no enough space in the space cache to reserve, it will reserve

On 02/06/2015 08:17 AM, Chris Wensink wrote: > Hello Everyone, > > Does anyone have any more detail about what kind of system Anthem / Blue > Cross was running and what kind of attack broke into their system? > > It's terrible that it happened, but I think it would benefit all Admins > everywhere to learn how it happened so that we can secure our systems > from a

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? Thank you Lubos -- To unsubscribe from this list: send the line

we wipe the filesystem signatures from device before do mkfs, since we can't trust mkfs can remove the filesystem signature absolutely. Signed-off-by: Wanlong Gao <gaowanlong at cn.fujitsu.com> --- daemon/mkfs.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/daemon/mkfs.c b/daemon/mkfs.c index 5475582..19224ec 100644 --- a/daemon/mkfs.c +++

From: "Richard W.M. Jones" <rjones@redhat.com> If you use virt-make-fs to create a partitionless FAT-formatted disk image then currently you will get an error: $ virt-make-fs --type=fat . /tmp/test.img 'mkfs' (create filesystem) operation failed. Instead of 'fat', try 'vfat' (long filenames) or 'msdos' (short filenames). mkfs: fat: /dev/sda:

On Fri, 2015-02-06 at 08:40 -0600, mshinn wrote: > I recommend reading up on kreb's site: > > http://krebsonsecurity.com/2015/02/china-to-blame-in-anthem-hack/ > > Not sure the "hack" was an issue with their platforms per se. > > " > ?On January 27, 2015, an Anthem associate, a database administrator, > discovered suspicious activity ? a database

Hello all We are experimenting with btrfs and we''ve run into some problems. We are running on two Sun Storage J4400 Arrays containing a total of 48 1 TB disks. With 24 disks in the btrfs: # mkfs.btrfs /dev/sd[b-y] WARNING! - Btrfs Btrfs v0.19 IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using adding device /dev/sdc id 2 ... adding device /dev/sdy id 24 fs