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
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
>>
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
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
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
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
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,
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
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
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
This is rather long - so if you're replying to just one bit, please
consider trimming the parts that you're not responding to to make
everybody's life a little bit better!
Some time ago I wrote about a data corruption issue. I've still not
managed to track it down but I have two new datapoints
14 matches
Mail list logo
