[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: safety of save_env

From: Andrei Borzenkov
Subject: Re: safety of save_env
Date: Wed, 24 Aug 2016 10:17:03 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

24.08.2016 07:15, Michael Zimmermann пишет:
> I mean safe in the sense that it would not destroy data outside of that
> file (no matter if writing was successful or not) or even destroy/add
> errors to  the filesystem.(ext*, f2fs, fat*, ...).

It computes block list of file data and then overwrites these blocks. It
will abort if file is sparse. It actually even double checks block list
by reading directly from disk (bypassing filesystem driver) and
comparing results.

So it looks reasonably safe in that it should not write outside of space
already allocated for file data on disk. It obviously will not work for
filesystem that computes checksums over data like btrfs or zfs; these
filesystems currently ignore read hooks so always return empty block
list (leading to confusing error message).

For journalled filesystems there is non-zero probability that journal
replay will change content of those blocks.

Note that it depends on explicit fs driver support; looking e.g. at f2fs
patch inline data bypasses read hook. Probably not an issue for 100M
file though.

> On Tue, Aug 23, 2016 at 9:59 PM, Andrei Borzenkov <address@hidden>
> wrote:
>> 23.08.2016 21:51, Michael Zimmermann пишет:
>>> Hi,
>>> how safe is the usage of save_env? I'm considering writing like 100MB to
>> a
>>> loop file using the technique used by this command.
>> Define "safe". Command is filesystem agnostic and expects fully
>> preallocated file; it writes on block level. It also builds full content
>> of environment file in memory before writing it out; so it may fail on
>> systems with small amount of memory.
>> It attempts to verify that file can be represented by block lists and it
>> does not overwrite blocks outside of allocated for the file.
>> _______________________________________________
>> Grub-devel mailing list
>> address@hidden
> _______________________________________________
> Grub-devel mailing list
> address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]