Messages in this thread | | | Date | Tue, 30 May 2017 11:37:40 +0900 | From | Hyunchul Lee <> | Subject | Re: [PATCH] ubifs: Add freeze support |
| |
On Mon, May 29, 2017 at 10:42:37AM +0200, Richard Weinberger wrote: > Hyunchul, > > Am 29.05.2017 um 04:24 schrieb Hyunchul Lee: > >>> This is just broken. First ubifs should still properly propagate > >>> the errors, and second freezing/unfreezing read only file systems is > >>> perfectly valid, > >> > >> it is right. > > > > if updating TNC is failed, ubifs might become inconsistant and be switched to > > read-only mode. for example, when ubifs_jnl_update is called to create a file, > > if inserting a znode for new inode is failed, TNC has only a znode for > > new dentry. and this can be only recoverd by replay. > > > > is it required to fix this? > > UBIFS is designed to be power-cut tolerant. > So, UBIFS must not corrupt in any case. > > Which failure are you facing? > > I have the feeling that you try to paper over some other issue. :-)
The failure hasn't happened. I wondered the following situation should be handled.
ubifs_create ubifs_jnl_update write_head ubifs_tnc_add_nm /* (1) add dentry to TNC */ ubifs_tnc_add /* (2) add new inode to TNC */ ubifs_tnc_add /* (3) add parent inode to TNC */
If ubifs_tnc_add(2) fails, TNC would have the index of a dentry which points to an invalid inode. So, though ubifs_readdir emits the dentry, this inode cannot be accessed. Becasue there isn't the index of the inode.
I know this situation is hardly probable. But UBIFS would be read-only and inconsitant in this situation, until replay is completed.
> > Thanks, > //richard
--
Thanks, Hyunchul
| |