Re: Btrfs-progs release 3.17

[Gui Hecheng <guihc.fnst@cn.fujitsu.com>]

On Tue, 2014-10-28 at 16:42 +0800, Anand Jain wrote:
> 
> 
> On 28/10/2014 12:03, Gui Hecheng wrote:
> > On Thu, 2014-10-23 at 21:36 +0800, Anand Jain wrote:
> >>
> >>    there is no point in re-creating so many btrfs kernel's logic in user
> >>    space. its just unnecessary, when kernel is already doing it. use
> >>    some interface to get info from kernel after device is registered,
> >>    (not necessarily mounted). so progs can be as sleek as possible.
> >>    to me it started as just one more bug now we have fixed so many many.
> >>    It all needs one good interface for kernel which provides anything
> >>    anything from the kernel.
> >>
> >
> > Oh, the interface for kernel you described is really interesting.
> > But how to store the seed/sprout relationships so that we can fetch them
> > correctly for umounted btrfs?
> 
>   remember -  btrfs-control ioctl READY does not work yet when seed is
>   present. Some how we need to fix that in kernel right. ? for which
>   we need the seed/sprout relation when devices are unmounted. you may
>   get that working/accepted in the kernel first, a simple user space
>   interface (such as nacked /proc/fs/btrfs/devlist interface or
>   discussing sysfs interface (bit risky though)) is all that is needed
>   to get this working.
> 

   As far as I could understand, so we have to make the ioctl READY to
do the seed/sprout detecting relation detecting first.
   And then, all the user space tool has to do is fetching stuff through
a new user interface.

   I think this is really a neat way. So is it on your schedule to make
the ioctl READY 'ready'? If not, I am always ready to serve.

   Since there may be more discussions and comments on the above work,
for now, I just plan to make the current way in 3.17 not so 'slow' and
'noisy'.

Thanks,
Gui

> 
> > -Gui
> >
> >>
> >> On 10/23/14 16:52, Gui Hecheng wrote:
> >>> On Thu, 2014-10-23 at 16:13 +0800, Anand Jain wrote:
> >>>>
> >>>> Some of the disks on my system were missing and I was able to hit
> >>>> this issue.
> >>>>
> >>>>
> >>>> ----------------
> >>>> Check tree block failed, want=12582912, have=0
> >>>> read block failed check_tree_block
> >>>> Couldn't read chunk root
> >>>> warning devid 2 not found already
> >>>> Check tree block failed, want=143360, have=0
> >>>> read block failed check_tree_block
> >>>> Couldn't read chunk root
> >>>> warning, device 4 is missing
> >>>> warning, device 3 is missing
> >>>> warning, device 2 is missing
> >>>> warning, device 1 is missing
> >>>> ----------------
> >>>>
> >>>>
> >>>> Did a bisect and it leads to this following patch.
> >>>>
> >>>> ----------------
> >>>> commit 915902c5002485fb13d27c4b699a73fb66cc0f09
> >>>>
> >>>>        btrfs-progs: fix device missing of btrfs fi show with seed devices
> >>>> ----------------
> >>>>
> >>>>     Also this patch stalls ~2sec in the cmd btrfs fi show, on my system
> >>>>     with 48 disks.
> >>>>
> >>>> Also a simple test case hits some warnings...
> >>>>
> >>>> ----------------
> >>>>     mkfs.btrfs -draid1 -mraid1 /dev/sdb /dev/sdc
> >>>>     mount /dev/sdb /btrfs && fillfs /btrfs 100 && umount /btrfs
> >>>>     wipefs -a /dev/sdb
> >>>>     modprobe -r btrfs && modprobe btrfs
> >>>>     mount -o degraded /dev/sdb /btrfs
> >>>>     btrfs fi show
> >>>> Label: none  uuid: 9844cd05-1c8c-473e-a84b-bac95aab7bc9
> >>>>            Total devices 2 FS bytes used 1.59MiB
> >>>>            devid    2 size 967.87MiB used 104.75MiB path /dev/sdc
> >>>>            *** Some devices missing
> >>>>
> >>>> warning, device 1 is missing
> >>>> warning, device 1 is missing
> >>>> warning devid 1 not found already
> >>>> ----------------
> >>>>
> >>>
> >>> Hi Anand and Petr,
> >>>
> >>> Oh, it seems that there are btrfs with missing devs that are bringing
> >>> troubles to the @open_ctree_... function.
> >>> This should be a missing case of the patch above which should only take
> >>> effects when seeding devices are present.
> >>> I will try my best to follow this case, suggestions are welcome, Thanks!
> >>>
> >>> -Gui
> >>>
> >>>>
> >>>>
> >>>>
> >>>> On 10/23/14 14:57, Petr Janecek wrote:
> >>>>> Hello,
> >>>>>
> >>>>>>     You have mentioned two issues when balance and fi show running
> >>>>>>     concurrently
> >>>>>
> >>>>>      my mail was a bit chaotic, but I get the stalls even on idle system.
> >>>>> Today I got
> >>>>>
> >>>>> parent transid verify failed on 1559973888000 wanted 1819 found 1821
> >>>>> parent transid verify failed on 1559973888000 wanted 1819 found 1821
> >>>>> parent transid verify failed on 1559973888000 wanted 1819 found 1821
> >>>>> parent transid verify failed on 1559973888000 wanted 1819 found 1821
> >>>>> Ignoring transid failure
> >>>>> leaf parent key incorrect 1559973888000
> >>>>>
> >>>>> from 'btrfs fi sh' while I was just copying something, no balance running.
> >>>>>
> >>>>> [...]
> >>>>>> [PATCH 1/1] btrfs-progs: code optimize cmd_scan_dev() use
> >>>>>> btrfs_register_one_device()
> >>>>>> [PATCH 1/2] btrfs-progs: introduce btrfs_register_all_device()
> >>>>>> [PATCH 2/2] btrfs-progs: optimize btrfs_scan_lblkid() for multiple calls
> >>>>>>
> >>>>>> If you could, pls..
> >>>>>>     Now on 3.17 apply above 3 patches and see if you see any better
> >>>>>>     performance for the stalling issue.
> >>>>>
> >>>>>      no perceptible change: takes ~40 seconds both before and after
> >>>>> applying. Old version <1 sec.
> >>>>>
> >>>>>>     can you do same steps on 3.16 and report what you observe
> >>>>>
> >>>>>      So many rejects -- do you have older versions of these patches?
> >>>>>
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> Petr
> >>>>> --
> >>>>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> >>>>> the body of a message to majordomo@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 majordomo@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 majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >