From: Chao Yu <chao@kernel.org>
To: Patrick Doyle <wpdster@gmail.com>, jaegeuk@kernel.org
Cc: linux-f2fs-devel@lists.sourceforge.net
Subject: Re: Are there limitation to the number of named pipes/FIFO's supported by F2FS?
Date: Wed, 5 Sep 2018 23:57:45 +0800 [thread overview]
Message-ID: <8ffaeb7c-972e-f1d2-277d-0b02407f58ff@kernel.org> (raw)
In-Reply-To: <CAF_dkJCyf69FEM+RberH4NV2FZqa3b0tN+zQROkm3F1a_vFspw@mail.gmail.com>
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
next prev parent reply other threads:[~2018-09-05 15:57 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-04 16:28 Are there limitation to the number of named pipes/FIFO's supported by F2FS? Patrick Doyle
2018-09-05 1:55 ` Chao Yu
2018-09-05 4:12 ` Jaegeuk Kim
2018-09-05 13:35 ` Patrick Doyle
2018-09-05 15:57 ` Chao Yu [this message]
2018-09-05 16:11 ` Patrick Doyle
2018-09-05 17:30 ` Jaegeuk Kim
2018-09-06 1:51 ` Chao Yu
2018-09-06 13:14 ` Patrick Doyle
2018-09-06 13:29 ` Chao Yu
2018-09-06 2:03 ` Chao Yu
2018-09-06 12:44 ` Chao Yu
2018-09-06 13:31 ` Patrick Doyle
2018-09-05 17:16 ` Jaegeuk Kim
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=8ffaeb7c-972e-f1d2-277d-0b02407f58ff@kernel.org \
--to=chao@kernel.org \
--cc=jaegeuk@kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=wpdster@gmail.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).