Goffredo Baroncelli posted on Wed, 15 Feb 2017 19:25:57 +0100 as
excerpted:
> (Resended because I don saw it in the mailing lists)
>
> -
> Hi,
>
> I want to highlight this bug another time.
>
> I encountered this bug, when I was looking to a problem with find. I my
> machine find took an hu
(Resended because I don saw it in the mailing lists)
-
Hi,
I want to highlight this bug another time.
I encountered this bug, when I was looking to a problem with find. I my machine
find took an huge quantity of memory (up to 3GB) when used by updatedb.
http://lists.gnu.org/archiv
Hi,
I want to highlight this bug another time.
I encountered this bug, when I was looking to a problem with find. I my machine
find took an huge quantity of memory (up to 3GB) when used by updatedb.
http://lists.gnu.org/archive/html/findutils-patches/2016-12/msg0.html
The root of
On 9/16/16 4:28 PM, Tomasz Sterna wrote:
> Hi.
>
> I have spotted an issue with stat(2) call on files on btrfs.
> It is giving me dev_t st_dev number that does not correspond to any
> mounted filesystem in proc's mountinfo.
That's by design. Your particular file system may only use one device
bu
Hi.
I have spotted an issue with stat(2) call on files on btrfs.
It is giving me dev_t st_dev number that does not correspond to any
mounted filesystem in proc's mountinfo.
A quick example:
$ grep btrfs /proc/self/mountinfo
61 0 0:36 /root / rw,relatime shared:1 - btrfs /dev/bcache0
rw,ssd,spa
