search for: backrefer

On Fri, Aug 28, 2020 at 11:16 AM David Blaikie <dblaikie at gmail.com> wrote: > > Would you like to conduct the conversation here, or on the review thread? (I lean towards having them here, but don't mind if folks feel like it keeps the noise down & want to more post a notice saying "hey, here's this thing, if you're interested, go discuss it over there" -

On Mon, Aug 31, 2020 at 1:29 PM David Blaikie <dblaikie at gmail.com> wrote: > > > > On Mon, Aug 31, 2020 at 1:24 PM Fāng-ruì Sòng <maskray at google.com> wrote: >> >> On Fri, Aug 28, 2020 at 11:16 AM David Blaikie <dblaikie at gmail.com> wrote: >> > >> > Would you like to conduct the conversation here, or on the review thread? (I lean

Hi all, LLD's --warn-backrefs is a tool to identify potential incompatible archive selection semantics with traditional Unix linkers. I have improved it (via D77522,D77630 and D77512) to a state where a --warn-backrefs diagnostic almost assuredly means that the link will fail with GNU ld, or the symbol will get different resolution in GNU ld and LLD. My conclusion is that --warn-backrefs is a

We''re going to use this flag EXTENT_DEFRAG to indicate which range belongs to defragment so that we can implement snapshow-aware defrag: We set the EXTENT_DEFRAG flag when dirtying the extents that need defragmented, so later on writeback thread can differentiate between normal writeback and writeback started by defragmentation. This patch is used for the latter one. Originally patch

On 2020-09-01, Petr Hosek wrote: >I see the GNU ld behavior as a limitation, not as a feature, as Peter Smith >also pointed out in https://reviews.llvm.org/D86762. While it can be argued >that there are certain cases where it can help detect layering >violations as you mentioned in your change, I'm not sure how valuable that >is in practice. Every case I've encountered so

A user reported that fsck was complaining about unresolved refs for some snapshots. You can reproduce this by doing mkfs.btrfs /dev/sdb mount /dev/sdb /mnt btrfs subvol snap /mnt/ /mnt/a btrfs subvol snap /mnt/ /mnt/b btrfs subvol del /mnt/a umount /mnt btrfsck /dev/sdb and you''d get this unresolved ref root 258 dir 256 index 2 namelen 1 name a error 600 because snapshot b has a dir

Parents must be same after going through ref_for_same_block. Signed-off-by: Liu Bo <bo.li.liu@oracle.com> --- fs/btrfs/backref.c | 6 ------ 1 files changed, 0 insertions(+), 6 deletions(-) diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c index f318793..9aaa38e6 100644 --- a/fs/btrfs/backref.c +++ b/fs/btrfs/backref.c @@ -469,11 +469,6 @@ static int __merge_refs(struct list_head

On 2020-09-03, Peter Collingbourne wrote: >On Tue, Sep 1, 2020 at 5:35 PM Fāng-ruì Sòng via llvm-dev < >llvm-dev at lists.llvm.org> wrote: > >> On 2020-09-01, Petr Hosek wrote: >> >I see the GNU ld behavior as a limitation, not as a feature, as Peter >> Smith >> >also pointed out in https://reviews.llvm.org/D86762. While it can be >> argued

On 2020-09-03, Peter Collingbourne wrote: >On Thu, Sep 3, 2020 at 2:00 PM Fāng-ruì Sòng <maskray at google.com> wrote: > >> On 2020-09-03, Peter Collingbourne wrote: >> >On Tue, Sep 1, 2020 at 5:35 PM Fāng-ruì Sòng via llvm-dev < >> >llvm-dev at lists.llvm.org> wrote: >> > >> >> On 2020-09-01, Petr Hosek wrote: >> >> >I

On Thu, Sep 3, 2020 at 5:15 PM Nico Weber <thakis at chromium.org> wrote: > I wanted to chime in and say that I think we should keep the current > default too, for three reasons: > > 1. The current default is more user friendly. Users shouldn't have to > worry about if they pass -lpthread before or after their .o files (...or > other libraries. I know I know for

It looks like the conversation has died, but I just wanted to post my own investigation based on our internal code base. The code base itself is quite a sprawling mass, involving multiple different build systems, some bits CMake based, some hand-curated and so on, and I don't fully comprehend it all. I do know that trying to change it is hard at best, and more likely impossible to do so

[11558.527680] ------------[ cut here ]------------ [11558.527708] kernel BUG at fs/btrfs/transaction.c:1337! [11558.527730] invalid opcode: 0000 [#1] PREEMPT SMP [11558.527764] CPU 1 [11558.527776] Modules linked in: loop nls_cp437 vfat fat dm_mod xfs exportfs jfs usb_storage uas fuse ext4 jbd2 mbcache snd_hda_codec_hdmi snd_hda_codec_realtek arc4 iwlwifi snd_hda_intel snd_hda_codec uvcvideo

...I already have it in my branches and can provide a full implementation with tests (FileCheck now has a test/ dir all of its own since r168113) if the proposal is accepted. The rough outline of the implementation: To enable such matching in a natural way, our regex implementation needs to support backreferences in matches. This then allows to find all references to a variable defined on the same line and substitute them by backrefs. Luckily, our regex implementation already supports backreferences, although a bit of hacking is required to enable it. It supports both Basic Regular Expressions (BREs)...

Hi All, I''m trying to repair a broken fs using btrfsck and am hitting a failed assertion. I''d appreciate any suggestions for what to do next. Is there any thing I can do to help fix this bug? Any other information from my FS which would help? If the FS could be salvaged that would be a bonus, but I''m more interested in providing a useful bug report before wiping the

I''ve upgraded to linux 3.10 and enabled extended inode refs and skinny metadata extent refs with these commands: btrfstune -r /dev/sdc1 btrfstune -x /dev/sdc1 Since then, I have "WARNING: at fs/btrfs/backref.c:903 find_parent_nodes+0x616/0x815 [btrfs]()" showing up like crazy: # grep -c "WARNING: at fs/btrfs/backref.c:903" syslog 181819 That''s after just

Signed-off-by: Anand Jain <anand.jain@oracle.com> --- mkfs.c | 3 +-- 1 files changed, 1 insertions(+), 2 deletions(-) diff --git a/mkfs.c b/mkfs.c index de1beed..0843600 100644 --- a/mkfs.c +++ b/mkfs.c @@ -1196,8 +1196,7 @@ static void process_fs_features(u64 flags) for (i = 0; i < ARRAY_SIZE(mkfs_features); i++) { if (flags & mkfs_features[i].flag) { - fprintf(stderr,

Hi! I used to have arch linux running on 1 btrfs partition (sda1, incl. /boot). When switching to 3.2.5 recently the system fails to boot: (after udevd) /etc/rc.sysinit: line 15: 117 Bus error mountpoint -q /proc and so on, no idea. It used to boot with 3.2.4, but 1) I obviously had some corruption in the tree, when I tried to delete a certain file I hit e.g. "kernel BUG at

I have a string such as fileName<-"Agg.20.20.20-all-01". All I want to do is pull the "20.20.20" and the "all" as strings. Obviously, they aren't always those values. The "20.20.20" can be "30.30.30" but it's always after the . which is next to the second g in Agg and it's always the same length. The all might not always be

Version 0.3-7 of the gsubfn package is available on CRAN. Changes to the package are: - all known bugs have been fixed. - in gsubfn and strapply the replacement object can be a list (or a function, formula, character string or proto object, as before). In the case of a list, regexp matches are looked up in the list names and the corresponding list component used. # Example 1 - at

Version 0.3-7 of the gsubfn package is available on CRAN. Changes to the package are: - all known bugs have been fixed. - in gsubfn and strapply the replacement object can be a list (or a function, formula, character string or proto object, as before). In the case of a list, regexp matches are looked up in the list names and the corresponding list component used. # Example 1 - at