-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
You are right. Some time ago I have already sent a patch for this. Hugo,
can you please integrate it?
Thanks,
Andreas Philipp
[PATCH] check number of args for btrfs sub snap correctly
Check whether there are the right number of arguments (e
Hi, Hugo,
I built your for-chris branch, and ran 'btrfs sub snap' command.
Then, I encountered following error message.
# btrfs sub snap Dir-1 Dir-2
Invalid arguments for subvolume snapshot
commit:8b4c2a22bff85f86af44587973c8da8c29a67ffc is wrong, I think.
(2011/07/01 21:55), Stephane Chaze
On 08/10/2011 10:18 PM, Tsutomu Itoh wrote:
> (2011/08/11 10:58), Jeff Mahoney wrote:
>> On 08/10/2011 09:27 PM, Tsutomu Itoh wrote:
>>> Hi, Jeff,
>>>
>>> (2011/08/11 8:20), Jeff Mahoney wrote:
This patch handles btrfs_start_transaction failures that don't occur
in a loop and are ob
(2011/08/11 10:58), Jeff Mahoney wrote:
> On 08/10/2011 09:27 PM, Tsutomu Itoh wrote:
>> Hi, Jeff,
>>
>> (2011/08/11 8:20), Jeff Mahoney wrote:
>>> This patch handles btrfs_start_transaction failures that don't occur
>>> in a loop and are obvious to simply push up. In all cases except the
>>>
On 08/10/2011 09:27 PM, Tsutomu Itoh wrote:
> Hi, Jeff,
>
> (2011/08/11 8:20), Jeff Mahoney wrote:
>> This patch handles btrfs_start_transaction failures that don't occur
>> in a loop and are obvious to simply push up. In all cases except the
>> mark_garbage_root case, the error is already h
Hi, Jeff,
(2011/08/11 8:20), Jeff Mahoney wrote:
> This patch handles btrfs_start_transaction failures that don't occur
> in a loop and are obvious to simply push up. In all cases except the
> mark_garbage_root case, the error is already handled by BUG_ON in the
> caller.
>
> Signed-off-by: J
On 08/10/2011 07:20 PM, Jeff Mahoney wrote:
> --- a/fs/btrfs/extent_io.c
> +++ b/fs/btrfs/extent_io.c
[...]
Oops. This is missing one more case. I'll re-send this one as part
of a general post-review re-send.
@@ -3292,8 +3316,10 @@ int set_extent_buffer_uptodate(struct ex
num_pages = num
In the locking case, set_extent_bit can return -EEXIST but callers
already handle that.
In the non-locking case, it can't fail. Memory allocation failures are
handled by BUG_ON.
This patch pushes up the BUG_ONs from set_extent_bit to callers, except
where -ENOMEM can't occur (e.g. __GFP_WAI
btrfs_pin_extent looks up a block group and then calls pin_down_extent
with it. If the lookup fails, it should return -ENOENT to allow callers
to handle the error condition. For the three existing callers, it is
a logic error if the lookup fails and a panic will occur.
Signed-off-by: Jeff Maho
clear_extent_bit can fail with -ENOMEM for a specific case but will BUG
on other memory allocation failures.
This patch returns -ENOMEM for memory allocation failures and handles them
with BUG_ON in callers which don't handle it already.
Signed-off-by: Jeff Mahoney
---
fs/btrfs/disk-io.c
lock_extent, try_lock_extent, and lock_extent_bits can't currently fail
because errors are caught via BUG_ON.
This patch pushes the error handling up to callers, which currently
only handle them via BUG_ON themselves.
Signed-off-by: Jeff Mahoney
---
fs/btrfs/compression.c |3 +-
fs
This patch handles btrfs_start_transaction failures that don't occur
in a loop and are obvious to simply push up. In all cases except the
mark_garbage_root case, the error is already handled by BUG_ON in the
caller.
Signed-off-by: Jeff Mahoney
---
fs/btrfs/extent-tree.c |6 +-
fs/btr
The previous patch pushed the clear_extent_bit error handling up a level,
which included unlock_extent and unlock_extent_cache.
This patch pushes the BUG_ON up into the callers of those functions.
Signed-off-by: Jeff Mahoney
---
fs/btrfs/compression.c |6 +-
fs/btrfs/disk-io.c
pin_down_extent performs some operations which can't fail and then calls
set_extent_dirty, which has two failure cases via set_extent_bit:
1) Return -EEXIST if exclusive bits are set
- Since it doesn't use any exclusive bits, this failure case can't
occur.
2) Return -ENOMEM if memory
As part of the effort to eliminate BUG_ON as an error handling
technique, we need to determine which errors are actual logic errors,
which are on-disk corruption, and which are normal runtime errors
e.g. -ENOMEM.
Annotating these error cases is helpful to understand and report them.
This pa
The *_state functions can only return 0 or -EEXIST. This patch addresses
the cases where those functions return -EEXIST, representing a locking
failure. It handles them by panicking with an appropriate error message.
Signed-off-by: Jeff Mahoney
---
fs/btrfs/extent_io.c | 42
Hi all -
The following 8 patches add more error handling to the btrfs code:
- Add btrfs_panic
- Catch locking failures in {set,clear}_extent_bit
- Push up set_extent_bit errors to callers
- Push up lock_extent errors to callers
- Push up clear_extent_bit errors to callers
- Push up unlock_e
We need to truncate page cache pages for the clone ioctl target range or
else we'll confuse ourselves to no end. If the old data was cached, we
used to still see it (until remount). If the page was partially updated
we used to get a mix of old and new data.
Signed-off-by: Sage Weil
---
v1->v2:
On Wed, Aug 10, 2011 at 11:36:09AM -0500, Alex Elder wrote:
> > Possible ways to fix this:
> > 1) use /sbin/mkfs -t $FSTYP like _scratch_mkfs, or
> > 2) set $MKFS_BTRFS_PROG like for some other filesystems
> >
> >
> > What is preferred?
>
> Whatever works. My personal preference would be option
On Wed, 2011-08-10 at 12:33 -0400, Christoph Hellwig wrote:
> On Wed, Aug 10, 2011 at 05:52:14PM +0200, David Sterba wrote:
> > there's a hardcoded path for mkfs.btrfs in common.rc:_scratch_mkfs_sized()
> >
> > 335 btrfs)
> > 336 /sbin/mkfs.$FSTYP $MKFS_OPTIONS $SCRATCH_DEV -b $fssize
On Wed, 2011-08-10 at 17:52 +0200, David Sterba wrote:
> Hi,
>
> On Mon, Aug 01, 2011 at 12:31:19PM +0200, Stefan Behrens wrote:
> > Use _scratch_mkfs / _scratch_mkfs_sized instead of _scratch_mkfs_xfs
> > where possible.
> > Execute 015, 062, 083, 117, 120 and 192 for all filesystems, these
> > t
On Wed, Aug 10, 2011 at 05:52:14PM +0200, David Sterba wrote:
> there's a hardcoded path for mkfs.btrfs in common.rc:_scratch_mkfs_sized()
>
> 335 btrfs)
> 336 /sbin/mkfs.$FSTYP $MKFS_OPTIONS $SCRATCH_DEV -b $fssize
> 337 ;;
>
> I have a /usr/local/ installation of btrfsprogs
Hi,
On Mon, Aug 01, 2011 at 12:31:19PM +0200, Stefan Behrens wrote:
> Use _scratch_mkfs / _scratch_mkfs_sized instead of _scratch_mkfs_xfs
> where possible.
> Execute 015, 062, 083, 117, 120 and 192 for all filesystems, these
> tests used to be XFS specific.
this patch is now in xfstests-dev and
On Tuesday, 02 August, 2011 11:43:39 you wrote:
> On 01.08.2011 20:51, Goffredo Baroncelli wrote:
[...]
> > 1) If we are interested to transport only the file
> > type/contents/timestamps/acls/owners/permissions, that could be obtained
> > with a combination of "find-new" (with some extensions [1])
On Wednesday, 03 August, 2011 17:04:40 Jan Schmidt wrote:
> On 02.08.2011 19:42, Goffredo Baroncelli wrote:
> >> Furthermore, receiving should not need kernel support at all (except for
> >> an optional interface to create a file with a certain inode, we'll see).
> >> Thus, replicating metadata cor
On 21.05.2011 01:05, Miguel Garrido wrote:
> On Fri, May 20, 2011 at 12:35 PM, Tomasz Chmielewski wrote:
>>
>> Nobody has a clue what makes btrfs run out of space when used with
>> PostgreSQL, even when there is plenty of free space left?
>>
>>
>> # df -h
>> FilesystemSize Used Avail
Hi,
Recently I suffered from a badly corrupted btrfs filesystem.
I had several snapshots in /snap that I moved into / (using /bin/mv). After
that, attempting to access the ls the snapshot resulted in the ls process
hanging. There were syslog messages:
Aug 7 20:56:42 i kernel: [ 111.882816]
27 matches
Mail list logo
