Re: [f2fs-dev] [PATCH 1/2] f2fs: fix to avoid quota inode leak in ->put_super
On 2018/8/29 10:05, Jaegeuk Kim wrote:
> On 08/21, Chao Yu wrote:
>> On 2018/8/21 10:38, Jaegeuk Kim wrote:
>>> On 08/20, Chao Yu wrote:
On 2018/8/18 23:16, Jaegeuk Kim wrote:
> On 08/17, Chao Yu wrote:
>> generic/019 reports below error:
>>
>> __quota_error: 1160 callbacks suppressed
>> Quota error (device zram1): write_blk: dquota write failed
>> Quota error (device zram1): qtree_write_dquot: Error -28 occurred while
>> creating quota
>> Quota error (device zram1): write_blk: dquota write failed
>> Quota error (device zram1): qtree_write_dquot: Error -28 occurred while
>> creating quota
>> Quota error (device zram1): write_blk: dquota write failed
>> Quota error (device zram1): qtree_write_dquot: Error -28 occurred while
>> creating quota
>> Quota error (device zram1): write_blk: dquota write failed
>> Quota error (device zram1): qtree_write_dquot: Error -28 occurred while
>> creating quota
>> Quota error (device zram1): write_blk: dquota write failed
>> Quota error (device zram1): qtree_write_dquot: Error -28 occurred while
>> creating quota
>> VFS: Busy inodes after unmount of zram1. Self-destruct in 5 seconds.
>> Have a nice day...
>>
>> If we failed in below path due to fail to write dquot block, we will miss
>> to release quota inode, fix it.
>>
>> - f2fs_put_super
>> - f2fs_quota_off_umount
>> - f2fs_quota_off
>>- f2fs_quota_sync <-- failed
>>- dquot_quota_off <-- missed to call
>>
>> Signed-off-by: Chao Yu
>> ---
>> fs/f2fs/super.c | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
>> index a5df9fbc6355..9647bbcdfd2b 100644
>> --- a/fs/f2fs/super.c
>> +++ b/fs/f2fs/super.c
>> @@ -1977,10 +1977,12 @@ void f2fs_quota_off_umount(struct super_block
>> *sb)
>> for (type = 0; type < MAXQUOTAS; type++) {
>> err = f2fs_quota_off(sb, type);
>> if (err) {
>> +int ret = dquot_quota_off(sb, type);
>> +
>
> Could you check the mainline version?
I guess we missed to apply below patch? Could you check that?
f2fs: report error if quota off error during umount
>>>
>>> I remember there was a bug in the patch.
>>
>> Yeah, I guess this patch can fix that one. So could you help trying to test
>> again with the two patches if you have time. :)
>
> Let me merge two patch and try some tests again. :P
Thanks for helping. ;)
Thanks,
>
>>
>> Thanks,
>>
>>>
Thanks,
>
>> f2fs_msg(sb, KERN_ERR,
>> "Fail to turn off disk quota "
>> -"(type: %d, err: %d), Please "
>> -"run fsck to fix it.", type, err);
>> +"(type: %d, err: %d, ret:%d), Please "
>> +"run fsck to fix it.", type, err, ret);
>> set_sbi_flag(F2FS_SB(sb), SBI_NEED_FSCK);
>> }
>> }
>> --
>> 2.18.0.rc1
>>>
>>> .
>>>
>
> .
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH] f2fs: avoid wrong decrypted data from disk
On 2018/8/28 6:52, Jaegeuk Kim wrote:
> 1. Create a file in an encrypted directory
> 2. Do GC & drop caches
> 3. Read stale data before its bio for metapage was not issued yet
>
> Signed-off-by: Jaegeuk Kim
> ---
> fs/f2fs/data.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index 382c1ef9a9e4..c3557fd4a0bd 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -1550,6 +1550,13 @@ static int f2fs_mpage_readpages(struct address_space
> *mapping,
> bio = NULL;
> }
> if (bio == NULL) {
> + /*
> + * If the page is under writeback, we need to wait for
> + * its completion to see the correct decrypted data.
> + */
> + if (unlikely(f2fs_encrypted_file(inode)))
> + f2fs_wait_on_block_writeback(F2FS_I_SB(inode),
> block_nr);
I think we have did this in f2fs_grab_read_bio(), so we just need to cover 'bio
!= NULL' case, right?
Thanks,
> +
> bio = f2fs_grab_read_bio(inode, block_nr, nr_pages,
> is_readahead ? REQ_RAHEAD : 0);
> if (IS_ERR(bio)) {
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 1/2] f2fs: fix to avoid quota inode leak in ->put_super
On 08/21, Chao Yu wrote:
> On 2018/8/21 10:38, Jaegeuk Kim wrote:
> > On 08/20, Chao Yu wrote:
> >> On 2018/8/18 23:16, Jaegeuk Kim wrote:
> >>> On 08/17, Chao Yu wrote:
> generic/019 reports below error:
>
> __quota_error: 1160 callbacks suppressed
> Quota error (device zram1): write_blk: dquota write failed
> Quota error (device zram1): qtree_write_dquot: Error -28 occurred while
> creating quota
> Quota error (device zram1): write_blk: dquota write failed
> Quota error (device zram1): qtree_write_dquot: Error -28 occurred while
> creating quota
> Quota error (device zram1): write_blk: dquota write failed
> Quota error (device zram1): qtree_write_dquot: Error -28 occurred while
> creating quota
> Quota error (device zram1): write_blk: dquota write failed
> Quota error (device zram1): qtree_write_dquot: Error -28 occurred while
> creating quota
> Quota error (device zram1): write_blk: dquota write failed
> Quota error (device zram1): qtree_write_dquot: Error -28 occurred while
> creating quota
> VFS: Busy inodes after unmount of zram1. Self-destruct in 5 seconds.
> Have a nice day...
>
> If we failed in below path due to fail to write dquot block, we will miss
> to release quota inode, fix it.
>
> - f2fs_put_super
> - f2fs_quota_off_umount
> - f2fs_quota_off
> - f2fs_quota_sync <-- failed
> - dquot_quota_off <-- missed to call
>
> Signed-off-by: Chao Yu
> ---
> fs/f2fs/super.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> index a5df9fbc6355..9647bbcdfd2b 100644
> --- a/fs/f2fs/super.c
> +++ b/fs/f2fs/super.c
> @@ -1977,10 +1977,12 @@ void f2fs_quota_off_umount(struct super_block
> *sb)
> for (type = 0; type < MAXQUOTAS; type++) {
> err = f2fs_quota_off(sb, type);
> if (err) {
> +int ret = dquot_quota_off(sb, type);
> +
> >>>
> >>> Could you check the mainline version?
> >>
> >> I guess we missed to apply below patch? Could you check that?
> >>
> >> f2fs: report error if quota off error during umount
> >
> > I remember there was a bug in the patch.
>
> Yeah, I guess this patch can fix that one. So could you help trying to test
> again with the two patches if you have time. :)
Let me merge two patch and try some tests again. :P
>
> Thanks,
>
> >
> >>
> >> Thanks,
> >>
> >>>
> f2fs_msg(sb, KERN_ERR,
> "Fail to turn off disk quota "
> -"(type: %d, err: %d), Please "
> -"run fsck to fix it.", type, err);
> +"(type: %d, err: %d, ret:%d), Please "
> +"run fsck to fix it.", type, err, ret);
> set_sbi_flag(F2FS_SB(sb), SBI_NEED_FSCK);
> }
> }
> --
> 2.18.0.rc1
> >
> > .
> >
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [RFC PATCH 10/10] f2fs: fs-verity support
On 08/29, Chao Yu wrote:
> On 2018/8/29 1:01, Jaegeuk Kim wrote:
> > On 08/28, Chao Yu wrote:
> >> On 2018/8/28 15:27, Jaegeuk Kim wrote:
> >>> On 08/27, Chao Yu wrote:
> Hi Eric,
>
> On 2018/8/27 1:35, Eric Biggers wrote:
> > Hi Chao,
> >
> > On Sat, Aug 25, 2018 at 01:54:08PM +0800, Chao Yu wrote:
> >> On 2018/8/25 0:16, Eric Biggers wrote:
> >>> From: Eric Biggers
> >>> #ifdef CONFIG_F2FS_CHECK_FS
> >>> #define f2fs_bug_on(sbi, condition) BUG_ON(condition)
> >>> #else
> >>> @@ -146,7 +149,7 @@ struct f2fs_mount_info {
> >>> #define F2FS_FEATURE_QUOTA_INO 0x0080
> >>> #define F2FS_FEATURE_INODE_CRTIME0x0100
> >>> #define F2FS_FEATURE_LOST_FOUND 0x0200
> >>> -#define F2FS_FEATURE_VERITY 0x0400 /* reserved */
> >>> +#define F2FS_FEATURE_VERITY 0x0400
> >>>
> >>> #define F2FS_HAS_FEATURE(sb, mask)
> >>> \
> >>> ((F2FS_SB(sb)->raw_super->feature & cpu_to_le32(mask)) != 0)
> >>> @@ -598,7 +601,7 @@ enum {
> >>> #define FADVISE_ENC_NAME_BIT 0x08
> >>> #define FADVISE_KEEP_SIZE_BIT0x10
> >>> #define FADVISE_HOT_BIT 0x20
> >>> -#define FADVISE_VERITY_BIT 0x40/* reserved */
> >>> +#define FADVISE_VERITY_BIT 0x40
> >>
> >> As I suggested before, how about moving f2fs' verity_bit from
> >> i_fadvise to more
> >> generic i_flags field like ext4, so we can a) remaining more bits for
> >> those
> >> demands which really need file advise fields. b) using i_flags bits
> >> keeping line
> >> with ext4. Not sure, if user want to know whether the file is verity
> >> one, it
> >> will be easy for f2fs to export the status through FS_IOC_SETFLAGS.
> >>
> >> #define EXT4_VERITY_FL 0x0010 /* Verity protected
> >> inode */
> >>
> >> #define F2FS_VERITY_FL 0x0010 /* Verity protected
> >> inode */
> >>
> >
> > I don't like using i_advise much either, but I actually don't see either
> > location being much better than the other at the moment. The real
> > problem is an
> > artificial one: the i_flags in f2fs's on-disk format are being assumed
> > to use
>
> Yeah, but since most copied flags from vfs/ext4 are not actually used in
> f2fs,
> also 0x0010 bit is not used now, so we can just define it now
> directly for
> verity bit.
>
> Cleanup and remapping in ioctl interface for those unused flags, we can
> do it
> latter?
> >>>
> >>> No, it was reserved by f2fs-tools,
> >>
> >> That's not a problem, since we didn't use that reserved bit in any of
> >> images
> >> now, there is no backward compatibility issue.
> >
> > We're using that.
>
> Oops, if it was in production, I agree to keep it in i_advice, otherwise, we
> still can discuss its location.
>
> >
> >>
> >>> and I think this should be aligned to the encryption bit.
> >>
> >> Alright, we could, but if so, i_advise will run out of space earlier,
> >> after that
> >> we have to add real advice bit into i_inline or i_flags, that would be a
> >> little
> >> weird.
> >>
> >> For encryption bit, as a common vfs feature flag, in the beginning of
> >> encryption
> >> development, it will be better to set it into i_flags, IMO, but now, we
> >> have to
> >> keep it as it was.
> >>
> >>> Moreover, we guarantee i_flags less strictly from power-cut than i_advise.
> >>
> >> IMO, in power-cut scenario, it needs to keep both i_flags and i_advise
> >> being
> >> recoverable strictly. Any condition that we can not recover i_flags?
> >
> > In __f2fs_ioc_setflags, f2fs_mark_inode_dirty_sync(inode, false);
>
> Ah, that's right, do you remember why we treat them with different recoverable
> level?
Since I thought that such the flags wouln't be critical on power cuts, but be
enough for us to guarantee by write_inode() or fsync().
>
> Thanks,
>
> >
> >>
> >> Thanks,
> >>
> >>>
>
> Thanks,
>
> > the same numbering scheme as ext4's on-disk format, which makes it seem
> > that
> > they have to be in sync, and that all new ext4 flags (say, EA_INODE)
> > also
> > reserve bits in f2fs and vice versa, when they in fact do not.
> > Instead, f2fs
> > should use its own numbering for its i_flags, and it should map them
> > to/from
> > whatever is needed for common APIs like FS_IOC_{GET,SET}FLAGS and
> > FS_IOC_FS{GET,SET}XATTR.
> >
> > So putting the verity flag in *either* location (i_advise or i_flags)
> > is just
> > kicking the can down the road. If I get around to it I will send a
> > patch that
> > cleans up the f2fs flags properly...>
> > Thanks,
> >
> > - Eric
> >
> >
Re: [f2fs-dev] [RFC PATCH 10/10] f2fs: fs-verity support
On 2018/8/29 1:01, Jaegeuk Kim wrote:
> On 08/28, Chao Yu wrote:
>> On 2018/8/28 15:27, Jaegeuk Kim wrote:
>>> On 08/27, Chao Yu wrote:
Hi Eric,
On 2018/8/27 1:35, Eric Biggers wrote:
> Hi Chao,
>
> On Sat, Aug 25, 2018 at 01:54:08PM +0800, Chao Yu wrote:
>> On 2018/8/25 0:16, Eric Biggers wrote:
>>> From: Eric Biggers
>>> #ifdef CONFIG_F2FS_CHECK_FS
>>> #define f2fs_bug_on(sbi, condition)BUG_ON(condition)
>>> #else
>>> @@ -146,7 +149,7 @@ struct f2fs_mount_info {
>>> #define F2FS_FEATURE_QUOTA_INO 0x0080
>>> #define F2FS_FEATURE_INODE_CRTIME 0x0100
>>> #define F2FS_FEATURE_LOST_FOUND0x0200
>>> -#define F2FS_FEATURE_VERITY0x0400 /* reserved */
>>> +#define F2FS_FEATURE_VERITY0x0400
>>>
>>> #define F2FS_HAS_FEATURE(sb, mask)
>>> \
>>> ((F2FS_SB(sb)->raw_super->feature & cpu_to_le32(mask)) != 0)
>>> @@ -598,7 +601,7 @@ enum {
>>> #define FADVISE_ENC_NAME_BIT 0x08
>>> #define FADVISE_KEEP_SIZE_BIT 0x10
>>> #define FADVISE_HOT_BIT0x20
>>> -#define FADVISE_VERITY_BIT 0x40/* reserved */
>>> +#define FADVISE_VERITY_BIT 0x40
>>
>> As I suggested before, how about moving f2fs' verity_bit from i_fadvise
>> to more
>> generic i_flags field like ext4, so we can a) remaining more bits for
>> those
>> demands which really need file advise fields. b) using i_flags bits
>> keeping line
>> with ext4. Not sure, if user want to know whether the file is verity
>> one, it
>> will be easy for f2fs to export the status through FS_IOC_SETFLAGS.
>>
>> #define EXT4_VERITY_FL 0x0010 /* Verity protected
>> inode */
>>
>> #define F2FS_VERITY_FL 0x0010 /* Verity protected
>> inode */
>>
>
> I don't like using i_advise much either, but I actually don't see either
> location being much better than the other at the moment. The real
> problem is an
> artificial one: the i_flags in f2fs's on-disk format are being assumed to
> use
Yeah, but since most copied flags from vfs/ext4 are not actually used in
f2fs,
also 0x0010 bit is not used now, so we can just define it now directly
for
verity bit.
Cleanup and remapping in ioctl interface for those unused flags, we can do
it
latter?
>>>
>>> No, it was reserved by f2fs-tools,
>>
>> That's not a problem, since we didn't use that reserved bit in any of images
>> now, there is no backward compatibility issue.
>
> We're using that.
Oops, if it was in production, I agree to keep it in i_advice, otherwise, we
still can discuss its location.
>
>>
>>> and I think this should be aligned to the encryption bit.
>>
>> Alright, we could, but if so, i_advise will run out of space earlier, after
>> that
>> we have to add real advice bit into i_inline or i_flags, that would be a
>> little
>> weird.
>>
>> For encryption bit, as a common vfs feature flag, in the beginning of
>> encryption
>> development, it will be better to set it into i_flags, IMO, but now, we have
>> to
>> keep it as it was.
>>
>>> Moreover, we guarantee i_flags less strictly from power-cut than i_advise.
>>
>> IMO, in power-cut scenario, it needs to keep both i_flags and i_advise being
>> recoverable strictly. Any condition that we can not recover i_flags?
>
> In __f2fs_ioc_setflags, f2fs_mark_inode_dirty_sync(inode, false);
Ah, that's right, do you remember why we treat them with different recoverable
level?
Thanks,
>
>>
>> Thanks,
>>
>>>
Thanks,
> the same numbering scheme as ext4's on-disk format, which makes it seem
> that
> they have to be in sync, and that all new ext4 flags (say, EA_INODE) also
> reserve bits in f2fs and vice versa, when they in fact do not. Instead,
> f2fs
> should use its own numbering for its i_flags, and it should map them
> to/from
> whatever is needed for common APIs like FS_IOC_{GET,SET}FLAGS and
> FS_IOC_FS{GET,SET}XATTR.
>
> So putting the verity flag in *either* location (i_advise or i_flags) is
> just
> kicking the can down the road. If I get around to it I will send a patch
> that
> cleans up the f2fs flags properly...>
> Thanks,
>
> - Eric
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>
>>>
>>> .
>>>
>
> .
>
Re: [f2fs-dev] [RFC PATCH 10/10] f2fs: fs-verity support
On 08/28, Chao Yu wrote:
> On 2018/8/28 15:27, Jaegeuk Kim wrote:
> > On 08/27, Chao Yu wrote:
> >> Hi Eric,
> >>
> >> On 2018/8/27 1:35, Eric Biggers wrote:
> >>> Hi Chao,
> >>>
> >>> On Sat, Aug 25, 2018 at 01:54:08PM +0800, Chao Yu wrote:
> On 2018/8/25 0:16, Eric Biggers wrote:
> > From: Eric Biggers
> > #ifdef CONFIG_F2FS_CHECK_FS
> > #define f2fs_bug_on(sbi, condition)BUG_ON(condition)
> > #else
> > @@ -146,7 +149,7 @@ struct f2fs_mount_info {
> > #define F2FS_FEATURE_QUOTA_INO 0x0080
> > #define F2FS_FEATURE_INODE_CRTIME 0x0100
> > #define F2FS_FEATURE_LOST_FOUND0x0200
> > -#define F2FS_FEATURE_VERITY0x0400 /* reserved */
> > +#define F2FS_FEATURE_VERITY0x0400
> >
> > #define F2FS_HAS_FEATURE(sb, mask)
> > \
> > ((F2FS_SB(sb)->raw_super->feature & cpu_to_le32(mask)) != 0)
> > @@ -598,7 +601,7 @@ enum {
> > #define FADVISE_ENC_NAME_BIT 0x08
> > #define FADVISE_KEEP_SIZE_BIT 0x10
> > #define FADVISE_HOT_BIT0x20
> > -#define FADVISE_VERITY_BIT 0x40/* reserved */
> > +#define FADVISE_VERITY_BIT 0x40
>
> As I suggested before, how about moving f2fs' verity_bit from i_fadvise
> to more
> generic i_flags field like ext4, so we can a) remaining more bits for
> those
> demands which really need file advise fields. b) using i_flags bits
> keeping line
> with ext4. Not sure, if user want to know whether the file is verity
> one, it
> will be easy for f2fs to export the status through FS_IOC_SETFLAGS.
>
> #define EXT4_VERITY_FL 0x0010 /* Verity protected
> inode */
>
> #define F2FS_VERITY_FL 0x0010 /* Verity protected
> inode */
>
> >>>
> >>> I don't like using i_advise much either, but I actually don't see either
> >>> location being much better than the other at the moment. The real
> >>> problem is an
> >>> artificial one: the i_flags in f2fs's on-disk format are being assumed to
> >>> use
> >>
> >> Yeah, but since most copied flags from vfs/ext4 are not actually used in
> >> f2fs,
> >> also 0x0010 bit is not used now, so we can just define it now directly
> >> for
> >> verity bit.
> >>
> >> Cleanup and remapping in ioctl interface for those unused flags, we can do
> >> it
> >> latter?
> >
> > No, it was reserved by f2fs-tools,
>
> That's not a problem, since we didn't use that reserved bit in any of images
> now, there is no backward compatibility issue.
We're using that.
>
> > and I think this should be aligned to the encryption bit.
>
> Alright, we could, but if so, i_advise will run out of space earlier, after
> that
> we have to add real advice bit into i_inline or i_flags, that would be a
> little
> weird.
>
> For encryption bit, as a common vfs feature flag, in the beginning of
> encryption
> development, it will be better to set it into i_flags, IMO, but now, we have
> to
> keep it as it was.
>
> > Moreover, we guarantee i_flags less strictly from power-cut than i_advise.
>
> IMO, in power-cut scenario, it needs to keep both i_flags and i_advise being
> recoverable strictly. Any condition that we can not recover i_flags?
In __f2fs_ioc_setflags, f2fs_mark_inode_dirty_sync(inode, false);
>
> Thanks,
>
> >
> >>
> >> Thanks,
> >>
> >>> the same numbering scheme as ext4's on-disk format, which makes it seem
> >>> that
> >>> they have to be in sync, and that all new ext4 flags (say, EA_INODE) also
> >>> reserve bits in f2fs and vice versa, when they in fact do not. Instead,
> >>> f2fs
> >>> should use its own numbering for its i_flags, and it should map them
> >>> to/from
> >>> whatever is needed for common APIs like FS_IOC_{GET,SET}FLAGS and
> >>> FS_IOC_FS{GET,SET}XATTR.
> >>>
> >>> So putting the verity flag in *either* location (i_advise or i_flags) is
> >>> just
> >>> kicking the can down the road. If I get around to it I will send a patch
> >>> that
> >>> cleans up the f2fs flags properly...>
> >>> Thanks,
> >>>
> >>> - Eric
> >>>
> >>> --
> >>> Check out the vibrant tech community on one of the world's most
> >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >>> ___
> >>> Linux-f2fs-devel mailing list
> >>> Linux-f2fs-devel@lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> >>>
> >
> > .
> >
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
Re: [f2fs-dev] [PATCH 1/2] add configure option --with-root-libdir
On 08/28, Theodore Y. Ts'o wrote: > On Tue, Aug 28, 2018 at 12:12:02AM -0700, Jaegeuk Kim wrote: > > > > I think f2fs-tools is getting much firmer lib APIs, so don't expect frequent > > major updates on library versions, but was struggling to keep it as much as > > possible tho. I'm checking the final test results, and thus, planning to > > release 1.11.1 within a week or so. In this release, I'm seeing that > > it requires to bump revision like libf2fs-5.1.0, and libf2fs-format-4.1.0. > > Just checking to be sure --- does 5.1.0 mean that that were no changes > to interfaces that were already present in 5.0.0, but there are new > interfaces added? That's what a minor version bump generally means, > but I just want to be sure. Ah, probably I misunderstood the below? https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html I understood that, if there is no interface change but some implementation changes, I need to bump revision. If new interface is added, for example, I need to bump current while revision=0 and age++. Please correct me, if I'm going in wrong way. > > Thanks, > > - Ted -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 1/2] add configure option --with-root-libdir
On Tue, Aug 28, 2018 at 12:12:02AM -0700, Jaegeuk Kim wrote: > > I think f2fs-tools is getting much firmer lib APIs, so don't expect frequent > major updates on library versions, but was struggling to keep it as much as > possible tho. I'm checking the final test results, and thus, planning to > release 1.11.1 within a week or so. In this release, I'm seeing that > it requires to bump revision like libf2fs-5.1.0, and libf2fs-format-4.1.0. Just checking to be sure --- does 5.1.0 mean that that were no changes to interfaces that were already present in 5.0.0, but there are new interfaces added? That's what a minor version bump generally means, but I just want to be sure. Thanks, - Ted -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [RFC PATCH v2 3/4] f2fs-tools: unify the writeback of superblock
On 2018/8/28 21:47, Chao Yu wrote:
> On 2018/8/14 14:56, Junling Zheng wrote:
>> Introduce __write_superblock() to support updating specified one
>> superblock or both, thus we can wrapper it in update_superblock() and
>> f2fs_write_super_block to unify all places where sb needs to be updated.
>>
>> Signed-off-by: Junling Zheng
>> ---
>> v1 -> v2:
>> - if dev_write_block failed, add some notes and free buf to avoid memory
>> leak.
>> fsck/fsck.h| 2 +-
>> fsck/mount.c | 74 +++---
>> fsck/resize.c | 20 ++---
>> include/f2fs_fs.h | 35 ++
>> mkfs/f2fs_format.c | 19 +---
>> 5 files changed, 56 insertions(+), 94 deletions(-)
>>
>> diff --git a/fsck/fsck.h b/fsck/fsck.h
>> index 6042e68..e3490e6 100644
>> --- a/fsck/fsck.h
>> +++ b/fsck/fsck.h
>> @@ -178,7 +178,7 @@ extern void move_curseg_info(struct f2fs_sb_info *, u64,
>> int);
>> extern void write_curseg_info(struct f2fs_sb_info *);
>> extern int find_next_free_block(struct f2fs_sb_info *, u64 *, int, int);
>> extern void write_checkpoint(struct f2fs_sb_info *);
>> -extern void write_superblock(struct f2fs_super_block *);
>> +extern void update_superblock(struct f2fs_super_block *, int);
>> extern void update_data_blkaddr(struct f2fs_sb_info *, nid_t, u16, block_t);
>> extern void update_nat_blkaddr(struct f2fs_sb_info *, nid_t, nid_t,
>> block_t);
>>
>> diff --git a/fsck/mount.c b/fsck/mount.c
>> index 58ef3e6..e7ceb8d 100644
>> --- a/fsck/mount.c
>> +++ b/fsck/mount.c
>> @@ -476,7 +476,7 @@ void print_sb_state(struct f2fs_super_block *sb)
>> }
>>
>> static inline int sanity_check_area_boundary(struct f2fs_super_block *sb,
>> -u64 offset)
>> +enum SB_ADDR sb_addr)
>> {
>> u32 segment0_blkaddr = get_sb(segment0_blkaddr);
>> u32 cp_blkaddr = get_sb(cp_blkaddr);
>> @@ -542,14 +542,11 @@ static inline int sanity_check_area_boundary(struct
>> f2fs_super_block *sb,
>> segment_count_main << log_blocks_per_seg);
>> return -1;
>> } else if (main_end_blkaddr < seg_end_blkaddr) {
>> -int err;
>> -
>> set_sb(segment_count, (main_end_blkaddr -
>> segment0_blkaddr) >> log_blocks_per_seg);
>>
>> -err = dev_write(sb, offset, sizeof(struct f2fs_super_block));
>> -MSG(0, "Info: Fix alignment: %s, start(%u) end(%u) block(%u)\n",
>> -err ? "failed": "done",
>> +update_superblock(sb, 1 << sb_addr);
>> +MSG(0, "Info: Fix alignment: start(%u) end(%u) block(%u)\n",
>> main_blkaddr,
>> segment0_blkaddr +
>> (segment_count << log_blocks_per_seg),
>> @@ -558,7 +555,7 @@ static inline int sanity_check_area_boundary(struct
>> f2fs_super_block *sb,
>> return 0;
>> }
>>
>> -int sanity_check_raw_super(struct f2fs_super_block *sb, u64 offset)
>> +int sanity_check_raw_super(struct f2fs_super_block *sb, enum SB_ADDR
>> sb_addr)
>> {
>> unsigned int blocksize;
>>
>> @@ -600,30 +597,24 @@ int sanity_check_raw_super(struct f2fs_super_block
>> *sb, u64 offset)
>> if (get_sb(segment_count) > F2FS_MAX_SEGMENT)
>> return -1;
>>
>> -if (sanity_check_area_boundary(sb, offset))
>> +if (sanity_check_area_boundary(sb, sb_addr))
>> return -1;
>> return 0;
>> }
>>
>> -int validate_super_block(struct f2fs_sb_info *sbi, int block)
>> +int validate_super_block(struct f2fs_sb_info *sbi, enum SB_ADDR sb_addr)
>> {
>> -u64 offset;
>> char buf[F2FS_BLKSIZE];
>>
>> sbi->raw_super = malloc(sizeof(struct f2fs_super_block));
>>
>> -if (block == 0)
>> -offset = F2FS_SUPER_OFFSET;
>> -else
>> -offset = F2FS_BLKSIZE + F2FS_SUPER_OFFSET;
>> -
>> -if (dev_read_block(buf, block))
>> +if (dev_read_block(buf, sb_addr))
>> return -1;
>>
>> memcpy(sbi->raw_super, buf + F2FS_SUPER_OFFSET,
>> sizeof(struct f2fs_super_block));
>>
>> -if (!sanity_check_raw_super(sbi->raw_super, offset)) {
>> +if (!sanity_check_raw_super(sbi->raw_super, sb_addr)) {
>> /* get kernel version */
>> if (c.kd >= 0) {
>> dev_read_version(c.version, 0, VERSION_LEN);
>> @@ -642,13 +633,9 @@ int validate_super_block(struct f2fs_sb_info *sbi, int
>> block)
>> MSG(0, "Info: FSCK version\n from \"%s\"\nto \"%s\"\n",
>> c.sb_version, c.version);
>> if (memcmp(c.sb_version, c.version, VERSION_LEN)) {
>> -int ret;
>> -
>> memcpy(sbi->raw_super->version,
>> c.version, VERSION_LEN);
>> -ret =
[f2fs-dev] [Bug 200635] Oops error in refresh_sit_entry() while unmounting a crafted F2FS image
https://bugzilla.kernel.org/show_bug.cgi?id=200635 --- Comment #6 from Chao Yu (c...@kernel.org) --- SB checksum feature is not upstreamed yet, and there is one bug in the patch, could you fix this manually and apply that patchset? https://sourceforge.net/p/linux-f2fs/mailman/message/36402182/ I wrote a patch, which is based on sb checksum feature, could you have a try? https://sourceforge.net/p/linux-f2fs/mailman/message/36402198/ -- You are receiving this mail because: You are watching the assignee of the bug. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
[f2fs-dev] [PATCH] fsck.f2fs: try to recover cp_payload from valid cp pack
If sb checksum is not enabled, and cp pack is valid due to no
crc inconsistence, let's try to recover cp_payload based on
cp_pack_start_sum in cp pack.
Signed-off-by: Chao Yu
---
fsck/f2fs.h | 5 +
fsck/mount.c | 10 +++---
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/fsck/f2fs.h b/fsck/f2fs.h
index d2164449db15..0d0d5e2cc399 100644
--- a/fsck/f2fs.h
+++ b/fsck/f2fs.h
@@ -259,6 +259,11 @@ static inline unsigned long __bitmap_size(struct
f2fs_sb_info *sbi, int flag)
return 0;
}
+static inline block_t __cp_payload(struct f2fs_sb_info *sbi)
+{
+ return le32_to_cpu(F2FS_RAW_SUPER(sbi)->cp_payload);
+}
+
static inline void *__bitmap_ptr(struct f2fs_sb_info *sbi, int flag)
{
struct f2fs_checkpoint *ckpt = F2FS_CKPT(sbi);
diff --git a/fsck/mount.c b/fsck/mount.c
index 4f0c3fc0db50..9421f5953cd8 100644
--- a/fsck/mount.c
+++ b/fsck/mount.c
@@ -945,12 +945,16 @@ int sanity_check_ckpt(struct f2fs_sb_info *sbi)
}
cp_pack_start_sum = __start_sum_addr(sbi);
- cp_payload = get_sb(cp_payload);
+ cp_payload = __cp_payload(sbi);
if (cp_pack_start_sum < cp_payload + 1 ||
cp_pack_start_sum > blocks_per_seg - 1 -
NR_CURSEG_TYPE) {
- MSG(0, "\tWrong cp_pack_start_sum(%u)\n", cp_pack_start_sum);
- return 1;
+ MSG(0, "\tWrong cp_pack_start_sum(%u) or cp_payload(%u)\n",
+ cp_pack_start_sum, cp_payload);
+ if ((get_sb(feature) & F2FS_FEATURE_SB_CHKSUM))
+ return 1;
+ set_sb(cp_payload, cp_pack_start_sum - 1);
+ update_superblock(sb, SB_ALL);
}
return 0;
--
2.18.0.rc1
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [RFC PATCH v2 3/4] f2fs-tools: unify the writeback of superblock
On 2018/8/14 14:56, Junling Zheng wrote:
> Introduce __write_superblock() to support updating specified one
> superblock or both, thus we can wrapper it in update_superblock() and
> f2fs_write_super_block to unify all places where sb needs to be updated.
>
> Signed-off-by: Junling Zheng
> ---
> v1 -> v2:
> - if dev_write_block failed, add some notes and free buf to avoid memory
> leak.
> fsck/fsck.h| 2 +-
> fsck/mount.c | 74 +++---
> fsck/resize.c | 20 ++---
> include/f2fs_fs.h | 35 ++
> mkfs/f2fs_format.c | 19 +---
> 5 files changed, 56 insertions(+), 94 deletions(-)
>
> diff --git a/fsck/fsck.h b/fsck/fsck.h
> index 6042e68..e3490e6 100644
> --- a/fsck/fsck.h
> +++ b/fsck/fsck.h
> @@ -178,7 +178,7 @@ extern void move_curseg_info(struct f2fs_sb_info *, u64,
> int);
> extern void write_curseg_info(struct f2fs_sb_info *);
> extern int find_next_free_block(struct f2fs_sb_info *, u64 *, int, int);
> extern void write_checkpoint(struct f2fs_sb_info *);
> -extern void write_superblock(struct f2fs_super_block *);
> +extern void update_superblock(struct f2fs_super_block *, int);
> extern void update_data_blkaddr(struct f2fs_sb_info *, nid_t, u16, block_t);
> extern void update_nat_blkaddr(struct f2fs_sb_info *, nid_t, nid_t, block_t);
>
> diff --git a/fsck/mount.c b/fsck/mount.c
> index 58ef3e6..e7ceb8d 100644
> --- a/fsck/mount.c
> +++ b/fsck/mount.c
> @@ -476,7 +476,7 @@ void print_sb_state(struct f2fs_super_block *sb)
> }
>
> static inline int sanity_check_area_boundary(struct f2fs_super_block *sb,
> - u64 offset)
> + enum SB_ADDR sb_addr)
> {
> u32 segment0_blkaddr = get_sb(segment0_blkaddr);
> u32 cp_blkaddr = get_sb(cp_blkaddr);
> @@ -542,14 +542,11 @@ static inline int sanity_check_area_boundary(struct
> f2fs_super_block *sb,
> segment_count_main << log_blocks_per_seg);
> return -1;
> } else if (main_end_blkaddr < seg_end_blkaddr) {
> - int err;
> -
> set_sb(segment_count, (main_end_blkaddr -
> segment0_blkaddr) >> log_blocks_per_seg);
>
> - err = dev_write(sb, offset, sizeof(struct f2fs_super_block));
> - MSG(0, "Info: Fix alignment: %s, start(%u) end(%u) block(%u)\n",
> - err ? "failed": "done",
> + update_superblock(sb, 1 << sb_addr);
> + MSG(0, "Info: Fix alignment: start(%u) end(%u) block(%u)\n",
> main_blkaddr,
> segment0_blkaddr +
> (segment_count << log_blocks_per_seg),
> @@ -558,7 +555,7 @@ static inline int sanity_check_area_boundary(struct
> f2fs_super_block *sb,
> return 0;
> }
>
> -int sanity_check_raw_super(struct f2fs_super_block *sb, u64 offset)
> +int sanity_check_raw_super(struct f2fs_super_block *sb, enum SB_ADDR sb_addr)
> {
> unsigned int blocksize;
>
> @@ -600,30 +597,24 @@ int sanity_check_raw_super(struct f2fs_super_block *sb,
> u64 offset)
> if (get_sb(segment_count) > F2FS_MAX_SEGMENT)
> return -1;
>
> - if (sanity_check_area_boundary(sb, offset))
> + if (sanity_check_area_boundary(sb, sb_addr))
> return -1;
> return 0;
> }
>
> -int validate_super_block(struct f2fs_sb_info *sbi, int block)
> +int validate_super_block(struct f2fs_sb_info *sbi, enum SB_ADDR sb_addr)
> {
> - u64 offset;
> char buf[F2FS_BLKSIZE];
>
> sbi->raw_super = malloc(sizeof(struct f2fs_super_block));
>
> - if (block == 0)
> - offset = F2FS_SUPER_OFFSET;
> - else
> - offset = F2FS_BLKSIZE + F2FS_SUPER_OFFSET;
> -
> - if (dev_read_block(buf, block))
> + if (dev_read_block(buf, sb_addr))
> return -1;
>
> memcpy(sbi->raw_super, buf + F2FS_SUPER_OFFSET,
> sizeof(struct f2fs_super_block));
>
> - if (!sanity_check_raw_super(sbi->raw_super, offset)) {
> + if (!sanity_check_raw_super(sbi->raw_super, sb_addr)) {
> /* get kernel version */
> if (c.kd >= 0) {
> dev_read_version(c.version, 0, VERSION_LEN);
> @@ -642,13 +633,9 @@ int validate_super_block(struct f2fs_sb_info *sbi, int
> block)
> MSG(0, "Info: FSCK version\n from \"%s\"\nto \"%s\"\n",
> c.sb_version, c.version);
> if (memcmp(c.sb_version, c.version, VERSION_LEN)) {
> - int ret;
> -
> memcpy(sbi->raw_super->version,
> c.version, VERSION_LEN);
> - ret = dev_write(sbi->raw_super, offset,
> - sizeof(struct f2fs_super_block));
> -
Re: [f2fs-dev] Corrupt F2FS partition - fsck is useless
Yes, I did my best to rebase it: https://paste.pound-python.org/show/nWshXUd5QSLbj5ZCugPy/ Unfortunately, it aborts: [ASSERT] (sanity_check_nid: 391) --> nid[0x3] ino is 0 #0 sanity_check_nid (sbi=sbi@entry=0x55782800 , nid=nid@entry=3, node_blk=node_blk@entry=0x557d6fe0, ftype=ftype@entry=F2FS_FT_DIR, ntype=ntype@entry=TYPE_INODE, ni=ni@entry=0x7fffd660) at fsck.c:392 #1 0xd853 in fsck_chk_fs (sbi=, blk_cnt=0x7fffd6ec) at fsck.c:997 #2 0x675c in do_fsck (sbi=0x55782800 ) at main.c:565 #3 main (argc=, argv=) at main.c:725 Luke On Tuesday 28 August 2018 09:28:57 Chao Yu wrote: > Hi Luke, > > Do you have tried Sheng Yong's patch? > > BTW, before recovering root inode, it needs to backup your entire image. > > On 2018/8/24 23:59, Chao Yu wrote: > > On 2018/8/24 22:38, Luke Dashjr wrote: > >> Info: Debug level = 1 > >> Info: Segments per section = 1 > >> Info: Sections per zone = 1 > >> Info: sector size = 512 > >> Info: total sectors = 12597656 (6151 MB) > >> Info: MKFS version > >> "Linux version 3.10.49-geda0055-01928-gb21c1b57 (hudsoncm@ilclbld30) > >> (gcc version 4.8 (GCC) ) #1 SMP PREEMPT Fri Feb 5 20:48:53 CST 2016" > >> Info: FSCK version > >> from "Linux version 4.17.11-gentoo (root@ishibashi) (gcc version 7.3.0 > >> (Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29 04:07:16 UTC > >> 2018" to "Linux version 4.17.11-gentoo (root@ishibashi) (gcc version > >> 7.3.0 (Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29 04:07:16 > >> UTC 2018" Info: superblock features = 0 : > >> Info: superblock encrypt level = 0, salt = > >> > >> > >> ++ > >> > >> | Super block| > >> > >> ++ > >> magic [0xf2f52010 : 4076150800] > >> major_ver [0x 1 : 1] > >> volum_name [] > >> minor_ver [0x 2 : 2] > >> log_sectorsize [0x 9 : 9] > >> log_sectors_per_block [0x 3 : 3] > >> log_blocksize [0x c : 12] > >> log_blocks_per_seg [0x 9 : 9] > >> segs_per_sec[0x 1 : 1] > >> secs_per_zone [0x 1 : 1] > >> checksum_offset [0x 0 : 0] > >> block_count [0x 13ffe0 : 1310688] > >> section_count [0x 9e9 : 2537] > >> segment_count [0x 9fe : 2558] > >> segment_count_ckpt [0x 2 : 2] > >> segment_count_sit [0x 2 : 2] > >> segment_count_nat [0x c : 12] > >> segment_count_ssa [0x 5 : 5] > >> segment_count_main [0x 9e9 : 2537] > >> segment0_blkaddr[0x 200 : 512] > >> cp_blkaddr [0x 200 : 512] > >> sit_blkaddr [0x 600 : 1536] > >> nat_blkaddr [0x a00 : 2560] > >> ssa_blkaddr [0x2200 : 8704] > >> main_blkaddr[0x2c00 : 11264] > >> root_ino[0x 3 : 3] > >> node_ino[0x 1 : 1] > >> meta_ino[0x 2 : 2] > >> cp_payload [0x 0 : 0] > >> version Linux version 4.17.11-gentoo > >> (root@ishibashi) (gcc version 7.3.0 (Gentoo Hardened 7.3.0 p1.0)) #1 SMP > >> PREEMPT Sun Jul 29 04:07:16 UTC 2018 > >> Info: total FS sectors = 10485504 (5119 MB) > >> Info: CKPT version = 1f339f > >> > >> ++ > >> > >> | Checkpoint | > >> > >> ++ > >> checkpoint_ver [0x 1f339f : 2044831] > >> user_block_count[0x 127a00 : 1210880] > >> valid_block_count [0x bfc23 : 785443] > >> rsvd_segment_count [0x 30 : 48] > >> overprov_segment_count [0x ac : 172] > >> free_segment_count [0x 30 : 48] > >> alloc_type[CURSEG_HOT_NODE] [0x 0 : 0] > >> alloc_type[CURSEG_WARM_NODE][0x 0 : 0] > >> alloc_type[CURSEG_COLD_NODE][0x 0 : 0] > >> cur_node_segno[0] [0x 4bc : 1212] > >> cur_node_segno[1] [0x 552 : 1362] > >> cur_node_segno[2] [0x 912 : 2322] > >> cur_node_blkoff[0] [0x
Re: [f2fs-dev] Corrupt F2FS partition - fsck is useless
Hi Luke, Do you have tried Sheng Yong's patch? BTW, before recovering root inode, it needs to backup your entire image. On 2018/8/24 23:59, Chao Yu wrote: > On 2018/8/24 22:38, Luke Dashjr wrote: >> Info: Debug level = 1 >> Info: Segments per section = 1 >> Info: Sections per zone = 1 >> Info: sector size = 512 >> Info: total sectors = 12597656 (6151 MB) >> Info: MKFS version >> "Linux version 3.10.49-geda0055-01928-gb21c1b57 (hudsoncm@ilclbld30) (gcc >> version 4.8 (GCC) ) #1 SMP PREEMPT Fri Feb 5 20:48:53 CST 2016" >> Info: FSCK version >> from "Linux version 4.17.11-gentoo (root@ishibashi) (gcc version 7.3.0 >> (Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29 04:07:16 UTC 2018" >> to "Linux version 4.17.11-gentoo (root@ishibashi) (gcc version 7.3.0 >> (Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29 04:07:16 UTC 2018" >> Info: superblock features = 0 : >> Info: superblock encrypt level = 0, salt = >> >> ++ >> | Super block| >> ++ >> magic [0xf2f52010 : 4076150800] >> major_ver [0x 1 : 1] >> volum_name [] >> minor_ver [0x 2 : 2] >> log_sectorsize [0x 9 : 9] >> log_sectors_per_block [0x 3 : 3] >> log_blocksize [0x c : 12] >> log_blocks_per_seg [0x 9 : 9] >> segs_per_sec[0x 1 : 1] >> secs_per_zone [0x 1 : 1] >> checksum_offset [0x 0 : 0] >> block_count [0x 13ffe0 : 1310688] >> section_count [0x 9e9 : 2537] >> segment_count [0x 9fe : 2558] >> segment_count_ckpt [0x 2 : 2] >> segment_count_sit [0x 2 : 2] >> segment_count_nat [0x c : 12] >> segment_count_ssa [0x 5 : 5] >> segment_count_main [0x 9e9 : 2537] >> segment0_blkaddr[0x 200 : 512] >> cp_blkaddr [0x 200 : 512] >> sit_blkaddr [0x 600 : 1536] >> nat_blkaddr [0x a00 : 2560] >> ssa_blkaddr [0x2200 : 8704] >> main_blkaddr[0x2c00 : 11264] >> root_ino[0x 3 : 3] >> node_ino[0x 1 : 1] >> meta_ino[0x 2 : 2] >> cp_payload [0x 0 : 0] >> version Linux version 4.17.11-gentoo (root@ishibashi) >> (gcc version 7.3.0 (Gentoo Hardened 7.3.0 p1.0)) #1 SMP PREEMPT Sun Jul 29 >> 04:07:16 UTC 2018 >> Info: total FS sectors = 10485504 (5119 MB) >> Info: CKPT version = 1f339f >> >> ++ >> | Checkpoint | >> ++ >> checkpoint_ver [0x 1f339f : 2044831] >> user_block_count[0x 127a00 : 1210880] >> valid_block_count [0x bfc23 : 785443] >> rsvd_segment_count [0x 30 : 48] >> overprov_segment_count [0x ac : 172] >> free_segment_count [0x 30 : 48] >> alloc_type[CURSEG_HOT_NODE] [0x 0 : 0] >> alloc_type[CURSEG_WARM_NODE][0x 0 : 0] >> alloc_type[CURSEG_COLD_NODE][0x 0 : 0] >> cur_node_segno[0] [0x 4bc : 1212] >> cur_node_segno[1] [0x 552 : 1362] >> cur_node_segno[2] [0x 912 : 2322] >> cur_node_blkoff[0] [0x bc : 188] >> cur_node_blkoff[1] [0x 79 : 121] >> cur_node_blkoff[2] [0x 169 : 361] >> alloc_type[CURSEG_HOT_DATA] [0x 0 : 0] >> alloc_type[CURSEG_WARM_DATA][0x 0 : 0] >> alloc_type[CURSEG_COLD_DATA][0x 0 : 0] >> cur_data_segno[0] [0x 576 : 1398] >> cur_data_segno[1] [0x 665 : 1637] >> cur_data_segno[2] [0x 66e : 1646] >> cur_data_blkoff[0] [0x 0 : 0] >> cur_data_blkoff[1] [0x 0 : 0] >> cur_data_blkoff[2] [0x 0 : 0] >> ckpt_flags [0x 4 : 4] >> cp_pack_total_block_count [0x 3 : 3] >>
Re: [f2fs-dev] [RFC PATCH 10/10] f2fs: fs-verity support
On 2018/8/28 15:27, Jaegeuk Kim wrote:
> On 08/27, Chao Yu wrote:
>> Hi Eric,
>>
>> On 2018/8/27 1:35, Eric Biggers wrote:
>>> Hi Chao,
>>>
>>> On Sat, Aug 25, 2018 at 01:54:08PM +0800, Chao Yu wrote:
On 2018/8/25 0:16, Eric Biggers wrote:
> From: Eric Biggers
> #ifdef CONFIG_F2FS_CHECK_FS
> #define f2fs_bug_on(sbi, condition) BUG_ON(condition)
> #else
> @@ -146,7 +149,7 @@ struct f2fs_mount_info {
> #define F2FS_FEATURE_QUOTA_INO 0x0080
> #define F2FS_FEATURE_INODE_CRTIME0x0100
> #define F2FS_FEATURE_LOST_FOUND 0x0200
> -#define F2FS_FEATURE_VERITY 0x0400 /* reserved */
> +#define F2FS_FEATURE_VERITY 0x0400
>
> #define F2FS_HAS_FEATURE(sb, mask)
> \
> ((F2FS_SB(sb)->raw_super->feature & cpu_to_le32(mask)) != 0)
> @@ -598,7 +601,7 @@ enum {
> #define FADVISE_ENC_NAME_BIT 0x08
> #define FADVISE_KEEP_SIZE_BIT0x10
> #define FADVISE_HOT_BIT 0x20
> -#define FADVISE_VERITY_BIT 0x40/* reserved */
> +#define FADVISE_VERITY_BIT 0x40
As I suggested before, how about moving f2fs' verity_bit from i_fadvise to
more
generic i_flags field like ext4, so we can a) remaining more bits for those
demands which really need file advise fields. b) using i_flags bits
keeping line
with ext4. Not sure, if user want to know whether the file is verity one,
it
will be easy for f2fs to export the status through FS_IOC_SETFLAGS.
#define EXT4_VERITY_FL 0x0010 /* Verity protected
inode */
#define F2FS_VERITY_FL 0x0010 /* Verity protected
inode */
>>>
>>> I don't like using i_advise much either, but I actually don't see either
>>> location being much better than the other at the moment. The real problem
>>> is an
>>> artificial one: the i_flags in f2fs's on-disk format are being assumed to
>>> use
>>
>> Yeah, but since most copied flags from vfs/ext4 are not actually used in
>> f2fs,
>> also 0x0010 bit is not used now, so we can just define it now directly
>> for
>> verity bit.
>>
>> Cleanup and remapping in ioctl interface for those unused flags, we can do it
>> latter?
>
> No, it was reserved by f2fs-tools,
That's not a problem, since we didn't use that reserved bit in any of images
now, there is no backward compatibility issue.
> and I think this should be aligned to the encryption bit.
Alright, we could, but if so, i_advise will run out of space earlier, after that
we have to add real advice bit into i_inline or i_flags, that would be a little
weird.
For encryption bit, as a common vfs feature flag, in the beginning of encryption
development, it will be better to set it into i_flags, IMO, but now, we have to
keep it as it was.
> Moreover, we guarantee i_flags less strictly from power-cut than i_advise.
IMO, in power-cut scenario, it needs to keep both i_flags and i_advise being
recoverable strictly. Any condition that we can not recover i_flags?
Thanks,
>
>>
>> Thanks,
>>
>>> the same numbering scheme as ext4's on-disk format, which makes it seem that
>>> they have to be in sync, and that all new ext4 flags (say, EA_INODE) also
>>> reserve bits in f2fs and vice versa, when they in fact do not. Instead,
>>> f2fs
>>> should use its own numbering for its i_flags, and it should map them to/from
>>> whatever is needed for common APIs like FS_IOC_{GET,SET}FLAGS and
>>> FS_IOC_FS{GET,SET}XATTR.
>>>
>>> So putting the verity flag in *either* location (i_advise or i_flags) is
>>> just
>>> kicking the can down the road. If I get around to it I will send a patch
>>> that
>>> cleans up the f2fs flags properly...>
>>> Thanks,
>>>
>>> - Eric
>>>
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> ___
>>> Linux-f2fs-devel mailing list
>>> Linux-f2fs-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
>>>
>
> .
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] Corrupt F2FS partition - fsck is useless
On Tuesday 28 August 2018 07:37:35 Jaegeuk Kim wrote: > Are you using dm-crypt under f2fs? No. > v3.10 is too much old, and I quit to backport recent patches as well. > Is there a chance to upgrade the kernel? The 3.10 was the Android/LineageOS phone that couldn't even boot. I'm doing all the data recovery attempts on 4.17.11. Thanks, Luke -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] Corrupt F2FS partition - fsck is useless
On 08/24, Luke Dashjr wrote:
> One of my phones recently decided to corrupt its /data partition. I managed
> to
> copy it to my PC before wiping the phone completely, but efforts to mount or
> otherwise recover data from it have proven futile.
>
> Mounting fails with dmesg showing:
>
> [433918.994391] F2FS-fs (loop0): inconsistent node block, nid:3,
> node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:4050480101642482739,blkaddr:757872690]
> [433918.995566] F2FS-fs (loop0): Failed to read root inode
> [433919.002420] F2FS-fs (loop0): inconsistent node block, nid:3,
> node_footer[nid:808791088,ino:808661560,ofs:92677510,cpver:4050480101642482739,blkaddr:757872690]
> [433919.003598] F2FS-fs (loop0): Failed to read root inode
>
> f2fs-tools v1.11.0's fsck crashes if I tell it to recover lost+found:
>
> (NOTE: fsck output at https://luke.dashjr.org/tmp/code/fsck.f2fs-LF.log.xz )
> #0 0x9911 in memcpy (__len=18446744072369571950,
> __src=0x557d644c, __dest=0x7fffd2d0)
> at /usr/include/bits/string_fortified.h:34
> #1 convert_encrypted_name (
> name=name@entry=0x557d644c
> "3\036\021\004\035=]\035\322\037\f(\212\202&\004\"\021\226\235Ec4
> [\227\266\221R1\332\331!
> \004\226\315\270\216\030\205\020\330\334\334\344\324sg\226\275-\317\352\352\032i\222]\326Ӌ\027^\030\226\005&\006|
> \333b\223\204I\323P\327\r\211K\220\306\321\064\r\271\263\064u\205\322\006g\034u]\003\002)\005!
> \200P\nc\024R\266\070\247\360>\342\333\330\361h$\022\203\265)\306$\264-di\316\331\346,B)\212^\211\321\032\227gdY\206M\023\256\272\346j\322<_\202\214\b!
> \361\241\213\370\336
> {\266\267w\230M&\370\246\345¹\027\271z\375\070u\323r\354\330\061\352
> 9s\346\034\373\367\357'(\270\264\263E\226"..., len=-1339979666,
> new=new@entry=0x7fffd2d0 "3\036\021\004\035=]\035", enc_name= out>)
> at fsck.c:1132
> #2 0x555639d9 in print_inode_info (sbi=0x557817e0 ,
> node=0x557d63f0, name=1) at mount.c:183
> #3 0x5556424f in print_node_info (sbi=,
> node_block=, verbose=)
> at mount.c:277
> #4 0x555620c2 in dump_node (sbi=sbi@entry=0x557817e0 ,
> nid=nid@entry=2875, force=force@entry=1)
> at dump.c:520
> #5 0xf58f in fsck_verify (sbi=) at fsck.c:2568
> #6 0x679b in do_fsck (sbi=0x557817e0 ) at main.c:569
> #7 main (argc=, argv=) at main.c:726
>
> If I tell it NOT to recover lost+found, it completes, but mounting still
> fails:
>
> (NOTE: fsck output https://luke.dashjr.org/tmp/code/fsck.f2fs-NO-LF.log.xz )
> [434361.813196] F2FS-fs (loop0): Found nat_bits in checkpoint
> [434361.825628] F2FS-fs (loop0): Failed to read root inode
> [434361.828461] F2FS-fs (loop0): Found nat_bits in checkpoint
> [434361.840620] F2FS-fs (loop0): Failed to read root inode
>
> Any ideas on how to get at least some data recovered from this?
> (Particularly the encryption key(s) Android stores at /data/misc/vold/*.key)
Are you using dm-crypt under f2fs? Did you decrypt the raw image?
v3.10 is too much old, and I quit to backport recent patches as well.
Is there a chance to upgrade the kernel?
>
> Thanks,
>
> Luke
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [RFC PATCH 10/10] f2fs: fs-verity support
On 08/27, Chao Yu wrote:
> Hi Eric,
>
> On 2018/8/27 1:35, Eric Biggers wrote:
> > Hi Chao,
> >
> > On Sat, Aug 25, 2018 at 01:54:08PM +0800, Chao Yu wrote:
> >> On 2018/8/25 0:16, Eric Biggers wrote:
> >>> From: Eric Biggers
> >>> #ifdef CONFIG_F2FS_CHECK_FS
> >>> #define f2fs_bug_on(sbi, condition) BUG_ON(condition)
> >>> #else
> >>> @@ -146,7 +149,7 @@ struct f2fs_mount_info {
> >>> #define F2FS_FEATURE_QUOTA_INO 0x0080
> >>> #define F2FS_FEATURE_INODE_CRTIME0x0100
> >>> #define F2FS_FEATURE_LOST_FOUND 0x0200
> >>> -#define F2FS_FEATURE_VERITY 0x0400 /* reserved */
> >>> +#define F2FS_FEATURE_VERITY 0x0400
> >>>
> >>> #define F2FS_HAS_FEATURE(sb, mask)
> >>> \
> >>> ((F2FS_SB(sb)->raw_super->feature & cpu_to_le32(mask)) != 0)
> >>> @@ -598,7 +601,7 @@ enum {
> >>> #define FADVISE_ENC_NAME_BIT 0x08
> >>> #define FADVISE_KEEP_SIZE_BIT0x10
> >>> #define FADVISE_HOT_BIT 0x20
> >>> -#define FADVISE_VERITY_BIT 0x40/* reserved */
> >>> +#define FADVISE_VERITY_BIT 0x40
> >>
> >> As I suggested before, how about moving f2fs' verity_bit from i_fadvise to
> >> more
> >> generic i_flags field like ext4, so we can a) remaining more bits for those
> >> demands which really need file advise fields. b) using i_flags bits
> >> keeping line
> >> with ext4. Not sure, if user want to know whether the file is verity one,
> >> it
> >> will be easy for f2fs to export the status through FS_IOC_SETFLAGS.
> >>
> >> #define EXT4_VERITY_FL 0x0010 /* Verity protected
> >> inode */
> >>
> >> #define F2FS_VERITY_FL 0x0010 /* Verity protected
> >> inode */
> >>
> >
> > I don't like using i_advise much either, but I actually don't see either
> > location being much better than the other at the moment. The real problem
> > is an
> > artificial one: the i_flags in f2fs's on-disk format are being assumed to
> > use
>
> Yeah, but since most copied flags from vfs/ext4 are not actually used in f2fs,
> also 0x0010 bit is not used now, so we can just define it now directly for
> verity bit.
>
> Cleanup and remapping in ioctl interface for those unused flags, we can do it
> latter?
No, it was reserved by f2fs-tools, and I think this should be aligned to the
encryption bit. Moreover, we guarantee i_flags less strictly from power-cut than
i_advise.
>
> Thanks,
>
> > the same numbering scheme as ext4's on-disk format, which makes it seem that
> > they have to be in sync, and that all new ext4 flags (say, EA_INODE) also
> > reserve bits in f2fs and vice versa, when they in fact do not. Instead,
> > f2fs
> > should use its own numbering for its i_flags, and it should map them to/from
> > whatever is needed for common APIs like FS_IOC_{GET,SET}FLAGS and
> > FS_IOC_FS{GET,SET}XATTR.
> >
> > So putting the verity flag in *either* location (i_advise or i_flags) is
> > just
> > kicking the can down the road. If I get around to it I will send a patch
> > that
> > cleans up the f2fs flags properly...>
> > Thanks,
> >
> > - Eric
> >
> > --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > Linux-f2fs-devel mailing list
> > Linux-f2fs-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> >
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH 1/2] add configure option --with-root-libdir
On 08/27, Theodore Y. Ts'o wrote: > On Mon, Aug 27, 2018 at 09:57:44AM -0700, Jaegeuk Kim wrote: > > > > Thanks. I've added this and been testing with other patches for next > > release. > > > > Are you planning on doing a new release soon? > > I'm also wondering if you could give some color commentary on how > often you plan on bumping the shared version library numbers? The > reason why I ask is because there is a Debian package which depends on > libf2fs and libf2fs-format, android-libf2fs-utils. It appears to be > part of the Android SDK. I think f2fs-tools is getting much firmer lib APIs, so don't expect frequent major updates on library versions, but was struggling to keep it as much as possible tho. I'm checking the final test results, and thus, planning to release 1.11.1 within a week or so. In this release, I'm seeing that it requires to bump revision like libf2fs-5.1.0, and libf2fs-format-4.1.0. > > I was about to send the Debian maintainer of android-libf2fs-utils > package a ping asking him or her to relink against the latest so > versions --- libf2fs.so.5 and libf2fs-format.so.4. But if the next > release is going to involve a bump of the so versions again, I'll hold > off requesting a rebuild of the package. > > And if the shared libraries are going to be regularly bumped due to > incompatible ABI changes, should I recommend the andorid-f2fs-utils to > statically link instead of link against the f2fs shared libraries? Yeah, I think that'd be much safer to us for a while, as I expect. > > (I haven't bumped the e2fsprogs so versions in over a decade, but > that's because I had carefully designed the interfaces to allow for > backwards compatibility as we added new features to the file system. > I didn't know if that was part of your plan for f2fs-tools) Will keep to try on it. :) Thanks, > > Thanks!! > > - Ted -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
