On Mon, 26 Feb 2024, Andy Smith wrote:
Hi,
On Mon, Feb 26, 2024 at 06:25:53PM +, Tim Woodall wrote:
Feb 17 17:01:49 xen17 vmunix: [3.802581] ata1.00: disabling queued TRIM
support
Feb 17 17:01:49 xen17 vmunix: [3.805074] ata1.00: disabling queued TRIM
support
from libata-core.c
Hi,
On Mon, Feb 26, 2024 at 06:25:53PM +, Tim Woodall wrote:
> Feb 17 17:01:49 xen17 vmunix: [3.802581] ata1.00: disabling queued TRIM
> support
> Feb 17 17:01:49 xen17 vmunix: [3.805074] ata1.00: disabling queued TRIM
> support
>
>
> from libata-core.c
>
> { "Samsung SSD 870*",
>>> You should not be running trim in a container/virtual machine
>> Why not? That's, in my case, basically saying "you should not be running
>> trim on a drive exported via iscsi" Perhaps I shouldn't be but I'd like
>> to understand why. Enabling thin_provisioning and fstrim works and gets
>> mapp
On 2/26/24 16:31, Tim Woodall wrote:
On Mon, 26 Feb 2024, Gremlin wrote:
re running fstrim in a vm.
The Host system takes care of it
I guess you've no idea what iscsi is. Because this makes no sense at
all. systemd or no systemd. The physical disk doesn't have to be
something the host system
On Mon, 26 Feb 2024, Gremlin wrote:
re running fstrim in a vm.
The Host system takes care of it
I guess you've no idea what iscsi is. Because this makes no sense at
all. systemd or no systemd. The physical disk doesn't have to be
something the host system knows anything about.
Here's a threa
On 2/26/24 14:40, Tim Woodall wrote:
On Mon, 26 Feb 2024, Gremlin wrote:
Are you using systemd ?
No, I'm not
You should not be running trim in a container/virtual machine
Why not? That's, in my case, basically saying "you should not be running
trim on a drive exported via iscsi" Perhaps I
On Mon, 26 Feb 2024, Gremlin wrote:
Are you using systemd ?
No, I'm not
You should not be running trim in a container/virtual machine
Why not? That's, in my case, basically saying "you should not be running
trim on a drive exported via iscsi" Perhaps I shouldn't be but I'd like
to understan
On 2/26/24 13:25, Tim Woodall wrote:
TLDR; there was a firmware bug in a disk in the raid array resulting in
data corruption. A subsequent kernel workaround resulted in
dramatically reducing the disk performance. (probably just writes but I
didn't confirm)
Initially, under heavy disk load I got
TLDR; there was a firmware bug in a disk in the raid array resulting in
data corruption. A subsequent kernel workaround resulted in
dramatically reducing the disk performance. (probably just writes but I
didn't confirm)
Initially, under heavy disk load I got errors like:
Preparing to unpack ..
9 matches
Mail list logo
