Hello Guy,
Am Donnerstag, 4. September 2014, 11:00:55 schrieb Gui Hecheng:
On Mon, 2014-09-01 at 15:25 +, Zooko Wilcox-OHearn wrote:
I'm more than happy to try out patches and even focus my own brain on
diagnosing it, if I can. I'm hoping to regain access to some of my
files on my
On Mon, Aug 18, 2014 at 04:38:18PM +0800, Anand Jain wrote:
ioctl BTRFS_IOC_FS_INFO return num_devices which does _not_ include seed
device, But the following ioctl BTRFS_IOC_DEV_INFO counts and gets seed
disk when probed. So in the userland we hit a count-slot missmatch
bug..
The inherit in btrfs_ioctl_snap_create_v2() and vol_args in
btrfs_ioctl_rm_dev() are ERR_PTRs so we can't call kfree() on them.
These kind of bugs are One Err Bugs where there is just one error
label that does everything. I could set the inherit = NULL and keep
the single out label but it ends
+ static __thread char _str[24];
This patch is causing segmentation fault as it reached maximum stack
depth on the sparc machine. Just earlier method of malloc is better ?
unless we want to change the stack depth. Any comments ?
Thanks, Anand
On 07/10/2013 10:30 PM, David
On 09/04/2014 05:58 PM, David Sterba wrote:
On Mon, Aug 18, 2014 at 04:38:18PM +0800, Anand Jain wrote:
ioctl BTRFS_IOC_FS_INFO return num_devices which does _not_ include seed
device, But the following ioctl BTRFS_IOC_DEV_INFO counts and gets seed
disk when probed. So in the userland we hit
Am 04.09.2014 13:09, schrieb Dan Carpenter:
The inherit in btrfs_ioctl_snap_create_v2() and vol_args in
btrfs_ioctl_rm_dev() are ERR_PTRs so we can't call kfree() on them.
These kind of bugs are One Err Bugs where there is just one error
label that does everything. I could set the inherit
On Thu, Sep 04, 2014 at 02:11:00PM +0200, walter harms wrote:
ret = btrfs_ioctl_snap_create_transid(file, vol_args-name,
vol_args-fd, subvol, ptr,
readonly, inherit);
+ if (ret)
+ goto
On 09/04/2014 07:09 AM, Dan Carpenter wrote:
The inherit in btrfs_ioctl_snap_create_v2() and vol_args in
btrfs_ioctl_rm_dev() are ERR_PTRs so we can't call kfree() on them.
These kind of bugs are One Err Bugs where there is just one error
label that does everything. I could set the
Some more details about this problem:
-the directory involved is /lib/modules/3.17.0-rc3-cu3/kernel/drivers/iio/gyro
-in that dir there should be kernel object named hid-sensor-gyro-3d.ko
but there's
no trace of it
-that dir cannot be removed or overwritten. rm -rf fails saying that
the dir
On Wed, Sep 03, 2014 at 02:32:09PM -0700, Greg KH wrote:
6f7ff6d7832c6be13e8c95598884dbc40ad69fb7
This doesn't apply to 3.10-stable :(
ce62003f690dff38d3164a632ec69efa15c32cbf
Neither did this.
I'm sorry for the trouble. I tried to verify that the patches apply but
must
(removed stable@ for now)
Just to follow up on this -
On Wed, 03 Sep 2014 23:36:00 +, Holger Hoffstätte wrote:
[on backporting both:
8d875f95da43c6a8f18f77869f2ef26e9594fecc and
f6dc45c7a93a011dff6eb9b2ffda59c390c7705a to 3.14]
...and I guess nobody will complain about slightly
On Thu, Sep 04, 2014 at 07:43:08PM +0800, Anand Jain wrote:
+ static __thread char _str[24];
This patch is causing segmentation fault as it reached maximum stack
depth on the sparc machine.
Sigh. I guess it was inevitable that this would fail somewhere :).
Just earlier
On Thu, Sep 04, 2014 at 06:37:58PM +0200, David Sterba wrote:
On Wed, Sep 03, 2014 at 02:32:09PM -0700, Greg KH wrote:
6f7ff6d7832c6be13e8c95598884dbc40ad69fb7
This doesn't apply to 3.10-stable :(
ce62003f690dff38d3164a632ec69efa15c32cbf
Neither did this.
I'm sorry
john terragon posted on Thu, 04 Sep 2014 07:30:37 +0200 as excerpted:
dm-0 is the first dmcrypt device of a pair on which I have
btrfs in RAID0 (btrfs native raid).
I assume that a scrub would not do any good since it seems to be
related to btrfs data structures more than actual file
john terragon posted on Thu, 04 Sep 2014 15:03:04 +0200 as excerpted:
Some more details about this problem:
-the directory involved is
/lib/modules/3.17.0-rc3-cu3/kernel/drivers/iio/gyro -in that dir there
should be kernel object named hid-sensor-gyro-3d.ko but there's
no trace of it
Everyone knows what raid0 entails. Moreover, with btrfs being an
experimental fs, not having backups would obviously be pure idiocy.
I wrote that it was pretty serious because the situation came out of
nowhere on a low-traffic fs on which the most exiciting thing that can
happen is an occasional
On Sep 4, 2014, at 6:20 PM, john terragon jterra...@gmail.com wrote:
Everyone knows what raid0 entails. Moreover, with btrfs being an
experimental fs, not having backups would obviously be pure idiocy.
That is a bit of hyperbole. There is such a thing as innocently ignorant, as
well as the
john terragon posted on Fri, 05 Sep 2014 02:20:26 +0200 as excerpted:
Everyone knows what raid0 entails. Moreover, with btrfs being an
experimental fs, not having backups would obviously be pure idiocy.
I wrote that it was pretty serious because the situation came out of
nowhere on a
Chris Murphy posted on Thu, 04 Sep 2014 19:41:39 -0600 as excerpted:
Off chance scrub might fix the problem
How? He said it's btrfs raid0. There's no second copy to fix from.
(Of course if only the data is raid0, metadata being raid1, then if it's
metadata yes a scrub could fix it, but
On Sep 4, 2014, at 8:07 PM, Duncan 1i5t5.dun...@cox.net wrote:
Chris Murphy posted on Thu, 04 Sep 2014 19:41:39 -0600 as excerpted:
Off chance scrub might fix the problem
How? He said it's btrfs raid0. There's no second copy to fix from.
(Of course if only the data is raid0, metadata
20 matches
Mail list logo
