From: George Stark <gnstark@salutedevices.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: <linux-kernel@vger.kernel.org>, <kernel@salutedevices.com>
Subject: Re: [PATCH 1/1] initrd: use O_SYNC flag while opening /dev/ram for write
Date: Tue, 9 Jul 2024 19:18:01 +0300 [thread overview]
Message-ID: <94ee7fda-68d8-4720-b95c-10783f2e51a5@salutedevices.com> (raw)
In-Reply-To: <ZozSlCGyKCkj3uUl@infradead.org>
Hello Christoph
Thanks for the review
On 7/9/24 09:03, Christoph Hellwig wrote:
> On Mon, Jul 08, 2024 at 11:09:23PM +0300, George Stark wrote:
>> initrd image is written to the /dev/ram block device using filp_open(),
>> kernel_write()
>
> First question: why are you using the legacy initrd and not initramfs?
I was playing around with initrd to have ability to mount initrd fs from
disk after switching to main root and use files from it. We can't mount
initramfs image. In embedded system mounting vs extracting makes a
difference due to resource limitations. In the end we dropped that idea
partly because of initrd is marked as deprecated.
But since it has been deprecated since 2020 and it's still there I
thought may be it was used by someone so this patch was worth publishing.
If initrd really counts its last days then this patch can be thrown away.
>
>> . After fput() /dev/ram is mounted and may fail due to not
>> all data is actually written to the device yet. The mount error remains
>> hidden due to MS_SILENT flag usage and mount_root_generic has retries.
>> So use O_SYNC flag to have all data written to /dev/ram before mounting.
>
> O_SYNC is highly inefficient. If you have a valid reason to care about
> a corner case in the hopefully soon to be remvoved legacy initrd code,
> the right way to do this is a single fdatasync after the writes have
> finished.
Ok.
--
Best regards
George
prev parent reply other threads:[~2024-07-09 16:18 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-08 20:09 George Stark
2024-07-09 6:03 ` Christoph Hellwig
2024-07-09 16:18 ` George Stark [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=94ee7fda-68d8-4720-b95c-10783f2e51a5@salutedevices.com \
--to=gnstark@salutedevices.com \
--cc=hch@infradead.org \
--cc=kernel@salutedevices.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®