Hi everyone,
I've pulled out some of the btrfs commits from the merge window that
we'd like to see in stable. The full list of sha's from Linus is below,
you can see 4 of them are only needed on 3.17
2fad4e83e12591eb3bd213875b9edc2d18e93383
0b4699dcb65c2cff793210b07f40b98c2d423a43 # v3.17
12b894
Duncan posted on Sun, 19 Oct 2014 05:37:36 + as excerpted:
> Russell Coker posted on Sun, 19 Oct 2014 10:41:41 +1100 as excerpted:
>
>> # find . -name "*546" -exec rm "{}" \;
>> rm: cannot remove `./1412233213.M638209P10546': No such file or
>> directory
>
> Going with the non-printable-char
Hiya Russell,
On Sat, 18 Oct 2014 02:54:19 PM Russell Coker wrote:
> # find . -name "*546"
> ./1412233213.M638209P10546
> # ls -l ./1412233213.M638209P10546
> ls: cannot access ./1412233213.M638209P10546: No such file or directory
Does:
find . -name "*546" -ls
work at all?
--
Chris Samuel
From: Liu Bo
This's been detected by testing generic/323 on btrfs, it keeps producing chaos
of checksum errors.
It is because aio-last-ref-held-by-io uses a static buffer that is been used
repeatedly for every io_submit() call, but we'll issue NUM_IOS(=16) io_sumbit()
in a 'for' loop at a time,
Hi.
Let's say I have a top-level subvolume /sub and that inside /sub I
have another subvolume say /sub/X/Y/subsub.
If I make a snapshot (both ro and rw give the same results) of /sub,
say /sub-snap, right now what I get is this
1) the /sub-snap/X/Y/subsub is present (and empty, and that's OK as
I've seen a hang in renameat2() from time to time on the last few
stable kernels. I can reproduce it easily but only on one specific
multi-terabyte filesystem with millions of files. I've tried to make
a simpler repro setup but so far without success.
Here is what I know so far. First, the stac
On Sat, Oct 11, 2014 at 2:08 PM, Linux Kernel Mailing List
wrote:
> Gitweb:
> http://git.kernel.org/linus/;a=commit;h=f612496bca664bff6a09a99a9a7506410b6e876e
> Commit: f612496bca664bff6a09a99a9a7506410b6e876e
> Btrfs: cleanup the read failure record after write or when the inode is
On Sun, Oct 19, 2014 at 06:01:16AM -0400, Chris Mason wrote:
> Hi everyone,
>
> I've pulled out some of the btrfs commits from the merge window that
> we'd like to see in stable. The full list of sha's from Linus is below,
> you can see 4 of them are only needed on 3.17
>
> 2fad4e83e12591eb3bd21
On Sun, Oct 19, 2014 at 09:55:11PM +0200, Greg KH wrote:
> On Sun, Oct 19, 2014 at 06:01:16AM -0400, Chris Mason wrote:
> > Hi everyone,
> >
> > I've pulled out some of the btrfs commits from the merge window that
> > we'd like to see in stable. The full list of sha's from Linus is below,
> > you
still somethings aren't matching, it could be that
underlying group profile might have changed without
your notice (yes in some circumstance it could).
can you show 'btrfs fi df '
Anand
On 10/19/14 07:12, Vincent. wrote:
i've upgraded to kernel 3.17.0 to update btrfs.ko and it's still no
Zygo Blaxell posted on Sun, 19 Oct 2014 15:25:26 -0400 as excerpted:
> It is the rename (mv) that is getting stuck. It seems to hold a lock
> that prevents any process from later traversing d/e with find or ls, but
> does not prevent a stat on the path 'd/e/f' (which reports that d/e/f is
> now a
Russell Coker posted on Sat, 18 Oct 2014 14:54:19 +1100 as excerpted:
> # find . -name "*546"
> ./1412233213.M638209P10546 # ls -l ./1412233213.M638209P10546 ls: cannot
> access ./1412233213.M638209P10546: No such file or directory
Does your mail server do a lot of renames? Is one perhaps stuck?
12 matches
Mail list logo
