From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-0.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU autolearn=ham autolearn_force=no version=3.4.4
Received: (qmail 17378 invoked from network); 22 Oct 2022 16:21:55 -0000
Received: from 9front.inri.net (168.235.81.73)
  by inbox.vuxu.org with ESMTPUTF8; 22 Oct 2022 16:21:55 -0000
Received: from cc-smtpout1.netcologne.de ([89.1.8.211]) by 9front; Sat Oct 22 12:20:15 -0400 2022
Received: from cc-app1.netcologne.de (cc-app1.netcologne.de [89.1.9.190])
	by cc-smtpout1.netcologne.de (Postfix) with ESMTP id D0151127C2
	for <9front@9front.org>; Sat, 22 Oct 2022 18:20:12 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=netcologne.de;
	s=nc1116a; t=1666455612;
	bh=N/QHbCMulDgENn7L9fcFLRYweheIOzdknD5llPfDYcI=;
	h=Date:From:To:Message-ID:In-Reply-To:References:Subject:From;
	b=NyoJ5tevMjte4yb/wdvq3od8xvKT/LQ9cyoRzQsUsw6LayiGGjFU3suQ+sRtA2Iiu
	 XP5hLxitj9GGKJFmuWrQlda6YijQx3SwJugYr/3QkqCI7+88g9vmrSb8FeY5JMA31p
	 ZuuMxQi05NbvkbViirIKE20NgiNqYW/hjRye8sB7Gj8IDLHCr7TXLhzpJiqQi1Zwbx
	 vvZ5nghdFwaDg/yKSNB81vdLsZn4XGrX12yhIh4JgOLuWGUH98JNEEHLisLkY8Fepd
	 /6XBZij3sZXmoQJvphZGUk+pGHGDQ1RHy0ShUcRmqsTwAEuk2Z6VZPNuxUZBBk/JBp
	 5ySjIzBOf7DUw==
Received: from cc-app1.netcologne.de (localhost [127.0.0.1])
	by cc-app1.netcologne.de (Postfix) with ESMTPA id 133C012A28
	for <9front@9front.org>; Sat, 22 Oct 2022 18:20:12 +0200 (CEST)
Date: Sat, 22 Oct 2022 18:20:12 +0200 (CEST)
From: Arne Meyer <meyer.arne83@netcologne.de>
To: 9front@9front.org
Message-ID: <76056358.4053648.1666455612029@comcenter.netcologne.de>
In-Reply-To: <A1DBB7B503ADD7D8261D0224D8B23553@eigenstate.org>
References: <1993373294.3416290.1664736998610@comcenter.netcologne.de>
 <A1DBB7B503ADD7D8261D0224D8B23553@eigenstate.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.6-Rev16
X-Originating-IP: 2001:4dd1:eccc:0:bccc:ab26:f6d:41ad
X-Originating-Client: open-xchange-appsuite
X-NetCologne-Spam: L
X-Rspamd-Queue-Id: 133C012A28
X-Spamd-Bar: ---
List-ID: <9front.9front.org>
List-Help: <http://lists.9front.org>
X-Glyph: ➈
X-Bullshit: NoSQL template cloud realtime-java high-performance-based interface 
Subject: Re: [9front] [patch] cdfs handle block sizes correctly
Reply-To: 9front@9front.org
Precedence: bulk

ping?

> ori@eigenstate.org hat am 02.10.2022 20:04 GMT geschrieben:
> 
>  
> Quoth Arne Meyer <meyer.arne83@netcologne.de>:
> > The old Readblock value is fine for data tracks, because 4 2048 byte blocks fit in the 8192 byte RPCMAX. But cdda blocks are 2352 bytes and 4 of those don't fit into 8192 bytes and stuff breaks. If I read the code correctly my change should set the number of blocks to 4 for data tracks and to 3 for everything else.
> 
> Ah, I misunderstood you -- I thought you were saying you had disks
> where the blocksize was larger than RPCMAX (8k).
> 
> I'll take another look.