The btrfs_read_sys_array function uses 3 variants to read data from
super block.
But the three variants are related to each other, so the patch removes
unneeded extra variants and make code a little simpler.
Signed-off-by: Qu Wenruo quwen...@cn.fujitsu.com
Reviewed-by: Miao Xie
On 06/27/2013 09:57 AM, Josef Bacik wrote:
If you use the SCRATCH_DEV_POOL for btrfs you will end up with the command line
like this
mkfs.btrfs $SCRATCH_DEV_POOL $SCRATCH_DEV
and btrfs does this thing where it makes the lowest valued device id show up in
/proc/mounts no matter which device
The btrfs_read_sys_array function uses 3 variants to read data from
super block.
But the three variants are related to each other, so the patch removes
unneeded extra variants and make code a little simpler.
Signed-off-by: Qu Wenruo quwen...@cn.fujitsu.com
Reviewed-by: Miao Xie
Hi all,
We now have several desktop search engines. We can get what we want in
the hard disk easily. For example, when we are going to search for
songs, we can search for the files with suffix '.mp3', '.wav' and
something else. Isn't it very convenient?
However, this is not enough in some
- It make no sense that we continue to do something after the error
happened, just go back with this patch.
- remove some check of copy_nocow_pages_for_inode(), such as page check
after write, inode check in the end of the function, because we are
sure they exist.
- remove the unnecessary
- It makes no sense that we deal with a inode in the dead tree.
- fix the race between dio and page copy by waiting the dio completion
- avoid the page copy vs truncate/punch hole
- check if the page is in the page cache or not
Signed-off-by: Miao Xie mi...@cn.fujitsu.com
---
fs/btrfs/scrub.c |
We get oops while running btrfs replace start test,
[ cut here ]
kernel BUG at mm/filemap.c:608!
[SNIP]
Call Trace:
[a04b36c7] copy_nocow_pages_for_inode+0x217/0x3f0 [btrfs]
[a04b34b0] ? scrub_print_warning_inode+0x230/0x230 [btrfs]
[a04b34b0]
Hello,
I'm trying to fix a btrfs file system. BTRFSCK reports errors in the
extend tree.
I've tryong to use --repair option but it ended up with an assertion
failure.
I'm also trying to understand how the filesystem can have become corrupted.
I'm running Ubuntu 12.10.
Any suggestion on ways to
On Thu, 27 Jun 2013, Kelvin kelvin9302...@gmail.com wrote:
It seems that there are some tagging systems, but they are not native
for the filesystem. It means that when we read the filesystem from an
OS without that system installed, everything will be in a mess (or we
can arrange the files in
On Thu, Jun 27, 2013 at 03:54:33PM +0200, Stéphane Mutz wrote:
Hello,
I'm trying to fix a btrfs file system. BTRFSCK reports errors in the
extend tree.
I've tryong to use --repair option but it ended up with an assertion
failure.
I'm also trying to understand how the filesystem can have
Roger Pack posted on Wed, 26 Jun 2013 15:04:56 -0600 as excerpted:
First off, thanks for an awesome file system, it is working well for my
purposes of compressing a filesystem on a small VPS. Woot!
I thought I'd call out a few things (in the hopes of spurring
improvements) I'd seen about
Hi,
I've built the GIT tools and run btrfsck (without options) following the
wiki page.
I got the following log:
Checking filesystem on /dev/VG_NL-SAS/LV_snap
UUID: de300fd0-1251-4767-9d80-84ce7ebfba9a
checking extents
checking free space cache
free space inode generation (0) did not match free
On Thu, Jun 27, 2013 at 04:23:45PM +0200, Stéphane Mutz wrote:
Hi,
I've built the GIT tools and run btrfsck (without options) following the
wiki page.
I got the following log:
Checking filesystem on /dev/VG_NL-SAS/LV_snap
UUID: de300fd0-1251-4767-9d80-84ce7ebfba9a
checking extents
Another bug caused by this script.
https://github.com/kernelslacker/io-tests/blob/master/setup.sh
WARNING: at kernel/lockdep.c:708 __lock_acquire+0x183b/0x1b70()
Modules linked in: sctp lec bridge 8021q garp stp mrp fuse dlci tun bnep hidp
rfcomm l2tp_ppp l2tp_netlink l2tp_core
Thanks a lot for the support.
The fs metadata allocation was full. I did the balance operation
and things seem to be back to normal.
It is a bit confusing and hard to predict when the fs is close to running
out of space on one of its pool. I still had 60GB+ free data space when
it happened.
The
Quoting Dave Jones (2013-06-27 10:58:24)
Another bug caused by this script.
https://github.com/kernelslacker/io-tests/blob/master/setup.sh
I'm still struggling to reproduce that one here. I've tried every
variation I can think of but I'll try again.
I really hope you don't already have
That's a great idea to use XATTR values to implement this! The
simulated directory can be a transparent way provided to search for
the XATTR containing the corresponding tags.
2013/6/27 Russell Coker russ...@coker.com.au:
On Thu, 27 Jun 2013, Kelvin kelvin9302...@gmail.com wrote:
It seems that
On Thu, Jun 27, 2013 at 11:01:30AM -0400, Chris Mason wrote:
Quoting Dave Jones (2013-06-27 10:58:24)
Another bug caused by this script.
https://github.com/kernelslacker/io-tests/blob/master/setup.sh
I'm still struggling to reproduce that one here. I've tried every
variation I can
I hit a weird problem were my root item had been deleted but the orphan item had
not. This isn't necessarily a problem, but it keeps the file system from being
mounted. To fix this we just need to axe the orphan item if we can't find the
fs root when we're putting them altogether. With this
Quoting Dave Jones (2013-06-27 11:19:22)
On Thu, Jun 27, 2013 at 11:01:30AM -0400, Chris Mason wrote:
Quoting Dave Jones (2013-06-27 10:58:24)
Another bug caused by this script.
https://github.com/kernelslacker/io-tests/blob/master/setup.sh
I'm still struggling to reproduce that
On Thu, Jun 27, 2013 at 10:58:24AM -0400, Dave Jones wrote:
Another bug caused by this script.
https://github.com/kernelslacker/io-tests/blob/master/setup.sh
WARNING: at kernel/lockdep.c:708 __lock_acquire+0x183b/0x1b70()
Modules linked in: sctp lec bridge 8021q garp stp mrp fuse dlci tun
On Thu, Jun 27, 2013 at 11:38:57AM -0400, Chris Mason wrote:
I really hope you don't already have CONFIG_DEBUG_PAGE_ALLOC turned on,
maybe it will catch this?
I do. Though given this is lockdep complaining about what looks like
memory corruption, it's probably not related.
When adjusting the enospc rules for relocation I ran into a deadlock because we
were relocating the only system chunk and that forced us to try and allocate a
new system chunk while holding locks in the chunk tree, which caused us to
deadlock. To fix this I've moved all of the dev extent addition
There are a few problems with btrfs/265. First we don't redirect the output of
btrfs fi ba somwhere else, so we fail this test outright. Secondly if you have
less than 4 devices in your scratch dev pool it won't work because you can't
mkfs raid10 without 4 devices. This is all impossible to
I hit a weird problem were my root item had been deleted but the orphan item had
not. This isn't necessarily a problem, but it keeps the file system from being
mounted. To fix this we just need to axe the orphan item if we can't find the
fs root when we're putting them altogether. With this
Reviewing as requested! It certainly looks reasonable, but I don't have
enough history with the code to really say much more than that.
Some questions:
@@ -8423,6 +8432,10 @@ void btrfs_create_pending_block_groups(struct
btrfs_trans_handle *trans,
Several users reported this crash of NULL pointer or general protection,
the story is that we add a rbtree for speedup ulist iteration, and we
use krealloc() to address ulist growth, and krealloc() use memcpy to copy
old data to new memory area, so it's OK for an array as it doesn't use
pointers
Hi Liu,
Several users reported this crash of NULL pointer or general protection,
the story is that we add a rbtree for speedup ulist iteration, and we
use krealloc() to address ulist growth, and krealloc() use memcpy to copy
old data to new memory area, so it's OK for an array as it doesn't
On Fri, Jun 28, 2013 at 11:28:39AM +0800, Wang Shilong wrote:
Hi Liu,
Several users reported this crash of NULL pointer or general protection,
the story is that we add a rbtree for speedup ulist iteration, and we
use krealloc() to address ulist growth, and krealloc() use memcpy to copy
Several users reported this crash of NULL pointer or general protection,
the story is that we add a rbtree for speedup ulist iteration, and we
use krealloc() to address ulist growth, and krealloc() use memcpy to copy
old data to new memory area, so it's OK for an array as it doesn't use
pointers
From: Jie Liu jeff@oracle.com
Create a small file and fallocate it to a big size with
FALLOC_FL_KEEP_SIZE option, then truncate it back to the
small size again, the disk free space is not changed back
in this case. i.e,
# dd if=/dev/zero of=/mnt/test bs=512 count=1
# ls -l /mnt
total 4
31 matches
Mail list logo
