Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp3673982pxu; Sun, 11 Oct 2020 19:48:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzyrjXGjkTmxr7KJqDonbD6d1j+voektPy4DwU6+i21fAUPb8w+hLjmv3Cd4eLWSFTXpjuM X-Received: by 2002:a05:6402:142c:: with SMTP id c12mr12244310edx.41.1602470936687; Sun, 11 Oct 2020 19:48:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1602470936; cv=none; d=google.com; s=arc-20160816; b=Cfoe4ioXS5EVUR8oeycBcwfXyP9qxxRxTRmguWOEQ+L9r+mifCvPPsgOFj9pROsnXv yPzxhvLZQJIu5leN5b5s1TDkrOTnVrOqSxE02ND+gh0UXOBQ/rueF3KjXjYv3ALiQhWX VvxXxMUvrLl50zkXjFaxryb2mtGKX1IQ0GYBsJZDBgTh8P16ut31xh6e/jXL3U+rzM56 jRKuncbbAm6n47Yiev1DhNYZ4YexPrvEs9ATXfjlaOkISFeUWqBrKFzySzrjeRH1D+Y/ zeyRGJrc+Bw+YVK8nNM0OBeaz/ABoxvVRacjeB3cY3IZfz5iMdm29O4p0tkFLyVkGEq4 TAQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :to:subject:reply-to; bh=bKo/4KLFVIFcCSG2DCs48i2Krt0OGz1eKWyLPIhlf2g=; b=SxflQ4jxNeBCCjZdotvudgNcFCORyKcxHoXTA1EPI3TyFWY++sFCmAFharCz0k0Vea nxesnPJ90sgiFD1ogrZ+qmkMsxl80r5ywe6+KqQfl4VqQoguZVofNDS2mTE6vkUZvia4 5tjZ/3pgKq07omM55NoSxf+bKhsvpock13IAY0fXMsCxdiioM4ciot0GppnzhS7DdQ34 hCtRjaG8/QRRbAmbp/w7RJKZw4xFUcGyKVr2XFNIS/kTruhSeRu5NJLT2y+4gprFvq9F H+sD5/zpRm8ciqJmnlhBeCf0cw8mnG1RtUp1+8bIe5D2Ft8JR2XaYUFsmHLYhApVzycN 1mDQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h17si10745701ejf.88.2020.10.11.19.48.34; Sun, 11 Oct 2020 19:48:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726798AbgJLCGP (ORCPT + 99 others); Sun, 11 Oct 2020 22:06:15 -0400 Received: from mail-1.ca.inter.net ([208.85.220.69]:53837 "EHLO mail-1.ca.inter.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726777AbgJLCGP (ORCPT ); Sun, 11 Oct 2020 22:06:15 -0400 X-Greylist: delayed 548 seconds by postgrey-1.27 at vger.kernel.org; Sun, 11 Oct 2020 22:06:14 EDT Received: from localhost (offload-3.ca.inter.net [208.85.220.70]) by mail-1.ca.inter.net (Postfix) with ESMTP id 8FD462EA08E; Sun, 11 Oct 2020 21:57:05 -0400 (EDT) Received: from mail-1.ca.inter.net ([208.85.220.69]) by localhost (offload-3.ca.inter.net [208.85.220.70]) (amavisd-new, port 10024) with ESMTP id kDROQ88fsnuA; Sun, 11 Oct 2020 21:50:07 -0400 (EDT) Received: from [192.168.48.23] (host-104-157-204-209.dyn.295.ca [104.157.204.209]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: dgilbert@interlog.com) by mail-1.ca.inter.net (Postfix) with ESMTPSA id 39D512EA02E; Sun, 11 Oct 2020 21:57:05 -0400 (EDT) Reply-To: dgilbert@interlog.com Subject: Re: [question] What happens when dd writes data to a missing device? To: Mikhail Gavrilov , Linux List Kernel Mailing References: From: Douglas Gilbert Message-ID: Date: Sun, 11 Oct 2020 21:57:04 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-CA Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2020-10-11 3:46 p.m., Mikhail Gavrilov wrote: > Hi folks! > I have a question. > What happens when dd writes data to a missing device? > > For example: > # dd if=/home/mikhail/Downloads/Fedora-Workstation-Live-x86_64-Rawhide-20201010.n.0.iso > of=/dev/adb > > Today I and wrongly entered /dev/adb instead of /dev/sdb, > and what my surprise was when the data began to be written to the > /dev/adb device without errors. > > But my surprise was even greater when cat /dev/adb started to display > the written data. > > I have a question: > Where the data was written and could it damage the stored data in > memory or on disk? Others have answered your direct question. You may find 'oflag=nocreat' helpful if you (or others) do _not_ want a regular file created in /dev ; for example: if you have misspelt a device name. That flag may also be helpful in unstable systems (e.g. where device nodes are disappearing and re-appearing) as it can be a real pain if you manage to create a regular file with a name like /dev/sdc when the disk usually occupying that node is temporarily offline. When that disk comes back online then regular file '/dev/sdc' will stop device node '/dev/sdc' from being created. The solution is to remove the regular file /dev/sdc and you probably need to power cycle that disk. If this becomes a regular event then 'oflag=nocreat' is your friend [see 'man dd' for a little more information, it really should be expanded]. Doug Gilbert