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 ..
On 1/21/24 02:45, Tim Woodall wrote:
On Sat, 20 Jan 2024, David Christensen wrote:
On 1/20/24 08:25, Tim Woodall wrote:
Some time ago I wrote about a data corruption issue. I've still not
managed to track it down ...
Please post a console session that demonstrates, or at least
documents, the
On 1/21/24 05:46, Tim Woodall wrote:
The disk that I'm using when I saw the above error is a straight LVM ->
iscsi -> ext3 mounted like this:
/dev/xvdb on /mnt/mirror/ftp/mirror type ext3 (rw,noatime)
I should stay out of this, but feel compelled to ask why ext3?
It had a very short run, a l
On Sat, 20 Jan 2024, David Christensen wrote:
On 1/20/24 08:25, Tim Woodall wrote:
Some time ago I wrote about a data corruption issue. I've still not
managed to track it down ...
Please post a console session that demonstrates, or at least documents, the
data corruption.
Console session
On 1/20/24 08:25, Tim Woodall wrote:
> Some time ago I wrote about a data corruption issue. I've still not
> managed to track it down ...
Please post a console session that demonstrates, or at least documents,
the data corruption.
Please cut and paste complete console sessions into your posts
13 matches
Mail list logo
