[Top][All Lists]

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

Re: [PATCH] Refuse to install on XFS destroying its superblock

From: Robert Millan
Subject: Re: [PATCH] Refuse to install on XFS destroying its superblock
Date: Tue, 20 Oct 2009 12:18:10 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

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.

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).

Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

reply via email to

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