A user reported a problem with his fs where he had a bogus isize on his
directory. In order to make sure my patch for fsck fixes this properly I needed
to be able to corrupt an inode like this, which is what this patch is for.
Eventually I want to extend this to corrupt everything so we can
If you start the replace procedure on a read only filesystem, at
the end the procedure fails to write the updated dev_items to the
chunk tree. The problem is that this error is not indicated except
for a WARN_ON(). If the user now thinks that everything was done
as expected and destroys the source
A user reported a problem where he was unable to rmdir an empty directory. This
is because his isize was wrong. This patch will fix this sort of corruption and
allow him to rmdir his directory. Thanks
Signed-off-by: Josef Bacik jba...@fusionio.com
---
cmds-check.c | 86
Running sparse I found a few small things where we should have static functions
that aren't used externally and we should be using unsigned values for bit
fields. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/disk-io.c |8
fs/btrfs/send.c|4 ++--
2
When adding orphans to an inode's root, we start a transaction for
that root that when ended in several places such as for example
extent-tree.c:btrfs_remove_block_group(), inode.c:btrfs_unlink() and
inode.c:btrfs_evict_node(), doesn't result in a commit, that is,
On 08/19/2013 20:21, Josef Bacik wrote:
Running sparse I found a few small things where we should have static functions
that aren't used externally and we should be using unsigned values for bit
fields. Thanks,
Signed-off-by: Josef Bacik jba...@fusionio.com
---
fs/btrfs/disk-io.c |8
On Mon, Aug 19, 2013 at 08:47:21PM +0200, Stefan Behrens wrote:
On 08/19/2013 20:21, Josef Bacik wrote:
Running sparse I found a few small things where we should have static
functions
that aren't used externally and we should be using unsigned values for bit
fields. Thanks,
+static void print_df(struct btrfs_ioctl_space_args *sargs)
+{
+ char description[80];
+ char *total_bytes;
+ char *used_bytes;
+ u64 flags;
+ u64 i;
+ int written;
+ char g_str[64];
+ int g_sz;
+ for (i = 0; i sargs-total_spaces; i++) {
+
This issue is simple to reproduce and observe if kmemleak is enabled.
Two simple ways to reproduce it:
** 1
$ mkfs.btrfs -f /dev/loop0
$ mount /dev/loop0 /mnt/btrfs
$ btrfs balance start /mnt/btrfs
$ umount /mnt/btrfs
** 2
$ mkfs.btrfs -f /dev/loop0
$ mount /dev/loop0 /mnt/btrfs
$ touch
This issue is simple to reproduce and observe if kmemleak is enabled.
Two simple ways to reproduce it:
** 1
$ mkfs.btrfs -f /dev/loop0
$ mount /dev/loop0 /mnt/btrfs
$ btrfs balance start /mnt/btrfs
$ umount /mnt/btrfs
** 2
$ mkfs.btrfs -f /dev/loop0
$ mount /dev/loop0 /mnt/btrfs
$ touch
This issue is simple to reproduce and observe if kmemleak is enabled.
Two simple ways to reproduce it:
** 1
$ mkfs.btrfs -f /dev/loop0
$ mount /dev/loop0 /mnt/btrfs
$ btrfs balance start /mnt/btrfs
$ umount /mnt/btrfs
** 2
$ mkfs.btrfs -f /dev/loop0
$ mount /dev/loop0 /mnt/btrfs
$ touch
Thanks for the patch Stefan, it has been committed.
--Rich
commit 6bd8df93fa6b7d9ce402f9c665e5971106df7843
Author: Stefan Behrens sbehr...@giantdisaster.de
Date: Fri Aug 16 17:44:54 2013 +
xfstests: btrfs/009 never shrinked or removed $seqres.full
Signed-off-by: Stefan Behrens
Ok, so the fix is now in 3.10.6 and I'm using that. I don't get the hang
anymore, but now I'm having a new problem.
Mount options --
rw,noatime,nodiratime,compress-force=zlib,space_cache,inode_cache,ssd
I need compression because I get a very high compression ratio with my data
and I have lots
There was a problem with send trying to overwrite a file that wasn't actually
the same. This is a test to check this particular case where receive fails when
it should succeed properly. I tested this to verify it fails without my fix and
passes with my fix. Thanks,
Signed-off-by: Josef Bacik
Hi,
during a balance I got the BUG from the subject line, followed by
BUG: unable to handle kernel paging request at 0008a940.
The machine needed to be rebooted afterwards; the filesystem was
successfully mounted and the balance resumed and finished successfully.
I then ran scrub which
This issue is simple to reproduce and observe if kmemleak is enabled.
Two simple ways to reproduce it:
** 1
$ mkfs.btrfs -f /dev/loop0
$ mount /dev/loop0 /mnt/btrfs
$ btrfs balance start /mnt/btrfs
$ umount /mnt/btrfs
** 2
$ mkfs.btrfs -f /dev/loop0
$ mount /dev/loop0 /mnt/btrfs
$ touch
Quoting Eric Sandeen (2013-08-17 23:50:51)
On 8/17/13 10:25 PM, Tom Gundersen wrote:
On Sat, Aug 17, 2013 at 7:59 PM, Chris Mason chris.ma...@fusionio.com
wrote:
The problem with the progs release is I keep finding more things I want
to add. My local git tree has about a dozen commits
17 matches
Mail list logo