From: Vladimir 'phcoder' Serbinenko <phcoder@gmail.com>
To: The development of GRUB 2 <grub-devel@gnu.org>
Subject: Re: [PATCH] Refuse to install on XFS destroying its superblock
Date: Tue, 20 Oct 2009 12:51:34 +0200 [thread overview]
Message-ID: <4ADD9636.5050102@gmail.com> (raw)
In-Reply-To: <20091020101810.GA3952@thorin>
Robert Millan wrote:
> On Sun, Oct 18, 2009 at 06:30:11PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>
>> Robert Millan wrote:
>>
>>> On Sat, Oct 17, 2009 at 02:09:31PM +0200, Vladimir 'phcoder' Serbinenko wrote:
>>>
>>>
>>>>>> The danger is that fs_probe may reject filesystem as valid just because
>>>>>> it's newer than expected.
>>>>>>
>>>>>>
>>>>>>
>>>>> What do you mean with "reject filesystem as valid"?
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Sorry for being unclear. I just meant that if some XFS structures are
>>>> updated then our xfs driver won't recognise it as xfs
>>>>
>>>>
>>> What do you mean with "updated"? You mean a new implementation of XFS? Or
>>> the same instance of XFS that has been modified after use?
>>>
>>>
>>>
>> I mean next version on XFS
>>
>
> Sorry, but what did you expect? You want to prevent PEBCAK using
> heuristic. There's no way we can tell if those 512 bytes are valuable
> data, only the user can. And even if you try to err on the safest side,
> there's no garantee that newer versions of XFS, or other filesystems that
> don't even exist yet will be detectable by us no matter what we do.
>
>
I think best way is to have whitelist of OS which have first sector free
and possible manual override like it was suggested.
> Why don't we just take a backup like someone suggested a while ago? I
> think there was even a patch. This way if valuable data is lost, user can
> restore it (and while at it, learnt his lesson that filesystems and embedded
> code aren't really supposed to be mixed in the same place).
>
>
The backup is inevitably stored on the filesystem itself which becomes
inaccessible once superblock is destroyed.
--
Regards
Vladimir 'phcoder' Serbinenko
Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
next prev parent reply other threads:[~2009-10-20 10:51 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-16 10:56 [PATCH] Refuse to install on XFS destroying its superblock Vladimir 'phcoder' Serbinenko
2009-10-16 14:03 ` Vladimir 'phcoder' Serbinenko
2009-10-16 16:01 ` Jordi Mallach
2009-10-16 18:38 ` Robert Millan
2009-10-16 20:09 ` Vladimir 'phcoder' Serbinenko
2009-10-16 20:52 ` Robert Millan
2009-10-16 21:08 ` Vladimir 'phcoder' Serbinenko
2009-10-16 21:53 ` Robert Millan
2009-10-16 22:18 ` Vladimir 'phcoder' Serbinenko
2009-10-17 11:25 ` Robert Millan
2009-10-17 11:43 ` Vladimir 'phcoder' Serbinenko
2009-10-17 12:00 ` Robert Millan
2009-10-17 12:06 ` Felix Zielcke
2009-10-17 12:09 ` Vladimir 'phcoder' Serbinenko
2009-10-17 16:12 ` richardvoigt
2009-10-18 16:44 ` Vladimir 'phcoder' Serbinenko
2009-10-18 15:46 ` Robert Millan
2009-10-18 16:30 ` Vladimir 'phcoder' Serbinenko
2009-10-20 10:18 ` Robert Millan
2009-10-20 10:51 ` Vladimir 'phcoder' Serbinenko [this message]
2009-10-25 0:01 ` Robert Millan
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=4ADD9636.5050102@gmail.com \
--to=phcoder@gmail.com \
--cc=grub-devel@gnu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.