[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: safety of save_env
Re: safety of save_env
Wed, 24 Aug 2016 11:10:19 +0300
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
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>
>>> 23.08.2016 21:51, Michael Zimmermann пишет:
>>>> how safe is the usage of save_env? I'm considering writing like 100MB to
>>>> 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
>> Grub-devel mailing list