On Thu, 7 Aug 2014 15:50:30 +0800, Liu Bo wrote:
[90496.156016] kworker/u8:14 D 880044e38540 0 21050 2
0x
[90496.157683] Workqueue: btrfs-delalloc normal_work_helper [btrfs]
[90496.159320] 88022880f990 0002 880407f649b0
88022880ffd8
On Mon, 4 Aug 2014 01:29:49 AM rocwhite168 wrote:
being able to recover at least somewhat
in this situation seems to be a desired feature for any file system.
I would add that only specially designed clustered/distributed filesystems will
survive this sort of accident.
All the best,
Chris
--
The file hole detection logic during a file fsync wasn't correct,
because it didn't look back (in a previous leaf) for the last file
extent item that can be in a leaf to the left of our leaf and that
has a generation lower than the current transaction id. This made it
assume that a hole exists
(2014/08/04 16:28), Qu Wenruo wrote:
Missing '+'s cause '-B' option not displayed correctly, add it to fix.
Signed-off-by: Qu Wenruo quwen...@cn.fujitsu.com
Reviewed-by: Satoru Takeuchi takeuchi_sat...@jp.fujitsu.com
Tested-by: Satoru Takeuchi takeuchi_sat...@jp.fujitsu.com
---
Hi Qu,
(2014/08/01 12:27), Qu Wenruo wrote:
According to Documentations/filesystem/btrfs.txt, ssd/ssd_spread/nossd
has their own dependency(See below), but only ssd_spread implying ssd is
implemented.
ssd_spread implies ssd, conflicts nossd.
ssd conflicts nossd.
nossd conflicts ssd and
On 08/07/2014 04:20 AM, Miao Xie wrote:
On Thu, 7 Aug 2014 15:50:30 +0800, Liu Bo wrote:
[90496.156016] kworker/u8:14 D 880044e38540 0 21050 2
0x
[90496.157683] Workqueue: btrfs-delalloc normal_work_helper [btrfs]
[90496.159320] 88022880f990 0002
Hi
Is there anything new on this topic? I am using Ubuntu 14.04.1 and
experiencing the same problem.
- 6 HDDs
- LUKS on every HDD
- btrfs RAID6 over this 6 crypt-devices
No LVM, no nodatacow files.
Mount-options: defaults,compress-force=lzo,space_cache
With the original 3.13-kernel
# btrfs send /mnt/320G/2012april_HDD_fullbackup.ro.0/ | btrfs receive /mnt/500G/
At subvol /mnt/320G/2012april_HDD_fullbackup.ro.0/
At subvol 2012april_HDD_fullbackup.ro.0
ERROR: send ioctl failed with -12: Cannot allocate memory
ERROR: unexpected EOF in stream.
kernel-3.16.0-1.fc21.x86_64
Tobias Holst posted on Thu, 07 Aug 2014 17:12:17 +0200 as excerpted:
Is there anything new on this topic? I am using Ubuntu 14.04.1 and
experiencing the same problem.
- 6 HDDs - LUKS on every HDD - btrfs RAID6 over this 6 crypt-devices No
LVM, no nodatacow files.
Mount-options:
Kernel 3.16.0 from git, btrfs-progs 3.14.2 from git, gentoo/~amd64.
Earlier today I had a device (SSD) not respond quickly enough after
resume from suspend-to-ram, a problem I had frequently some months ago,
but that I though was fixed as I've not had it in awhile.
The affected filesystems
Arne Jansen sensille at gmx.net writes:
On 24.01.2013 16:12, Jerome M wrote:
Hi,
With the current btrfs quota implementation, when you reach a
subvolume quota limit, you can't delete anything without first
removing the limit or enlarge it:
rm: cannot remove `testfile.bin': Disk
On Tue, Jul 29, 2014 at 10:24 AM, Miao Xie mi...@cn.fujitsu.com wrote:
The current code would load checksum data for several times when we split
a whole direct read io because of the limit of the raid stripe, it would
make us search the csum tree for several times. In fact, it just wasted time,
If an inode has a very large number of extent maps, we can spend
a lot of time freeing them, which triggers a soft lockup warning.
Therefore reschedule if we need to when freeing the extent maps
while evicting the inode.
I could trigger this all the time by running xfstests/generic/299 on
a file
13 matches
Mail list logo
