Re: safety of save_env

[Andrei Borzenkov]

24.08.2016 10:17, Andrei Borzenkov пишет:
> 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.
> 

Speaking about f2fs - does it use checksums for data or metadata? In
particular, if supporting block lists for inline data metadata checksums
may be an issue then.

Also I understand that it is designed for media which may not support
direct sector size write, or am I wrong?

Hmm ... inode checksums do mean problem for ext4 with inline data (not
yet in GRUB upstream).

>> 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
>>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>>
>>
>>
>>
>> _______________________________________________
>> Grub-devel mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>>
>