Hi,
output here:
[ 590.546162] returning enospc, space_info 3, size 0 reserved 0, flush
2, flush_state 7 dumping space info
[ 590.548280] space_info 4 has 6439292928 free, is full
[ 590.548283] space_info total=25748307968, used=19308916736, pinned=0,
reserved=32768, may_use=6438354944,
Dear list members,
Yesterday I was about to restart my computer and that's why I closed every
opened applications: three Eclipse instances, two other Java applications, 2
web browsers etc. It involved a lot of IO operations and before everything
could settle down my system became unresponsive.
From: Wang Shilong wangsl-f...@cn.fujitsu.com
This patch try to add a check before creating/destroying a qgroup.
Signed-off-by: Wang Shilong wangsl-f...@cn.fujitsu.com
Reviewed-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/ioctl.c | 41 -
1 files
From: Wang Shilong wangsl-f...@cn.fujitsu.com
This is one of most important reason why we introduce a mutex here,
the previous code dosen't check 'src' and 'dst' before assigning/removing
a qgroup relations. Without the mutex lock, and checks may leads
a race conditon.
Signed-off-by: Wang
From: Wang Shilong wangsl-f...@cn.fujitsu.com
The original code dosen't have necessary checks before
doing qgroup_inherit. Fix it.
Signed-off-by: Wang Shilong wangsl-f...@cn.fujitsu.com
Reviewed-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/ioctl.c | 50
From: Wang Shilong wangsl-f...@cn.fujitsu.com
Since mutex has been used for quota operations, we don't have to
hold spin_lock when calling find_qgroup_rb.
Signed-off-by: Wang Shilong wangsl-f...@cn.fujitsu.com
Reviewed-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/qgroup.c | 15
From: Wang Shilong wangsl-f...@cn.fujitsu.com
The check has been done just before starting/joining a transaction,
so we don't need to check it again.
Signed-off-by: Wang Shilong wangsl-f...@cn.fujitsu.com
Reviewed-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/qgroup.c | 20
Hello Arne,
I have sent a patch-set about btrfs quota,
would you please review them for me. Any comment is welcome.
Thanks,
Wang
From: Wang Shilong wangsl-f...@cn.fujitsu.com
This is one of most important reason why we introduce a mutex here,
the previous code dosen't check 'src' and 'dst'
Hi Josef,
Am 26.03.2013 13:53, schrieb Josef Bacik:
On Tue, Mar 26, 2013 at 01:45:42AM -0600, Stefan Priebe wrote:
Hi,
output here:
[ 590.546162] returning enospc, space_info 3, size 0 reserved 0, flush
2, flush_state 7 dumping space info
[ 590.548280] space_info 4 has 6439292928 free,
On Tue, Mar 26, 2013 at 05:37:35AM -0600, Szőts Ákos wrote:
Dear list members,
Yesterday I was about to restart my computer and that's why I closed every
opened applications: three Eclipse instances, two other Java applications, 2
web browsers etc. It involved a lot of IO operations and
On Mon, Mar 25, 2013 at 10:03:20PM -0600, lonat_fr...@163.com wrote:
Hi everyone,
I have used btrfs as a work partition with compression=zlib. The
compression ratio is not satisfied to me.
So you probably want compress-force=zlib. With just compress we will bail out
of the compression
On Sat, Mar 23, 2013 at 01:45:36PM -0500, Eric Sandeen wrote:
The mount manpage is maintained in the util-linux pkg,
but it's not kernel-version specific, and the util-linux
maintainer does not have specific knowledge of all filesytem
options.
Absolutely true. The util-linux maintainer is not
On Tue, Mar 26, 2013 at 06:55:23AM -0600, Stefan Priebe - Profihost AG wrote:
Hi Josef,
Am 26.03.2013 13:53, schrieb Josef Bacik:
On Tue, Mar 26, 2013 at 01:45:42AM -0600, Stefan Priebe wrote:
Hi,
output here:
[ 590.546162] returning enospc, space_info 3, size 0 reserved 0, flush
Hi Josef,
Am 26.03.2013 14:30, schrieb Josef Bacik:
On Tue, Mar 26, 2013 at 06:55:23AM -0600, Stefan Priebe - Profihost AG wrote:
Hi Josef,
Am 26.03.2013 13:53, schrieb Josef Bacik:
On Tue, Mar 26, 2013 at 01:45:42AM -0600, Stefan Priebe wrote:
Hi,
output here:
[ 590.546162] returning
I fixed my file system here, so I can't provide more details now.
Anyway, I cloned your repository and successfully compiled the tree
(except for the mkfs program). But when I try to issue the command
./btrfs-image -c9 /dev/sda7 /home/linux/image.img I get the
following:
Could not open /dev/sda7
Dear list members,
In my previous thread at
http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg2.html
there was a space_cache kernel bug/panic on kernel 3.8. I could
successfully fix that with rebuilding the cache. But some files were
missing/corrupted. So I booted a rescue CD with
On Tue, Mar 26, 2013 at 07:49:16AM -0600, Stefan Priebe - Profihost AG wrote:
Hi Josef,
Am 26.03.2013 14:30, schrieb Josef Bacik:
On Tue, Mar 26, 2013 at 06:55:23AM -0600, Stefan Priebe - Profihost AG
wrote:
Hi Josef,
Am 26.03.2013 13:53, schrieb Josef Bacik:
On Tue, Mar 26,
On Tue, Mar 26, 2013 at 08:33:27AM -0600, Szőts Ákos wrote:
Dear list members,
In my previous thread at
http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg2.html
there was a space_cache kernel bug/panic on kernel 3.8. I could
successfully fix that with rebuilding the cache. But
Hi,
Am 26.03.2013 15:44, schrieb Josef Bacik:
Am 26.03.2013 13:53, schrieb Josef Bacik:
no - it's just mounted with mount -o noatime
:~# cat /proc/mounts | grep btrfs
/dev/mapper/raid54tb1 /mnt btrfs rw,noatime,space_cache 0 0
Ok I think I see what's going on. Can you try this patch and
3.8.0+ #3
This happened after 'umount /btrfs' was interrupted by ctl-C
# mount | egrep btrfs
/dev/mapper/mpathe on /btrfs type btrfs (rw,degraded)
# cat /etc/mtab | egrep btrfs
/dev/mapper/mpathe /btrfs btrfs rw,degraded 0 0
# cat /proc/mounts | egrep btrfs
# umount /btrfs
umount: /btrfs:
On Tue, Mar 26, 2013 at 09:03:11AM -0600, Stefan Priebe - Profihost AG wrote:
Hi,
Am 26.03.2013 15:44, schrieb Josef Bacik:
Am 26.03.2013 13:53, schrieb Josef Bacik:
no - it's just mounted with mount -o noatime
:~# cat /proc/mounts | grep btrfs
/dev/mapper/raid54tb1 /mnt btrfs
On Tue, Mar 26, 2013 at 09:24:02AM -0600, anand jain wrote:
3.8.0+ #3
This happened after 'umount /btrfs' was interrupted by ctl-C
# mount | egrep btrfs
/dev/mapper/mpathe on /btrfs type btrfs (rw,degraded)
# cat /etc/mtab | egrep btrfs
/dev/mapper/mpathe /btrfs btrfs rw,degraded 0 0
The error was just a silly permission denied one.
I uploaded the created image to www.morrohun.hu/temp/btrfs/btrfs.img
SHA1: 90ee61e0724700495d26678d58dc229e04a04cc4
Please, write me when you downloaded and I'll delete it.
I have the idea to run btrfsck from your tree on the file system
again,
HI,
Am 26.03.2013 16:25, schrieb Josef Bacik:
On Tue, Mar 26, 2013 at 09:03:11AM -0600, Stefan Priebe - Profihost AG wrote:
Hi,
Am 26.03.2013 15:44, schrieb Josef Bacik:
Am 26.03.2013 13:53, schrieb Josef Bacik:
no - it's just mounted with mount -o noatime
:~# cat /proc/mounts | grep btrfs
On Tue, Mar 26, 2013 at 09:59:57AM -0600, Szőts Ákos wrote:
The error was just a silly permission denied one.
I uploaded the created image to www.morrohun.hu/temp/btrfs/btrfs.img
SHA1: 90ee61e0724700495d26678d58dc229e04a04cc4
Please, write me when you downloaded and I'll delete it.
I have
On Tue, Mar 26, 2013 at 10:19:19AM -0600, Stefan Priebe wrote:
HI,
Am 26.03.2013 16:25, schrieb Josef Bacik:
On Tue, Mar 26, 2013 at 09:03:11AM -0600, Stefan Priebe - Profihost AG
wrote:
Hi,
Am 26.03.2013 15:44, schrieb Josef Bacik:
Am 26.03.2013 13:53, schrieb Josef Bacik:
no -
On Tue, Mar 26, 2013 at 10:27:34AM -0600, yiletian wrote:
Yes, I use compress-force=zlib for my partition.
Consider this scenario.
We first write a file with size of 256KB. Assume all data is compressed to
128KB size,
btrfs create a extent item in extent-tree to record the 128KB disk
On Tue, Mar 26, 2013 at 09:59:57AM -0600, Szőts Ákos wrote:
The error was just a silly permission denied one.
I uploaded the created image to www.morrohun.hu/temp/btrfs/btrfs.img
SHA1: 90ee61e0724700495d26678d58dc229e04a04cc4
Please, write me when you downloaded and I'll delete it.
I have
I think the biggest problem is how we can reclaim the space when the extent is
a compressed one.
In this case, we may need to read and decompress data in the extent, and then
compress the valid range to generate a new extent.
Is this process a performance killer?
At 2013-03-27 02:03:57,Josef
If my memory servers me well, it was taken in unmounted state. Do you
want me to take an other one and compare the SHA1 values?
--
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
On Tue, Mar 26, 2013 at 12:25:44PM -0600, Szőts Ákos wrote:
If my memory servers me well, it was taken in unmounted state. Do you
want me to take an other one and compare the SHA1 values?
Nope I found the bug, just a problem with the restore. Thanks,
Josef
--
To unsubscribe from this list:
Hi Josef,
Am 26.03.2013 18:45, schrieb Josef Bacik:
Am 26.03.2013 16:25, schrieb Josef Bacik:
On Tue, Mar 26, 2013 at 09:03:11AM -0600, Stefan Priebe - Profihost AG wrote:
Hi,
Am 26.03.2013 15:44, schrieb Josef Bacik:
Am 26.03.2013 13:53, schrieb Josef Bacik:
no - it's just mounted with
On Tue, Mar 26, 2013 at 01:05:36PM -0600, Stefan Priebe wrote:
Hi Josef,
Am 26.03.2013 18:45, schrieb Josef Bacik:
Am 26.03.2013 16:25, schrieb Josef Bacik:
On Tue, Mar 26, 2013 at 09:03:11AM -0600, Stefan Priebe - Profihost AG
wrote:
Hi,
Am 26.03.2013 15:44, schrieb Josef Bacik:
We are way over-reserving for unlink and rename. Rename is just some random
huge number and unlink accounts for tree log operations that don't actually
happen during unlink, not to mention the tree log doesn't take from the trans
block rsv anyway so it's completely useless. Thanks,
Hi,
but when i transfer big files i see now this one:
[20368.784736] INFO: task rsync:14911 blocked for more than 120 seconds.
[20368.821978] echo 0 /proc/sys/kernel/hung_task_timeout_secs
disables this message.
[20368.895140] rsync D 8160f580 0 14911 1
0x
We need to hold the ordered_operations mutex while waiting on ordered extents
since we splice and run the ordered extents list. We need to make sure anybody
else who wants to wait on ordered extents does actually wait for them to be
completed. This will keep us from bailing out of flushing in
A user reported a problem where he was getting early ENOSPC with hundreds of
gigs of free data space and 6 gigs of free metadata space. This is because the
global block reserve was taking up the entire free metadata space. This is
ridiculous, we have infrastructure in place to throttle if we
Document all current btrfs mount options.
Signed-off-by: Eric Sandeen sand...@redhat.com
---
V2:
* reflect that btrfs is no longer new ;)
* make it clear that alloc_start is for each device
* highlight potential perf impacts of -o discard
* reword skip_balance docs to refer to resume
diff
On Tue, Mar 26, 2013 at 01:22:20PM -0600, Stefan Priebe wrote:
Hi,
but when i transfer big files i see now this one:
[20368.784736] INFO: task rsync:14911 blocked for more than 120 seconds.
[20368.821978] echo 0 /proc/sys/kernel/hung_task_timeout_secs
disables this message.
HI,
Am 26.03.2013 20:38, schrieb Josef Bacik:
On Tue, Mar 26, 2013 at 01:22:20PM -0600, Stefan Priebe wrote:
Hi,
but when i transfer big files i see now this one:
[20368.784736] INFO: task rsync:14911 blocked for more than 120 seconds.
[20368.821978] echo 0
Hi,
I am using a btrfs loopback mounted file with lzo-compression on
Linux-3.7.9, and I ran into No space left on device messages,
although df reports only 55% of space is used:
# touch testfile
touch: cannot touch `testfile': No space left on device
# df
Filesystem 1K-blocks Used
All,
The btrfs qgroup limit command has an option -c which means limit amount
of data after compression. Whether this option is specified or not, I seem
to be able to write more well-compressible data than the specified limit. I
was expecting that omitting the -c option would never allow me to
HI,
When i work on btrfs hot relocation feature, i hit one question
about block reservation. btrfs hot relocation need to reserve block
space from specific devices such as SSD, but current btrfs reserving
code doesn't differentiate if block space is reserved from SSD or HDD.
In order to make
Bit late - but that could be explored in future. The main downside I see
with automatic redundancy/optimisation is the complexity it
introduces. Likely this would be best served with user-space tools.
On 11/03/13 02:21, Roger Binns wrote:
On 10/03/13 15:04, Hugo Mills wrote:
Given that this
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 26/03/13 21:27, Brendan Hide wrote:
On 11/03/13 02:21, Roger Binns wrote:
Why does all data have to be rewritten? Why does every piece of data
have to have exactly the same storage parameters in terms of
non-redundancy/performance/striping
45 matches
Mail list logo
