Hi,
The following two stacktraces appeared in my syslog (are they of any use?).
The "possible recursive locking" occured around the end of untaring a 4gig tar
ball.
I think the other one occurred during a 'yum upgrade'.
Cheers,
Ralph.
Dec 24 20:26:01 i kernel: [113505.458570]
Dec 24 20:26:0
cwillu wrote:
> On Wed, Nov 17, 2010 at 8:08 PM, Li Zefan wrote:
>> Hi Chris,
>>
>> Here's the updated patchset. As I still haven't got a kernel.org
>> account, I have set up a git tree in another public git repository,
>> and I'll use it for now.
>>
>> You can pull from:
>>
>>git://repo.o
On Wed, Nov 17, 2010 at 8:08 PM, Li Zefan wrote:
> Hi Chris,
>
> Here's the updated patchset. As I still haven't got a kernel.org
> account, I have set up a git tree in another public git repository,
> and I'll use it for now.
>
> You can pull from:
>
> git://repo.or.cz/linux-btrfs-devel.gi
Hi,
> Currently I'm running with -rc7. If the system still runs
> tomorrow morning I will do another test with -rc5 - this time on
> the USB 3.0 port. This should show whether this is a hardware or
> software problem.
Thanks, sounds good. Yes, the location of the BUG() does suggest a
Hi, Chris!
>> But exactly the same crash happened again some minutes ago. (I'm
>> now back to my old kernel.)
>
> Not sure I understand. Do you mean that the same crash happens on
> your older kernel now, or that you've reverted to your older kernel
> because you had another -rc5 crash
Hi Michael,
>> in write_all_supers(). Does dmesg say anything about the nature
>> of the errors above the BUG() line?
> The message was output to the console of the crashed system - so
> I'm sorry I cannot supply further informations.
Ah, okay. You could consider installing kgdb/kd
Hi!
>> Hi! I got a kernel BUG at
>>
>> fs/btrfs/disk-io.c:2311
>>
>> when testing the 2.6.37-rc5 kernel today.
>
> It's good to mention which line this is, since the line numbers are
> always changing. This is:
>
> if (total_errors > max_errors) {
>
Hi,
> Hi! I got a kernel BUG at
>
> fs/btrfs/disk-io.c:2311
>
> when testing the 2.6.37-rc5 kernel today.
It's good to mention which line this is, since the line numbers are
always changing. This is:
if (total_errors > max_errors) {
printk(KERN_ERR "btr
Hi!
I got a kernel BUG at
fs/btrfs/disk-io.c:2311
when testing the 2.6.37-rc5 kernel today.
The system crashed while doing really nothing for a few minutes.
Greetings, Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.k
This allows us to set a snapshot or a subvolume readonly or writable
on the fly.
Usage:
Set BTRFS_SUBVOL_RDONLY of btrfs_ioctl_vol_arg_v2->flags, and then
call ioctl(BTRFS_IOCTL_SUBVOL_SETFLAGS);
Changelog for v3:
- Change to pass __u64 as ioctl parameter.
Changelog for v2:
- Add _GETFLAGS io
Usage:
Set BTRFS_SUBVOL_RDONLY of btrfs_ioctl_vol_arg_v2->flags, and call
ioctl(BTRFS_I0CTL_SNAP_CREATE_V2).
Implementation:
- Set readonly bit of btrfs_root_item->flags.
- Add readonly checks in btrfs_permission (inode_permission),
btrfs_setattr, btrfs_set/remove_xattr and some ioctls.
Changel
Split it into two functions for two different ioctls, since they
share no common code.
Signed-off-by: Li Zefan
---
fs/btrfs/ioctl.c | 84 +
1 files changed, 40 insertions(+), 44 deletions(-)
diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
i
This patchset adds readonly-snapshots support. You can create a
readonly snapshot, and you can also set a snapshot (subvolume also)
readonly/writable on the fly.
A few readonly checks are added in setattr, permission, remove_xattr
and set_xattr callbacks, as well as in some ioctls.
The patchset i
13 matches
Mail list logo
