Are there limitation to the number of named pipes/FIFO's supported by F2FS?

Are there limitation to the number of named pipes/FIFO's supported by F2FS?

[Patrick Doyle]

I have created an f2fs partition on which to build embedded Linux
images (using Yocto/OpenEmbedded/Bitbake).

I just had a build fail where all 20 parallel makes failed with errors
of the form:

OSError: [Errno 5] Input/output error:
'/home/wpd/src/20180904-test/apps_proc/poky/build/tmp-glibc/work/armv7a-vfp-neon-oe-linux-gnueabi/libxml2/2.9.2-r0/temp/fifo.32426'

This build completed successfully in the past, including just this
morning (on this filesystem).

I believe by design (and benchmarks I have researched) that F2FS is
the best approach for SSD based file systems, but this will mark the
second time in less than a week of having put F2FS in operation that I
will have to back up my partition, reformat it with different flags,
and restore it from my backup.   I am now frustrated.

What options would you recommend for a 1TB SSD formatted with F2FS to
be used in an environment that generates Linux system images?  This
environment creates many object files, named pipes, logfiles, etc...

I will start my new backup now, and hope to learn your recommendation
before I am ready to issue my next mkfs command.

--wpd

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: Are there limitation to the number of named pipes/FIFO's supported by F2FS?

[Chao Yu]

On 2018/9/5 0:28, Patrick Doyle wrote:
> I have created an f2fs partition on which to build embedded Linux
> images (using Yocto/OpenEmbedded/Bitbake).
> 
> I just had a build fail where all 20 parallel makes failed with errors
> of the form:
> 
> OSError: [Errno 5] Input/output error:
> '/home/wpd/src/20180904-test/apps_proc/poky/build/tmp-glibc/work/armv7a-vfp-neon-oe-linux-gnueabi/libxml2/2.9.2-r0/temp/fifo.32426'

I don't remember there is any restriction to create named pipes/FIFO. If you can
provider more info about the building failure, maybe I can help to trouble shoot
the issue.

Is there no more free inode space? can you show me filesystem usage by 'stat -f'?

> 
> This build completed successfully in the past, including just this
> morning (on this filesystem).
> 
> I believe by design (and benchmarks I have researched) that F2FS is
> the best approach for SSD based file systems, but this will mark the
> second time in less than a week of having put F2FS in operation that I
> will have to back up my partition, reformat it with different flags,
> and restore it from my backup.   I am now frustrated.
> 
> What options would you recommend for a 1TB SSD formatted with F2FS to
> be used in an environment that generates Linux system images?  This
> environment creates many object files, named pipes, logfiles, etc...
> 
> I will start my new backup now, and hope to learn your recommendation
> before I am ready to issue my next mkfs command.

Do you upgrade both mkfs and kernel? and use mkfs -i to format your ssd device?

Thanks,

> 
> --wpd
> 
> ------------------------------------------------------------------------------
> 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

Re: Are there limitation to the number of named pipes/FIFO's supported by F2FS?

[Jaegeuk Kim]

On 09/05, Chao Yu wrote:
> On 2018/9/5 0:28, Patrick Doyle wrote:
> > I have created an f2fs partition on which to build embedded Linux
> > images (using Yocto/OpenEmbedded/Bitbake).
> > 
> > I just had a build fail where all 20 parallel makes failed with errors
> > of the form:
> > 
> > OSError: [Errno 5] Input/output error:
> > '/home/wpd/src/20180904-test/apps_proc/poky/build/tmp-glibc/work/armv7a-vfp-neon-oe-linux-gnueabi/libxml2/2.9.2-r0/temp/fifo.32426'
> 
> I don't remember there is any restriction to create named pipes/FIFO. If you can
> provider more info about the building failure, maybe I can help to trouble shoot
> the issue.
> 
> Is there no more free inode space? can you show me filesystem usage by 'stat -f'?

Me too. I don't think F2FS does something on pipes. :P

> 
> > 
> > This build completed successfully in the past, including just this
> > morning (on this filesystem).
> > 
> > I believe by design (and benchmarks I have researched) that F2FS is
> > the best approach for SSD based file systems, but this will mark the
> > second time in less than a week of having put F2FS in operation that I
> > will have to back up my partition, reformat it with different flags,
> > and restore it from my backup.   I am now frustrated.
> > 
> > What options would you recommend for a 1TB SSD formatted with F2FS to
> > be used in an environment that generates Linux system images?  This
> > environment creates many object files, named pipes, logfiles, etc...
> > 
> > I will start my new backup now, and hope to learn your recommendation
> > before I am ready to issue my next mkfs command.
> 
> Do you upgrade both mkfs and kernel? and use mkfs -i to format your ssd device?
> 
> Thanks,
> 
> > 
> > --wpd
> > 
> > ------------------------------------------------------------------------------
> > 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

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: Are there limitation to the number of named pipes/FIFO's supported by F2FS?

[Patrick Doyle]

On Wed, Sep 5, 2018 at 12:12 AM Jaegeuk Kim <jaegeuk@kernel.org> wrote:
> On 09/05, Chao Yu wrote:
> > I don't remember there is any restriction to create named pipes/FIFO. If you can
> > provider more info about the building failure, maybe I can help to trouble shoot
> > the issue.
> >
> > Is there no more free inode space? can you show me filesystem usage by 'stat -f'?
>
> Me too. I don't think F2FS does something on pipes. :P
Thank you both for your replies.  As per our previous email exchange,
I had formatted the filesystem with the "-i" option.  There were
plenty of free inodes.  I don't know what could have led to this
issue.  This is a production system for me, so I can't afford to spend
any more time trying to debug this.  I have made 2 changes to my
production system in the past 10 days: I installed a 1TB SSD, and I
formatted it with F2FS.  I have run into show-stopping problems twice
with this new configuration.  In the first case, I learned about the
"-i" option, and I saw that help (after I backed up all of my data and
reformatted).  In the second case, I ran into that bizarre build
failure.  It is possible that the root cause of that failure is bad
hardware (the new SSD).  It is possible that there is a latent bug in
the F2FS implementation that is exposed under heavy load on my 24-core
Xeon system.  It is possible that the second problem was a random
occurrence and I would never see it again.  Regardless, I can't afford
to lose another day tracking this down.  I have reformatted the SSD
with an ext4 FS and I am crossing my fingers that the hardware is not
the root cause.

For your own reference, I am running my production system on Ubuntu
16.04 LTS with a "4.15.0-33-generic" kernel.

--wpd

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: Are there limitation to the number of named pipes/FIFO's supported by F2FS?

[Chao Yu]

On 2018/9/5 21:35, Patrick Doyle wrote:
> On Wed, Sep 5, 2018 at 12:12 AM Jaegeuk Kim <jaegeuk@kernel.org> wrote:
>> On 09/05, Chao Yu wrote:
>>> I don't remember there is any restriction to create named pipes/FIFO. If you can
>>> provider more info about the building failure, maybe I can help to trouble shoot
>>> the issue.
>>>
>>> Is there no more free inode space? can you show me filesystem usage by 'stat -f'?
>>
>> Me too. I don't think F2FS does something on pipes. :P
> Thank you both for your replies.  As per our previous email exchange,
> I had formatted the filesystem with the "-i" option.  There were
> plenty of free inodes.  I don't know what could have led to this
> issue.  This is a production system for me, so I can't afford to spend
> any more time trying to debug this.  I have made 2 changes to my
> production system in the past 10 days: I installed a 1TB SSD, and I

I can understand that.

> formatted it with F2FS.  I have run into show-stopping problems twice
> with this new configuration.  In the first case, I learned about the
> "-i" option, and I saw that help (after I backed up all of my data and
> reformatted).  In the second case, I ran into that bizarre build
> failure.  It is possible that the root cause of that failure is bad
> hardware (the new SSD).  It is possible that there is a latent bug in
> the F2FS implementation that is exposed under heavy load on my 24-core
> Xeon system.  It is possible that the second problem was a random
> occurrence and I would never see it again.  Regardless, I can't afford
> to lose another day tracking this down.  I have reformatted the SSD
> with an ext4 FS and I am crossing my fingers that the hardware is not
> the root cause.

If there is any chance to retry f2fs, let f2fs guys know anything we can help. :)

> 
> For your own reference, I am running my production system on Ubuntu
> 16.04 LTS with a "4.15.0-33-generic" kernel.

Large nat bitmap feature was supported in 4.17, old kernel can not recognize the
feature flag set in mkfs, to make sure, are you porting last f2fs to 4.15?

To Jaegeuk,

Anyway, I think we'd better to add some warn info during formatting with an
upgraded mkfs, so that it can reduce the possiblity of encountering incompatible
issue between new mkfs and old kernel.

Thanks,

> 
> --wpd
> 
> ------------------------------------------------------------------------------
> 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

Re: Are there limitation to the number of named pipes/FIFO's supported by F2FS?

[Patrick Doyle]

On Wed, Sep 5, 2018 at 11:57 AM Chao Yu <chao@kernel.org> wrote:
> If there is any chance to retry f2fs, let f2fs guys know anything we can help. :)
>
Thank you.  If I have the opportunity to do that, I'll let you know.

As far as opportunities are concerned, I could just buy (have my
employer buy) another 1TB SSD, stick it in my system, format it with
F2FS, and see if I run into these sorts of issues again.  All that
would take is time, which is in short supply right now.  But it's not
out of the question.

> >
> > For your own reference, I am running my production system on Ubuntu
> > 16.04 LTS with a "4.15.0-33-generic" kernel.
>
> Large nat bitmap feature was supported in 4.17, old kernel can not recognize the
> feature flag set in mkfs, to make sure, are you porting last f2fs to 4.15?
What is the "Large nat bitmap feature"? (Now you've got me curious).

Would that have been turned on by default with the 1.11.0 version of
mkfs.f2fs I used to gain access to the "-i" option?

>
> To Jaegeuk,
>
> Anyway, I think we'd better to add some warn info during formatting with an
> upgraded mkfs, so that it can reduce the possiblity of encountering incompatible
> issue between new mkfs and old kernel.
I think it would also be worthwhile also to submit patches to the LTS
kernels that would check for an inhibit mounting of F2FS filesystems
that have features unsupported by the kernel.  If that is already in
place, then I shouldn't have been able to mount my f2fs partition if
it had the "Large nat bitmap feature" enabled.

--wpd

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: Are there limitation to the number of named pipes/FIFO's supported by F2FS?

[Jaegeuk Kim]

On 09/05, Patrick Doyle wrote:
> On Wed, Sep 5, 2018 at 11:57 AM Chao Yu <chao@kernel.org> wrote:
> > If there is any chance to retry f2fs, let f2fs guys know anything we can help. :)
> >
> Thank you.  If I have the opportunity to do that, I'll let you know.
> 
> As far as opportunities are concerned, I could just buy (have my
> employer buy) another 1TB SSD, stick it in my system, format it with
> F2FS, and see if I run into these sorts of issues again.  All that
> would take is time, which is in short supply right now.  But it's not
> out of the question.
> 
> > >
> > > For your own reference, I am running my production system on Ubuntu
> > > 16.04 LTS with a "4.15.0-33-generic" kernel.
> >
> > Large nat bitmap feature was supported in 4.17, old kernel can not recognize the
> > feature flag set in mkfs, to make sure, are you porting last f2fs to 4.15?
> What is the "Large nat bitmap feature"? (Now you've got me curious).
> 
> Would that have been turned on by default with the 1.11.0 version of
> mkfs.f2fs I used to gain access to the "-i" option?

I'm quite surprised that there was a case requiring over 10M files. I'm
little bit hesitate to enable this by default due to old kernel issue and
runtime checkpoint overheads given more data writes.

df -i:
         w/o -i       w/ -i
256GB   12812797    12346877
512GB   11800957    24926717
1TB     10017277    48688637

> 
> >
> > To Jaegeuk,
> >
> > Anyway, I think we'd better to add some warn info during formatting with an
> > upgraded mkfs, so that it can reduce the possiblity of encountering incompatible
> > issue between new mkfs and old kernel.
> I think it would also be worthwhile also to submit patches to the LTS
> kernels that would check for an inhibit mounting of F2FS filesystems
> that have features unsupported by the kernel.  If that is already in
> place, then I shouldn't have been able to mount my f2fs partition if
> it had the "Large nat bitmap feature" enabled.

Agreed, but I haven't taken a look at how ubuntu maintains their kernels.
BTW, 4.17-stable is EOL, and next -stable is 4.18.6.

> 
> --wpd

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: Are there limitation to the number of named pipes/FIFO's supported by F2FS?

[Chao Yu]

On 2018/9/6 0:11, Patrick Doyle wrote:
> On Wed, Sep 5, 2018 at 11:57 AM Chao Yu <chao@kernel.org> wrote:
>> If there is any chance to retry f2fs, let f2fs guys know anything we can help. :)
>>
> Thank you.  If I have the opportunity to do that, I'll let you know.
> 
> As far as opportunities are concerned, I could just buy (have my
> employer buy) another 1TB SSD, stick it in my system, format it with
> F2FS, and see if I run into these sorts of issues again.  All that
> would take is time, which is in short supply right now.  But it's not
> out of the question.
> 
>>>
>>> For your own reference, I am running my production system on Ubuntu
>>> 16.04 LTS with a "4.15.0-33-generic" kernel.
>>
>> Large nat bitmap feature was supported in 4.17, old kernel can not recognize the
>> feature flag set in mkfs, to make sure, are you porting last f2fs to 4.15?
> What is the "Large nat bitmap feature"? (Now you've got me curious).
> 
> Would that have been turned on by default with the 1.11.0 version of
> mkfs.f2fs I used to gain access to the "-i" option?
> 
>>
>> To Jaegeuk,
>>
>> Anyway, I think we'd better to add some warn info during formatting with an
>> upgraded mkfs, so that it can reduce the possiblity of encountering incompatible
>> issue between new mkfs and old kernel.
> I think it would also be worthwhile also to submit patches to the LTS
> kernels that would check for an inhibit mounting of F2FS filesystems
> that have features unsupported by the kernel.  If that is already in
> place, then I shouldn't have been able to mount my f2fs partition if
> it had the "Large nat bitmap feature" enabled.

Agreed, but I tracked LTS version in Linux upstream and kernel version in
LTS of ubuntu:

Linux Kernel Release Status
		KERNEL VERSION
mainline:	4.19-rc2
stable:		4.18.6
stable:		4.17.19 [EOL]
longterm:	4.14.68
longterm:	4.9.125
longterm:	4.4.154

Ubuntu Status
LTS VERSION	KERNEL VERSION
16.04		4.13
18.04		4.15

Found that, version number in between formal LTS linux kernel and kernel in
LTS ubunut is not the same...

And not sure that other distribution of linux will use above version
kernel, in order to fix all version, we have to:

1. find all linux distributions LTS kernel version.
2. make and send the right fixing patch to all distribution's kernel
maintainers.

Thoughts?

> 
> --wpd
> 
> ------------------------------------------------------------------------------
> 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

Re: Are there limitation to the number of named pipes/FIFO's supported by F2FS?

[Patrick Doyle]

On Wed, Sep 5, 2018 at 9:51 PM Chao Yu <yuchao0@huawei.com> wrote:
> On 2018/9/6 0:11, Patrick Doyle wrote:
> > I think it would also be worthwhile also to submit patches to the LTS
> > kernels that would check for an inhibit mounting of F2FS filesystems
> > that have features unsupported by the kernel.  If that is already in
> > place, then I shouldn't have been able to mount my f2fs partition if
> > it had the "Large nat bitmap feature" enabled.
>
> Agreed, but I tracked LTS version in Linux upstream and kernel version in
> LTS of ubuntu:
...
> And not sure that other distribution of linux will use above version
> kernel, in order to fix all version, we have to:
>
> 1. find all linux distributions LTS kernel version.
> 2. make and send the right fixing patch to all distribution's kernel
> maintainers.
>
> Thoughts?
My original recommendation was to patch the F2FS kernel driver so that
it refuses to mount filesystems with incompatible, or unknown,
options.  (I freely admit, I don't know what's involved in such a
patch, but I feel that there should be some way to validate the
features and format of the superblock to ensure that they are
compatible with the features expected by that particular version of
the kernel driver.)  I would expect that you should only need to
submit that patch against the kernel LTS versions (listed at
kernel.org) and let the distribution maintainers take it from there.

--wpd

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: Are there limitation to the number of named pipes/FIFO's supported by F2FS?

[Chao Yu]

On 2018/9/6 21:14, Patrick Doyle wrote:
> On Wed, Sep 5, 2018 at 9:51 PM Chao Yu <yuchao0@huawei.com> wrote:
>> On 2018/9/6 0:11, Patrick Doyle wrote:
>>> I think it would also be worthwhile also to submit patches to the LTS
>>> kernels that would check for an inhibit mounting of F2FS filesystems
>>> that have features unsupported by the kernel.  If that is already in
>>> place, then I shouldn't have been able to mount my f2fs partition if
>>> it had the "Large nat bitmap feature" enabled.
>>
>> Agreed, but I tracked LTS version in Linux upstream and kernel version in
>> LTS of ubuntu:
> ...
>> And not sure that other distribution of linux will use above version
>> kernel, in order to fix all version, we have to:
>>
>> 1. find all linux distributions LTS kernel version.
>> 2. make and send the right fixing patch to all distribution's kernel
>> maintainers.
>>
>> Thoughts?
> My original recommendation was to patch the F2FS kernel driver so that
> it refuses to mount filesystems with incompatible, or unknown,
> options.  (I freely admit, I don't know what's involved in such a
> patch, but I feel that there should be some way to validate the
> features and format of the superblock to ensure that they are
> compatible with the features expected by that particular version of
> the kernel driver.)  I would expect that you should only need to
> submit that patch against the kernel LTS versions (listed at

Below info is picked from kernel.org, you can see longterm version is 4.4/4.9/4.14

Linux Kernel Release Status
		KERNEL VERSION
mainline:	4.19-rc2
stable:		4.18.6
stable:		4.17.19 [EOL]
longterm:	4.14.68
longterm:	4.9.125
longterm:	4.4.154

> kernel.org) and let the distribution maintainers take it from there.

But, for example, ubuntu use below version kernel as underlying OS
16.04		4.13
18.04		4.15

So you can see, it's not possible to let distribution maintainers take related
patch from kernel.org, since they are maintaining different LTS kernel version.

Thanks,

> 
> --wpd
> 

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: Are there limitation to the number of named pipes/FIFO's supported by F2FS?

[Chao Yu]

On 2018/9/6 0:11, Patrick Doyle wrote:
> What is the "Large nat bitmap feature"? (Now you've got me curious).

That's the feature backed '-i' option, it can make image support more inode
space.

So if you use this feature in f2fs version lower than 4.17, there should be
problem.

> 
> Would that have been turned on by default with the 1.11.0 version of
> mkfs.f2fs I used to gain access to the "-i" option?

Not sure, in android scenario, I haven't got any report that in 256GB size
cell phone, it runs out of inode space.

To Jaegeuk,

Maybe, we could give a hint (leaving a message) to user to use '-i' option
if partition size is large, e.g. >= 512MB?

Thanks,


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: Are there limitation to the number of named pipes/FIFO's supported by F2FS?

[Chao Yu]

On 2018/9/6 10:03, Chao Yu wrote:
> On 2018/9/6 0:11, Patrick Doyle wrote:
>> What is the "Large nat bitmap feature"? (Now you've got me curious).
> 
> That's the feature backed '-i' option, it can make image support more inode
> space.
> 
> So if you use this feature in f2fs version lower than 4.17, there should be
> problem.
> 
>>
>> Would that have been turned on by default with the 1.11.0 version of
>> mkfs.f2fs I used to gain access to the "-i" option?
> 
> Not sure, in android scenario, I haven't got any report that in 256GB size
> cell phone, it runs out of inode space.
> 
> To Jaegeuk,
> 
> Maybe, we could give a hint (leaving a message) to user to use '-i' option
> if partition size is large, e.g. >= 512MB?

I mean >= 512GB, sorry.

> 
> Thanks,
> 
> 
> ------------------------------------------------------------------------------
> 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

Re: Are there limitation to the number of named pipes/FIFO's supported by F2FS?

[Patrick Doyle]

On Wed, Sep 5, 2018 at 10:04 PM Chao Yu <yuchao0@huawei.com> wrote:
> On 2018/9/6 0:11, Patrick Doyle wrote:
> > What is the "Large nat bitmap feature"? (Now you've got me curious).
>
> That's the feature backed '-i' option, it can make image support more inode
> space.
>
> So if you use this feature in f2fs version lower than 4.17, there should be
> problem.
okay, so that was my problem.  My computer was running a 4.15 kernel
with 4.17 features enabled in my f2fs file system.

Ironically, since 4.15 is not an official "longterm" kernel listed at
kernel.org, I would not have benefited from a patch to the 4.14
kernel, unless somebody at Ubuntu picked up on this.

But I'm not going to try F2FS with the "Large nat bitmap feature"
again until/unless I upgrade to a newer kernel.  Thanks for helping me
figure this out.

--wpd

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

Re: Are there limitation to the number of named pipes/FIFO's supported by F2FS?

[Jaegeuk Kim]

On 09/05, Chao Yu wrote:
> On 2018/9/5 21:35, Patrick Doyle wrote:
> > On Wed, Sep 5, 2018 at 12:12 AM Jaegeuk Kim <jaegeuk@kernel.org> wrote:
> >> On 09/05, Chao Yu wrote:
> >>> I don't remember there is any restriction to create named pipes/FIFO. If you can
> >>> provider more info about the building failure, maybe I can help to trouble shoot
> >>> the issue.
> >>>
> >>> Is there no more free inode space? can you show me filesystem usage by 'stat -f'?
> >>
> >> Me too. I don't think F2FS does something on pipes. :P
> > Thank you both for your replies.  As per our previous email exchange,
> > I had formatted the filesystem with the "-i" option.  There were
> > plenty of free inodes.  I don't know what could have led to this
> > issue.  This is a production system for me, so I can't afford to spend
> > any more time trying to debug this.  I have made 2 changes to my
> > production system in the past 10 days: I installed a 1TB SSD, and I
> 
> I can understand that.
> 
> > formatted it with F2FS.  I have run into show-stopping problems twice
> > with this new configuration.  In the first case, I learned about the
> > "-i" option, and I saw that help (after I backed up all of my data and
> > reformatted).  In the second case, I ran into that bizarre build
> > failure.  It is possible that the root cause of that failure is bad
> > hardware (the new SSD).  It is possible that there is a latent bug in
> > the F2FS implementation that is exposed under heavy load on my 24-core
> > Xeon system.  It is possible that the second problem was a random
> > occurrence and I would never see it again.  Regardless, I can't afford
> > to lose another day tracking this down.  I have reformatted the SSD
> > with an ext4 FS and I am crossing my fingers that the hardware is not
> > the root cause.
> 
> If there is any chance to retry f2fs, let f2fs guys know anything we can help. :)
> 
> > 
> > For your own reference, I am running my production system on Ubuntu
> > 16.04 LTS with a "4.15.0-33-generic" kernel.
> 
> Large nat bitmap feature was supported in 4.17, old kernel can not recognize the
> feature flag set in mkfs, to make sure, are you porting last f2fs to 4.15?
> 
> To Jaegeuk,
> 
> Anyway, I think we'd better to add some warn info during formatting with an
> upgraded mkfs, so that it can reduce the possiblity of encountering incompatible
> issue between new mkfs and old kernel.

Agreed we should warn on users to try this option in old kernel.

> 
> Thanks,
> 
> > 
> > --wpd
> > 
> > ------------------------------------------------------------------------------
> > 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