similar to: [PATCH] Btrfs: fix deadlock during allocating chunks

An user reported that he has hit an annoying deadlock while playing with ceph based on btrfs. Current updating device tree requires space from METADATA chunk, so we -may- need to do a recursive chunk allocation when adding/updating dev extent, that is where the deadlock comes from. If we use SYSTEM metadata to update device tree, we can avoid the recursive stuff. Reported-by: Jim Schutt

$./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

The ''char name[BTRFS_PATH_NAME_MAX]'' member of struct btrfs_ioctl_vol_args is passed directly to strlen() after being copied from user. I haven''t verified this, but in theory a userspace program could pass in an unterminated string and cause a kernel crash as strlen walks off the end of the array. This patch terminates the ->name string in all btrfs ioctl functions

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

I''m hitting an error with the default mkfs.btrfs in debian wheezy: ford:~# uname -a Linux ford.blinkenlights.nl 3.1.0-1-kirkwood #1 Tue Nov 15 00:17:24 UTC 2011 armv5tel GNU/Linux ford:~/btrfs-progs# dpkg -l | grep btrfs ii btrfs-tools 0.19+20111105-1 Checksumming Copy on Write Filesystem utilities ford:~# mkfs.btrfs /dev/vgroot/home WARNING! - Btrfs Btrfs

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

Fix a xl/libxl segfault when assigning a device to the guest (bug http://bugzilla.xensource.com/bugzilla/show_bug.cgi?id=1713). Signed-off-by: Gianni Tedesco <gianni.tedesco@citrix.com> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com> diff -r b05892ff0fce tools/libxl/libxl_pci.c --- a/tools/libxl/libxl_pci.c Tue Jan 25 15:14:52 2011 +0000 +++

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

Changes since v1: - Fix a double-free bug introduced by v1, pointed out by Stefano where internal pointer was being passed back to caller from libxl_create_stubdom() 8<---------------------------------------------------------------------- Currently scratch variables allocated by libxl have the same lifetime as the context. While this is suitable for one off invocations of xl. It is not

The biggest one is a fix for fstrim, and there''s a fix for on-disk free space cache. Others are small fixes and cleanups. The last three have been sent weeks ago. The patchset is also available in this repo: git://repo.or.cz/linux-btrfs-devel.git for-chris Note there''s a small confict with Al Viro''s vfs changes. Li Zefan (11): Btrfs: add pinned extents to

I saw the pci dev''s config is different from vbd/vnif with following comments: # Parsing the device SXP''s. In most cases, the SXP looks # like this: # # [device, [vif, [mac, xx:xx:xx:xx:xx:xx], [ip 1.3.4.5]]] # # However, for PCI devices it looks like this: # # [device, [pci, [dev, [domain, 0], [bus, 0], [slot, 1]]]] # # It seems the reasoning for this difference is

From: Wade Cline <clinew@linux.vnet.ibm.com> This patch is only an RFC. My internship is ending and I was hoping to get some feedback and incorporate any suggestions people may have before my internship ends along with life as we know it (this Friday). The filesystem should mount/umount properly but tends towards the explosive side when writes start happening. My current focus is on

> On 2014 Dec 10, at 08:40, Tom Stellard <tom at stellard.net> wrote: > > On Tue, Dec 09, 2014 at 09:22:16PM -0800, Duncan P. N. Exon Smith wrote: >> The `Metadata`/`Value` split (PR21532) landed in r223802 -- at least, the >> C++ side of it. This was a rocky day, but I suppose that's what I get >> for failing to stage the change in smaller pieces. >>

Hi, I have a RAID 1 (using mdadm) on CentOS Linux and in /proc/mdstat I see this: md7 : active raid1 sda2[0] sdb2[1] 26627648 blocks [2/2] [UU] [-->> it's OK] md1 : active raid1 sdb3[1] sda3[0] 4192896 blocks [2/2] [UU] [-->> it's OK] md2 : active raid1 sda5[0] sdb5[1] 4192832 blocks [2/2] [UU] [-->> it's OK] md3 : active raid1 sdb6[1] sda6[0] 4192832 blocks [2/2]

Hi R mailing list Does anyone know of a good way to conditionally evaluate R code chunks when Sweaveing? What I'd kind of like to be able to do is set a number of variables in a list and if variable.a=TRUE then process code chunk labelled "methodA", if variable.b=TRUE then process code chunk labelled "methodB" etc <<label=setvars>>= variable.a <- TRUE

Hi, We are using Solaris 10 update 7 with ZFS file system.And using the machine for informix db. Solaris Patch level Generic_142900-02 (Dec 09 PatchCluster release) Informix DB version 11.5FC6 We are facing an issue while enabling DIRECT_IO for the DB chunks. The error message which appears in the online.log file is "Direct I/O cannot be used for the chunk file <file_name>"

Hi, is there a way to collapse/expand the Sweave chunks? Best Riccardo

You might want to take a look at the op_open_callbacks API: https://opus-codec.org/docs/opusfile_api-0.7/group__stream__open__close.html#ga5b81c0b685f3d3c9c7d7091e5536c759 libopusfile will only call your provided read() function as needed. If you don't implement the seeking functions, it will only read it in a linear order. On 04/06/2018 09:08 AM, Chris McGowan wrote: > I would like to

http://bugzilla.mindrot.org/show_bug.cgi?id=916 Summary: SFTP over SSH died after roughly 20MB when asking for >64k chunks Product: Portable OpenSSH Version: 3.8.1p1 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo:

http://bugzilla.mindrot.org/show_bug.cgi?id=916 ------- Additional Comments From dtucker at zip.com.au 2005-01-27 18:05 ------- Does the patch in bug #896 resolve the problem? ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.