Re: assertion failures

2010-02-26 Thread Gustavo Alves
In my case, kernel 2.6.32-0.51.rc7.git2.fc13.i686.PAE and BTRFS under LVM2.


Gustavo Junior Alves
Specchio Soluções em TI


On Fri, Feb 26, 2010 at 1:15 PM, Chris Mason chris.ma...@oracle.com wrote:
 On Fri, Feb 26, 2010 at 11:13:32AM -0500, Chris Mason wrote:
 On Thu, Feb 25, 2010 at 03:28:19PM -0300, Gustavo Alves wrote:
  I've got the same error before in a similar situation (24 partitions,
  only two with problems). Unfortunally I erased all data after this
  error. Strange that all I've done was shutdown and poweron the
  machine.

 Basically it looks like the tree of data checksums isn't right.  Which
 kernels were you running when you had these problems?

 Sorry, I mixed up this corruption with one farther down.  The same
 question stands though, this error generally means that IO either didn't
 happen or happened in the wrong place.

 So, the more details you can give about your config the easier it will
 be to nail it down.

 -chris


--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: assertion failures

2010-02-26 Thread Gustavo Alves
In the tragic day I have done a halt command, but, as usual, never
finished as btrfs freezes before umount. I waited almost 5 minutes and
then pressed the power button.

The struct of the machine was very similar with the machine listed below.

 --- Physical volume ---
  PV Name   /dev/sda
  VG Name   specchio
  PV Size   465.76 GiB / not usable 12.02 MiB
  Allocatable   yes (but full)
  PE Size   128.00 MiB
  Total PE  3726
  Free PE   0
  Allocated PE  3726
  PV UUID   YpNYXY-AI1i-1D8D-9BAa-1DeY-hWNL-ZOtBIh

  --- Physical volume ---
  PV Name   /dev/sdb1
  VG Name   specchio
  PV Size   931.51 GiB / not usable 11.19 MiB
  Allocatable   yes
  PE Size   128.00 MiB
  Total PE  7452
  Free PE   24
  Allocated PE  7428
  PV UUID   G1mWRL-I7zx-bwbi-zYe8-tc2q-DrtD-tH6jIi

  --- Physical volume ---
  PV Name   /dev/sdd
  VG Name   specchio
  PV Size   931.51 GiB / not usable 13.71 MiB
  Allocatable   yes (but full)
  PE Size   128.00 MiB
  Total PE  7452
  Free PE   0
  Allocated PE  7452
  PV UUID   TWCEea-UURq-8HbM-NgkC-2J3Y-1qYE-TN7vud

  --- Physical volume ---
  PV Name   /dev/sdc
  VG Name   specchio
  PV Size   1.36 TiB / not usable 15.40 MiB
  Allocatable   yes
  PE Size   128.00 MiB
  Total PE  11178
  Free PE   11024
  Allocated PE  154
  PV UUID   hUbv4T-2Q0i-plGb-EO6a-2vAo-uHwj-Vda8zz

--- Volume group ---
  VG Name   specchio
  System ID
  Formatlvm2
  Metadata Areas4
  Metadata Sequence No  37
  VG Access read/write
  VG Status resizable
  MAX LV0
  Cur LV15
  Open LV   15
  Max PV0
  Cur PV4
  Act PV4
  VG Size   3.64 TiB
  PE Size   128.00 MiB
  Total PE  29808
  Alloc PE / Size   18760 / 2.29 TiB
  Free  PE / Size   11048 / 1.35 TiB
  VG UUID   AKxGo3-MVTJ-7XdC-GeTW-23e8-5Ee2-HY2PZ0


Gustavo Junior Alves

On Fri, Feb 26, 2010 at 6:10 PM, Chris Mason chris.ma...@oracle.com wrote:
 On Fri, Feb 26, 2010 at 04:57:27PM -0300, Gustavo Alves wrote:
 In my case, kernel 2.6.32-0.51.rc7.git2.fc13.i686.PAE and BTRFS under LVM2.


 Did you also have power-off based reboots?  Depending on the
 configuration LVM (anything other than a single drive) won't send barriers to
 the device.

 -chris

 
 Gustavo Junior Alves
 Specchio Soluções em TI


 On Fri, Feb 26, 2010 at 1:15 PM, Chris Mason chris.ma...@oracle.com wrote:
  On Fri, Feb 26, 2010 at 11:13:32AM -0500, Chris Mason wrote:
  On Thu, Feb 25, 2010 at 03:28:19PM -0300, Gustavo Alves wrote:
   I've got the same error before in a similar situation (24 partitions,
   only two with problems). Unfortunally I erased all data after this
   error. Strange that all I've done was shutdown and poweron the
   machine.
 
  Basically it looks like the tree of data checksums isn't right.  Which
  kernels were you running when you had these problems?
 
  Sorry, I mixed up this corruption with one farther down.  The same
  question stands though, this error generally means that IO either didn't
  happen or happened in the wrong place.
 
  So, the more details you can give about your config the easier it will
  be to nail it down.
 
  -chris
 
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-btrfs in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Problem with renaming devices

2009-11-07 Thread Gustavo Alves
Hi Chris,

I found the same problem on 2.6.32-0.33.rc5.git1 with btrfs-progs
0.19. This problem is already fixed?

Thanks


Gustavo Junior Alves
Specchio Soluções em TI
http://specchio.inf.br
Tel: +55 19 9223-0500


 From: Chris Mason chris.mason_ät_oracle.com
 Date: Tue, 07 Apr 2009 07:35:56 -0400

 On Mon, 2009-04-06 at 18:41 +0100, Hugo Mills wrote:
  There seems to be some issue over changing the names of the device
  that a btrfs filesystem lives on:
 
  # lvcreate scratch -n fstest -L 2G
  Logical volume fstest created
  # mkfs -t btrfs /dev/scratch/fstest
 
  WARNING! - Btrfs v0.18-ge3b0f66 IS EXPERIMENTAL
  WARNING! - see http://btrfs.wiki.kernel.org before using
 
  fs created label (null) on /dev/scratch/fs1
  nodesize 4096 leafsize 4096 sectorsize 4096 size 2.00GB
  Btrfs v0.18-ge3b0f66
 
  # mount /dev/scratch/fstest /mnt
  # umount /mnt
 
  # lvrename scratch fstest derek
  Renamed fstest to derek in volume group scratch
  # mount /dev/scratch/derek /mnt
  mount: /dev/mapper/scratch-derek: can't read superblock
 
  # lvrename scratch derek fstest
  Renamed derek to fstest in volume group scratch
  # mount /dev/scratch/fstest /mnt
  [success]
 
  The rename works properly on a completely virgin filesystem, but
  not on one that's been mounted and unmounted (as above).

 Whoops, we need to reset the pathname when a probe finds a given dev
 uuid on a given device. I'll patch it up when I get back next week.

 Thanks for this bug report.

 -chris
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html