From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id C3269158012 for ; Mon, 12 Sep 2022 17:28:09 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3D930E09B6; Mon, 12 Sep 2022 17:28:06 +0000 (UTC) Received: from mail-pg1-f170.google.com (mail-pg1-f170.google.com [209.85.215.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id F3C21E0930 for ; Mon, 12 Sep 2022 17:28:05 +0000 (UTC) Received: by mail-pg1-f170.google.com with SMTP id c24so8903318pgg.11 for ; Mon, 12 Sep 2022 10:28:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date; bh=nEK0NKPfa8PMnrb2Xh5l6MizSQJeJ6jA89WVmc0Ncqs=; b=J0/Xz8uaIKKO3hg0BtdAsqLZKXnD93xft6hJTEGgTf4wncGhM8xwoh2wBDws8gqUi2 63bhSpDa6G/W4yS+3h9TGUO8QrM8jd6d6ZAS8Fu5ymWIYEjsshqnqVERZeznzub6z/Xj SEebVq3fveEZUkwtlAjIWcD+AR4WGsnNTWXmQnxTU/FxgLQyyt+0snzO1HyQnUspIy5g wxQaWbQZ/qYSVFWvN4r+IOCsgOQNNh3/m1/Ig3195GjQca+zuABJmBNwbzKHtMJ5dGlg ZkcnRhb0SQTy1qibtK0r6ZMSO3SrqzD19p0uFQ1qVGYSX8yp4ztuRPjkT2g7kMSgzQuA B+RA== X-Gm-Message-State: ACgBeo3KiQv+MtCgFBJZVRdygCJfSPiwLyUMyQOC7xr6VmTWcSN+w6hC HPIL1ZllpQRvXJd8lCXw4hSJjCGOU1Vj3Dmj1c8yexn+ X-Google-Smtp-Source: AA6agR7gnK8zpxA8SRhjaAqUIQCSscJ8jM3VP/mM+tvetNzC+FOIP2N6WykSNxFuE4ERY3IbmwNgsrCbrXn5Hrt6vu4= X-Received: by 2002:a63:5916:0:b0:41d:2c8c:7492 with SMTP id n22-20020a635916000000b0041d2c8c7492mr24223557pgb.81.1663003684685; Mon, 12 Sep 2022 10:28:04 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: <1b6f36dd-f378-2d04-3df1-0541b9d944e9@gmail.com> In-Reply-To: <1b6f36dd-f378-2d04-3df1-0541b9d944e9@gmail.com> From: Rich Freeman Date: Mon, 12 Sep 2022 13:27:56 -0400 Message-ID: Subject: Re: [gentoo-user] Encrypted hard drives on LVM and urgent power shutdowns. To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset="UTF-8" X-Archives-Salt: 811f7c25-e7c3-472d-a174-d4e75f9306ae X-Archives-Hash: d9849ffc377143da569cf1a35b343087 On Sun, Sep 11, 2022 at 9:56 PM Dale wrote: > > I suspect this would happen on its own but I'd like to make sure. I'd > hate to mess up the file system badly on any of my drives or in a worst > case scenario, brick a hard drive with some 1 in a million chance problem. > I just wanted to comment that LUKS encryption on linux is pretty-much a block-level passthrough. So if your filesystem is journaled and using barriers or syncing to ensure consistency, and you add LUKS to it, then you shouldn't really see any difference in behavior if it is interrupted uncleanly by a power loss. The encryption could add a bit of latency but that shouldn't change much. Of course different filesystems handle interruptions differently, and all those caveats still apply. As far as unmounting goes, you just need to umount the filesystem. umount will block until all writes are synced to disk, and that includes all layers like LVM/LUKS/mdadm/whatever that might be underneath it. If umount returns, then all your data is written to disk and if at that instant you lose power there will be no data loss for that filesystem. I guess if you're using mdadm and you have multiple filesystems not aligned to a stripe boundary, then the raid write hole might still apply, and that is true at anytime whether the filesystem is mounted or not - data on a stripe shared with some other active filesystem could get lost in some situations. Obviously if you lose the key to a LUKS filesystem or if there is some kind of bug in LUKS the use of encryption could hinder data recovery. Beyond that it really shouldn't have any impact on anything. I guess it would also give you more exposure to RAM errors (since that is another code path that stores stuff in RAM). As already discussed, clean shutdowns triggered by NUT/etc are of course best, but the use of LUKS shouldn't change much with the use of a UPS otherwise. -- Rich