On 07/06/2012 03:52 AM, Nick Bowler wrote:
> Hi folks,
>
> I got bored while running the Debian installer (installing to btrfs)
> so I hard-reset the machine during install. The filesystem presumably
> suffered due to the reset, but I'm now getting oopses on attempts to
> mount it again. I get
On Thu, Jul 05, 2012 at 03:41:33PM +0200, Jan Schmidt wrote:
> I'd like to see if you corrupted your trees on disk in a really strange
> manner (with matching checksums?), or if data comes from the disk intact
> and becomes damaged thereafter.
>
> Could you store the output of
> btrfs-debug-
On 07/05/2012 06:51 PM, Alexander Block wrote:
> Hello all,
>
> in IRC we had a discussion on how we could solve sending live
> subvolumes and how to send subvolumes without the need to
> administrate/keep old snapshots for incremental sends. One of the
> ideas was to introduce "sendshots", which
On Thu, Jul 05, 2012 at 02:06:14PM -0600, Hugo Mills wrote:
> On Thu, Jul 05, 2012 at 04:01:22PM -0400, Chris Mason wrote:
> > Hi everyone,
> >
> > I've updated the master branch with the pending stable btrfs-progs
> > commit that should make the 0.20 release.
> >
> > Thanks to Hugh for helping t
On Thu, Jul 05, 2012 at 04:01:22PM -0400, Chris Mason wrote:
> Hi everyone,
>
> I've updated the master branch with the pending stable btrfs-progs
> commit that should make the 0.20 release.
>
> Thanks to Hugh for helping to queue up a few of them. We'll have more
^ that's an o, n
Hi folks,
I got bored while running the Debian installer (installing to btrfs)
so I hard-reset the machine during install. The filesystem presumably
suffered due to the reset, but I'm now getting oopses on attempts to
mount it again. I get dropped back to the shell after the first
attempt, attem
Hi everyone,
I've updated the master branch with the pending stable btrfs-progs
commit that should make the 0.20 release.
Thanks to Hugh for helping to queue up a few of them. We'll have more
frequent releases from here as we pull in the major new features going
into progs (raid5/6, send/receive
Hi Linus
I held off on my rc5 pull because I hit an oops during log recovery
after a crash. I wanted to make sure it wasn't a regression because
we have some logging fixes in here.
It turns out that a commit during the merge window just made it much
more likely to trigger directory logging inste
On Thu, Jul 5, 2012 at 9:24 PM, Ilya Dryomov wrote:
> On Thu, Jul 05, 2012 at 09:18:41PM +0200, Alexander Block wrote:
>> On Thu, Jul 5, 2012 at 9:01 PM, Zach Brown wrote:
>> > On 07/05/2012 11:59 AM, Ilya Dryomov wrote:
>> >
>> >> What if you are on a big-endian machine with a big-endian kernel
On Thu, Jul 05, 2012 at 09:18:41PM +0200, Alexander Block wrote:
> On Thu, Jul 5, 2012 at 9:01 PM, Zach Brown wrote:
> > On 07/05/2012 11:59 AM, Ilya Dryomov wrote:
> >
> >> What if you are on a big-endian machine with a big-endian kernel and
> >> userspace? Everything on-disk should be little-en
On Thu, Jul 5, 2012 at 9:01 PM, Zach Brown wrote:
> On 07/05/2012 11:59 AM, Ilya Dryomov wrote:
>
>> What if you are on a big-endian machine with a big-endian kernel and
>> userspace? Everything on-disk should be little-endian, so if you are
>> going to write stuff you got from userspace to disk,
On 07/05/2012 11:59 AM, Ilya Dryomov wrote:
What if you are on a big-endian machine with a big-endian kernel and
userspace? Everything on-disk should be little-endian, so if you are
going to write stuff you got from userspace to disk, at some point you
have to make sure you are writing out byte
On Thu, Jul 05, 2012 at 11:37:40AM -0700, Zach Brown wrote:
>
> >and take endianess into account with le{64,32}_to_cpu and
> >cpu_to_le{64,32} macros.
>
> The kernel doesn't support system calls from userspace of a different
> endianness, no worries there :)
What if you are on a big-endian machi
and take endianess into account with le{64,32}_to_cpu and
cpu_to_le{64,32} macros.
The kernel doesn't support system calls from userspace of a different
endianness, no worries there :)
- z
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to ma
On Thu, Jul 05, 2012 at 10:20:16AM -0700, Zach Brown wrote:
> On 07/05/2012 10:14 AM, Alexander Block wrote:
> >On Thu, Jul 5, 2012 at 7:08 PM, Zach Brown wrote:
> >>
> >>Careful, timespec will be different sizes in 32bit userspace and a 64bit
> >>kernel. I'd use btrfs_timespec to get a fixed siz
On 07/05/2012 10:14 AM, Alexander Block wrote:
On Thu, Jul 5, 2012 at 7:08 PM, Zach Brown wrote:
Careful, timespec will be different sizes in 32bit userspace and a 64bit
kernel. I'd use btrfs_timespec to get a fixed size timespec and avoid
all the compat_timespec noise. (I'd then also worry
On Thu, Jul 5, 2012 at 7:08 PM, Zach Brown wrote:
>> +static long btrfs_ioctl_set_received_subvol(struct file *file,
>> + void __user *arg)
>> +{
>> + struct btrfs_ioctl_received_subvol_args *sa = NULL;
>
>
>> + ret = copy_to_user(arg, sa, size
+static long btrfs_ioctl_set_received_subvol(struct file *file,
+ void __user *arg)
+{
+ struct btrfs_ioctl_received_subvol_args *sa = NULL;
+ ret = copy_to_user(arg, sa, sizeof(*sa));
+struct btrfs_ioctl_received_subvol_args {
+ ch
Hello all,
in IRC we had a discussion on how we could solve sending live
subvolumes and how to send subvolumes without the need to
administrate/keep old snapshots for incremental sends. One of the
ideas was to introduce "sendshots", which are basically snapshots
where no refs are counted for file
On Thu, Jul 05, 2012 at 09:25:44PM +0800, Liu Bo wrote:
> On 07/04/2012 11:15 PM, Marc MERLIN wrote:
> I'd expect to get some info from the following one, but I fails.
>
> Is it reproducible on your box?
It was reproducible when I reported it, but not anymore now. I couldn't stay
in a state where
On 04.07.2012 22:24, Sami Liedes wrote:
> On Wed, Jul 04, 2012 at 06:38:00PM +0200, Jan Schmidt wrote:
>>> [ 200.980496] btrfs: invalid parameters for read_extent_buffer: start
>>> (32771) > eb->len (32768). eb start is 2243489562624, level 26, generation
>>> 3144240307695375391, nritems 62017
On 07/04/2012 11:41 PM, David Sterba wrote:
> On Fri, Jun 29, 2012 at 06:00:38PM +0800, Liu Bo wrote:
>> We want 'btrfs subvolume list' to act as 'ls', which means that
>> we can not only list out all the subvolumes we have, but also list
>> each single one.
>>
>> So this patch add 's' option to s
On Wed, Jul 04, 2012 at 12:53:54AM -0600, Daniel J Blueman wrote:
> On 4 July 2012 13:19, Liu Bo wrote:
> > On 07/04/2012 11:37 AM, Daniel J Blueman wrote:
> >>> Hi everyone,
> >>>
> >>> I've got a nice set of fixes from Josef, Jan, Ilya and others in my
> >>> for-linus branch:
> >>>
> >>> git://g
Am Mittwoch, 4. Juli 2012 schrieb Bernd Kohler:
> The infos, given by "btrfs fi show /dev/sdb1" and "btrfs fi df /mnt"
> are ok, but df is "lieing":
>
> Filesystem Size Used Avail Use% Mounted on
> /dev/sdc1 8.0G 5.2G 56k 100% /mnt
>
> Don't get confused about used space, tried to write a 4G
Am Mittwoch, 4. Juli 2012 schrieb Bernd Kohler:
> Hi,
Hi Bernd,
> this is not really a bug in btrfs but to spread the info I will just
> drop this short message:
>
> My System (VirtualBox VM, 3 virtual HDDs with 10G, 5G and 3G) is today
> installed Ubuntu 12.04 LTS 64bit with Kernel 3.2.0-26 gen
On 07/04/2012 11:15 PM, Marc MERLIN wrote:
> On Wed, Jul 04, 2012 at 01:58:31PM +0800, Liu Bo wrote:
>> > The dmesg log, sysrq log and stack dump info can usually be very helpful.
>> >
>> > From your report, we can see the csum error and hang on log,
>> > 'no csum' is not that bad while hanging-o
On Thu, Jul 5, 2012 at 3:47 PM, Alexander Block wrote:
> On Thu, Jul 5, 2012 at 2:19 PM, Alex Lyakas
> wrote:
>> Alexander,
>>
> + if (advance_left && !left_end_reached) {
> + ret = tree_advance(left_root, left_path,
> &left_level,
> +
On Thu, Jul 5, 2012 at 2:19 PM, Alex Lyakas
wrote:
> Alexander,
>
+ if (advance_left && !left_end_reached) {
+ ret = tree_advance(left_root, left_path,
&left_level,
+ left_root_level,
+
Alexander,
>>> + if (advance_left && !left_end_reached) {
>>> + ret = tree_advance(left_root, left_path,
>>> &left_level,
>>> + left_root_level,
>>> + advance_left != ADVANCE_ONLY_NEXT,
On Wed, Jul 4, 2012 at 3:38 PM, Alexander Block wrote:
> This patch introduces uuids for subvolumes.
> [...]
Stefan and Jan pointed out a problem with this patch that would result
in read_extent_buffer calls that read beyond the leaf size when an old
root item is found at the end of a leaf. I push
Sorry, please ignore this patch.
On Thu, Jul 5, 2012 at 3:26 PM, wrote:
> From: Zhi Yong Wu
>
> Signed-off-by: Zhi Yong Wu
> ---
> extent-cache.c |4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/extent-cache.c b/extent-cache.c
> index 3dd6434..a5084ee 100644
>
From: Zhi Yong Wu
Signed-off-by: Zhi Yong Wu
---
extent-cache.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/extent-cache.c b/extent-cache.c
index 3dd6434..a5084ee 100644
--- a/extent-cache.c
+++ b/extent-cache.c
@@ -136,10 +136,10 @@ struct cache_extent *find_fir
32 matches
Mail list logo
