From: Jie Liu
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
-rw-r--r-- 1 root root 51
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 wh
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
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'
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 wh
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,
> siz
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 patc
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 figu
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
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 re
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 t
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 reprod
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 patc
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
> variatio
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 :
> On Thu, 27 Jun 2013, Kelvin wrote:
>> It seems that there are some tagging systems, but they
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 CONF
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
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 vmw_vsock_vmci_tr
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
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 sp
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 ab
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 ca
On Thu, 27 Jun 2013, Kelvin 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 traditional way as w
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 f
- 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
---
fs/btrfs/scrub.c | 23 ++
We get oops while running btrfs replace start test,
[ cut here ]
kernel BUG at mm/filemap.c:608!
[SNIP]
Call Trace:
[] copy_nocow_pages_for_inode+0x217/0x3f0 [btrfs]
[] ? scrub_print_warning_inode+0x230/0x230 [btrfs]
[] ? scrub_print_warning_inode+0x230/0x230 [btrfs]
- 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 got
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 situati
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
Reviewed-by: Miao Xie
---
fs/btrfs/volumes.c | 17 +--
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
30 matches
Mail list logo
