Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754150AbdC1Blp (ORCPT ); Mon, 27 Mar 2017 21:41:45 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:37822 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753703AbdC1Blm (ORCPT ); Mon, 27 Mar 2017 21:41:42 -0400 To: Dmitry Monakhov Cc: LKML , dgilbert@interlog.com, martin.petersen@oracle.com Subject: Re: scsi_debug: shared dev context, BUG or FEATURE? From: "Martin K. Petersen" Organization: Oracle Corporation References: <87tw6e4o75.fsf@dmlp.sw.ru> Date: Mon, 27 Mar 2017 21:41:17 -0400 In-Reply-To: <87tw6e4o75.fsf@dmlp.sw.ru> (Dmitry Monakhov's message of "Mon, 27 Mar 2017 20:35:58 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Source-IP: aserv0022.oracle.com [141.146.126.234] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1495 Lines: 37 Dmitry Monakhov writes: Dmitry, > scsi_debug has very strange structure from one point it supports > dynamic number of devices but from other point context is common for > all devices: > So basically we may have many devices with single context which refers > common data. Are any sane reason to share context between devices? > Who use such behaviour? As the name implies, scsi_debug was conceived to debug the SCSI layer. Among other things, the intent was to be able to test hundreds of controllers and LUNs without having physical hardware or storage to back that up. Plus to have a target whose reporting could easily be tweaked to test the SCSI core code. So that's the reason for the oddball shared buffer setup. scsi_debug wasn't really meant to be a "useful" storage target. If you want something with a per-device backing store I suggest you look at the SCSI target subsystem. With tcm_loop and ramdisk you get essentially the same thing as scsi_debug. With the added bonus that you can use files or block devices if you actually want the data to be persistent. > IMHO this is a pure bug. Please correct me if I'm wrong, I'll plan to > fix that by allocation separate context for each dev. I don't have a problem with allowing it as an option as long as the original behavior can be preserved. But again, I think target mode is a better bet if you actually care about what's being stored on the "media". -- Martin K. Petersen Oracle Linux Engineering