Am 17.09.19 um 18:23 schrieb Linus Torvalds:
> I do agree that a message is a good idea regardless, but I don't think
> it necessarily solves the problems except for developers
sadly in our current world dvelopers and maintainers don't read any logs
and as long it compiles and boots it works an
Am 10.09.19 um 19:33 schrieb Ahmed S. Darwish:
> Yes, doing any of below steps makes the problem reliably disappear:
>
> - boot param "random.trust_cpu=on"
> - rngd(8) enabled at boot (entropy source: x86 RDRAND + jitter)
> - pressing random 3 or 4 keyboard keys while GDM boot is stuck
a
Am 04.09.19 um 14:58 schrieb Theodore Y. Ts'o:
> Again, the likelihood that there will be file systems that have this
> problem in 2038 is... extremely low in my judgement. Storage media
> just doesn't last that long
in times of virtualization storage media are below the vdisk and the
file sys
Am 03.09.19 um 23:17 schrieb Theodore Y. Ts'o:
> I know of a truly vast number of servers in production all over the
> world which are using 128 byte inodes, and spamming the inodes at the
> maximum rate limit is a really bad idea. This includes at some major
> cloud data centers where the life
that's still not in 5.2.8
without the exception and "nf_conntrack_tcp_timeout_max_retrans = 60" a
vnc-over-ssh session having the VNC view in the background freezes
within 60 secods
---
IPV4 TABLE MANGLE (
Am 25.11.2017 um 23:32 schrieb Dave Chinner:
On Fri, Nov 24, 2017 at 03:03:37PM -0700, Andreas Dilger wrote:
Any worse an idea than running a new kernel on an old system?
Newer e2fsck fixes a lot of bugs that are present in older
e2fsck as well...
I'm running with everything up to date (debia
Am 24.07.2017 um 20:57 schrieb Pavel Machek:
Would it be feasible to run bcache (write-through) with existing ext4
filesystem?
I have 400GB of data I'd rather not move, and SSD I could use for
caching. Ok, SSD is connecte over USB2, but I guess it is still way
faster then seeking harddrive on
7 matches
Mail list logo
