[f2fs-dev] [PATCH] f2fs: remove unreachable lazytime mount option parsing
The lazytime/nolazytime options are now handled in the VFS, and are
never seen in filesystem parsers, so remove handling of these
options from f2fs.
Note: when lazytime support was added in 6d94c74ab85f it made
lazytime the default in default_options() - as a result, lazytime
cannot be disabled (because Opt_nolazytime is never seen in f2fs
parsing).
If lazytime is desired to be configurable, and default off is OK,
default_options() could be updated to stop setting it by default
and allow mount option control.
Signed-off-by: Eric Sandeen
---
(I came across this when looking at mount API conversion, which still
has not gotten very far, sorry!)
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 1f1b3647a998..12bf7f014fc4 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -151,8 +151,6 @@ enum {
Opt_mode,
Opt_fault_injection,
Opt_fault_type,
- Opt_lazytime,
- Opt_nolazytime,
Opt_quota,
Opt_noquota,
Opt_usrquota,
@@ -229,8 +227,6 @@ static match_table_t f2fs_tokens = {
{Opt_mode, "mode=%s"},
{Opt_fault_injection, "fault_injection=%u"},
{Opt_fault_type, "fault_type=%u"},
- {Opt_lazytime, "lazytime"},
- {Opt_nolazytime, "nolazytime"},
{Opt_quota, "quota"},
{Opt_noquota, "noquota"},
{Opt_usrquota, "usrquota"},
@@ -918,12 +914,6 @@ static int parse_options(struct super_block *sb, char
*options, bool is_remount)
f2fs_info(sbi, "fault_type options not supported");
break;
#endif
- case Opt_lazytime:
- sb->s_flags |= SB_LAZYTIME;
- break;
- case Opt_nolazytime:
- sb->s_flags &= ~SB_LAZYTIME;
- break;
#ifdef CONFIG_QUOTA
case Opt_quota:
case Opt_usrquota:
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH v2 20/23] xfs: add fs-verity support
On 4/4/23 11:27 AM, Darrick J. Wong wrote: > diff --git a/fs/xfs/xfs_super.c b/fs/xfs/xfs_super.c > index d40de32362b1..b6e99ed3b187 100644 > --- a/fs/xfs/xfs_super.c > +++ b/fs/xfs/xfs_super.c > @@ -30,6 +30,7 @@ > #include "xfs_filestream.h" > #include "xfs_quota.h" > #include "xfs_sysfs.h" > +#include "xfs_verity.h" > #include "xfs_ondisk.h" > #include "xfs_rmap_item.h" > #include "xfs_refcount_item.h" > @@ -1489,6 +1490,9 @@ xfs_fs_fill_super( > sb->s_quota_types = QTYPE_MASK_USR | QTYPE_MASK_GRP | QTYPE_MASK_PRJ; > #endif > sb->s_op = _super_operations; > +#ifdef CONFIG_FS_VERITY > + sb->s_vop = _verity_ops; > +#endif > Hi Andrey - it might be nicer to just do: fsverity_set_ops(sb, _verity_ops); here and use the (existing) helper to avoid the #ifdef. (the #ifdef is handled by the helper) (ext4 & btrfs could use this too ...) Thanks! -Eric ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH] doc: cgroup: add f2fs and xfs to supported list for writeback
On 7/1/20 3:32 AM, Christoph Hellwig wrote: > On Tue, Jun 30, 2020 at 08:59:34AM -0500, Eric Sandeen wrote: >> On 6/30/20 12:42 AM, Christoph Hellwig wrote: >>> On Mon, Jun 29, 2020 at 02:08:09PM -0500, Eric Sandeen wrote: >>>> f2fs and xfs have both added support for cgroup writeback: >>>> >>>> 578c647 f2fs: implement cgroup writeback support >>>> adfb5fb xfs: implement cgroup aware writeback >>>> >>>> so add them to the supported list in the docs. >>>> >>>> Signed-off-by: Eric Sandeen >>>> --- >>>> >>>> TBH I wonder about the wisdom of having this detail in >>>> the doc, as it apparently gets missed quite often ... >>> >>> I'd rather remove the list of file systems. It has no chance of >>> staying uptodate. >> >> Is there any way for a user to know whether a filesytem does or doesn't >> support it, in practice? > > git-grep SB_I_CGROUPWB Sure, but that's not quite what I meant by "a user" :) So I'll take that as a no. Thanks, -Eric ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] [PATCH] doc: cgroup: add f2fs and xfs to supported list for writeback
On 6/30/20 12:42 AM, Christoph Hellwig wrote: > On Mon, Jun 29, 2020 at 02:08:09PM -0500, Eric Sandeen wrote: >> f2fs and xfs have both added support for cgroup writeback: >> >> 578c647 f2fs: implement cgroup writeback support >> adfb5fb xfs: implement cgroup aware writeback >> >> so add them to the supported list in the docs. >> >> Signed-off-by: Eric Sandeen >> --- >> >> TBH I wonder about the wisdom of having this detail in >> the doc, as it apparently gets missed quite often ... > > I'd rather remove the list of file systems. It has no chance of > staying uptodate. Is there any way for a user to know whether a filesytem does or doesn't support it, in practice? Thanks, -Eric ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
[f2fs-dev] [PATCH] doc: cgroup: add f2fs and xfs to supported list for writeback
f2fs and xfs have both added support for cgroup writeback: 578c647 f2fs: implement cgroup writeback support adfb5fb xfs: implement cgroup aware writeback so add them to the supported list in the docs. Signed-off-by: Eric Sandeen --- TBH I wonder about the wisdom of having this detail in the doc, as it apparently gets missed quite often ... diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index ce3e05e..4f82afa 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -1684,9 +1684,9 @@ per-cgroup dirty memory states are examined and the more restrictive of the two is enforced. cgroup writeback requires explicit support from the underlying -filesystem. Currently, cgroup writeback is implemented on ext2, ext4 -and btrfs. On other filesystems, all writeback IOs are attributed to -the root cgroup. +filesystem. Currently, cgroup writeback is implemented on ext2, ext4, +btrfs, f2fs, and xfs. On other filesystems, all writeback IOs are +attributed to the root cgroup. There are inherent differences in memory and writeback management which affects how cgroup ownership is tracked. Memory is tracked per ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
Re: [f2fs-dev] xfstests: generic/342 run failed in f2fs
On 12/28/17 1:09 AM, Dave Chinner wrote:
...
> There's a whole lot more detail in the kernel commit 2be63d5ce929
> ("Btrfs: fix file loss on log replay after renaming a file and
> fsync") but my point is that we considered this a btrfs filesystem
> bug and so changing the test defeats it's purpose as a regression
> test for the btrfs bug.
>
> So IMO the test should not be changed. And I think we should be
> consistent and consider this f2fs failure as a f2fs bug that needs
> fixing to bring it's behaviour in line with xfs, ext4, and btrfs.
>
> Remember this when quoting POSIX about fsync behaviour: Posix is a
> terrible standard when it comes to data integrity. We go way, way
> beyond what POSIX specifies as a valid fsync implementation (i.e.
> posix allows "do nothing and return success" as a conformant
> implementation). Ext4, XFS and btrfs all have strictly ordered
> metadata crash recovery semantics and all of the crash recovery
> tests expect this behaviour from the filesytem being tested. The
> underlying intention is that by encoding it into these tests, all
> widely used and future linux filesystems meet or exceed this crash
> integrity requirement.
>
> IOWs, changing the test is the wrong thing to do on many levels
>
> Cheers,
>
> Dave.
>
Thanks for digging into the btrfs commit which changed the behavior
tested by this testcase, I had meant to do that.
Yeah, that's all fair, for sure. But this shouldn't be implicit in the
testcase; it should explicitly document that it is testing a de-facto
new standard adhered to by several filesystems, what that standard is,
etc, and not leave it to the reader. ;)
If a filesystem explicitly chooses not to adhere to that standard they
/could/ opt out of the test.
It's makes a lot of sense for linux filesystems to behave in consistent
ways, but if we're going to start enforcing that through xfstests we
need to be very clear about it, IMHO.
-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] xfstests: generic/342 run failed in f2fs
On 12/24/17 10:30 PM, Chen Rong wrote: > > > On 2017年12月25日 13:56, Eric Sandeen wrote: >> On 12/24/17 9:28 PM, Chen Rong wrote: >>> Hi, everyone: >>> >>> the issue as below: >> First we need to look - what does the test do? >> >> # Test that if we rename a file, create a new file that has the old name of >> the >> # other file and is a child of the same parent directory, fsync the new >> inode, >> # power fail and mount the filesystem, we do not lose the first file and that >> # file has the name it was renamed to. >> >> Ok, so it is a test of fsync'd file renames/creation over simulated device >> failure, and wants to be sure that all files and file contents are as >> expected if data integrity syscalls were made before the device failure. >> >>> # ./check generic/342 >>> FSTYP -- f2fs >>> PLATFORM -- Linux/x86_64 node01 4.15.0-rc4 >>> MKFS_OPTIONS -- /dev/sde1 >>> MOUNT_OPTIONS -- -o acl,user_xattr /dev/sde1 /tmp/test1 >>> >>> generic/342 - output mismatch (see >>> /home/ubuntu/git/xfstests-dev/results//generic/342.out.bad) >>> --- tests/generic/342.out 2017-12-13 13:47:20.14400 -0500 >>> +++ /home/ubuntu/git/xfstests-dev/results//generic/342.out.bad >>> 2017-12-25 11:13:12.92800 -0500 >>> @@ -8,8 +8,7 @@ >>> 48c940ba3b8671d3d6ea74e4ccad8ca3 SCRATCH_MNT/a/bar >>> Directory a/ contents after log replay: >>> SCRATCH_MNT/a: >>> -bar >> the test created foo, fsynced it, then renamed it to bar and created a >> /new/ file also named foo, then fsynced the new file foo. >> >> Despite that 2nd fsync, the renamed file "bar" is not present in >> your case. >> >> However, don't we really need to fsync the directory after >> the rename and recreation to ensure persistence? >> >> iows: does this patch make the test pass on f2fs? It does >> for me, and I think it's the only valid way to run the test: > the patch works for me. but btrfs could pass the test without it, why so > different? Filesystems are free to do /more/ than the minimum required by posix - see ext4_sync_parent for example. Or xfs_finish_rename, for synchronous mounts: * If this is a synchronous mount, make sure that the rename transaction * goes to disk before returning to the user. */ if (tp->t_mountp->m_flags & (XFS_MOUNT_WSYNC|XFS_MOUNT_DIRSYNC)) xfs_trans_set_sync(tp); so behavior can be fs-dependent, or mount option dependent, etc. But to be portable, if an app wants directory changes to be persistent before proceeding, it must fsync the directory after making changes. I don't know about f2fs's design intent, whether it guarantees more than posix requires, but to guarantee that this test works on any posix fs, I think that directory fsync is needed. -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] [PATCH 1/2] generic/065: f2fs serves 64KB size with zero data
On 2/26/15 7:23 PM, Jaegeuk Kim wrote: The f2fs provides 64KB size with 0 data after fsync was done to directory file. Cc: Filipe Manana fdman...@suse.com Signed-off-by: Jaegeuk Kim jaeg...@kernel.org --- tests/generic/065 | 4 1 file changed, 4 insertions(+) diff --git a/tests/generic/065 b/tests/generic/065 index b5a296d..3d2b437 100755 --- a/tests/generic/065 +++ b/tests/generic/065 @@ -139,6 +139,10 @@ ext3) # a 64Kb file, with all bytes having the value 0xff [ $hello_digest == ecb99e6ffea7be1e5419350f725da86b ] digest_ok=yes ;; +f2fs) + # a 64Kb file, with all bytes having the value 0 + [ $hello_digest == fcd6bcb56c1689fcef28b57c22475bad ] digest_ok=yes + ;; whoa... I will admit to having poorly reviewed this test. Given that this file was never fsynced, I don't think the test should be looking at file contents *at all* I'll do an ex post facto review, I think, and really, I think all of the above should just be removed from the test. Without fsync, we don't know what's in the file. (ext3 could be mounted with writeback mode, for example). -Eric *) # an empty file [ $hello_digest == d41d8cd98f00b204e9800998ecf8427e ] digest_ok=yes -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ ___ 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] src/godown: support f2fs triggering specific ioctl
On 1/8/15 12:31 PM, Jaegeuk Kim wrote:
This patch triggers the F2FS-related ioctl for godown.
hohum, wouldn't it be a whole lot easier to just re-use the XFS ioctl
number in f2fs? Then you wouldn't have to duplicate all this code.
If you really want your own unique ioctl number, what about
just doing statfs on the target, and if f_type returns F2FS_SUPER_MAGIC,
swictch the ioctl nr to F2FS_IOC_GOINGDOWN.
Then if not F2FS_SUPER_MAGIC, leave the ioctl nr at XFS_IOC_GOINGDOWN, and
if it fails, it fails (other filesystems might support the original nr.)
And then you can probably just add f2fs to the existing testcase,
and move it to tests/shared?
-Eric
Signed-off-by: Jaegeuk Kim jaeg...@kernel.org
---
src/godown.c | 88
1 file changed, 65 insertions(+), 23 deletions(-)
diff --git a/src/godown.c b/src/godown.c
index b140a41..b44790b 100644
--- a/src/godown.c
+++ b/src/godown.c
@@ -19,33 +19,82 @@
#include syslog.h
#include global.h
+#define F2FS_IOCTL_MAGIC 0xf5
+#define F2FS_IOC_GOINGDOWN _IO(F2FS_IOCTL_MAGIC, 6)
+
+enum ftypes {
+ XFS_FS,
+ F2FS_FS,
+};
+
static char *xprogname;
+static char *mnt_dir;
+static int verbose_opt = 0;
+static int flushlog_opt = 0;
+static enum ftypes fs = XFS_FS;
static void
usage(void)
{
- fprintf(stderr, usage: %s [-f] [-v] mnt-dir\n, xprogname);
+ fprintf(stderr, usage: %s [-f] [-v] [-s 0/1] mnt-dir\n, xprogname);
+}
+
+static int
+xfs_goingdown(int fd)
+{
+ int flag;
+
+ flag = (flushlog_opt ? XFS_FSOP_GOING_FLAGS_LOGFLUSH
+ : XFS_FSOP_GOING_FLAGS_NOLOGFLUSH);
+ if (verbose_opt) {
+ printf(Calling XFS_IOC_GOINGDOWN\n);
+ }
+
+ syslog(LOG_WARNING, xfstests-induced forced shutdown of %s:\n,
+ mnt_dir);
+ if ((xfsctl(mnt_dir, fd, XFS_IOC_GOINGDOWN, flag)) == -1) {
+ fprintf(stderr, %s: error on xfsctl(GOINGDOWN) of \%s\:
%s\n,
+ xprogname, mnt_dir, strerror(errno));
+ return 1;
+ }
+ return 0;
+}
+
+static int
+f2fs_goingdown(int fd)
+{
+ if (verbose_opt) {
+ printf(Calling F2FS_IOC_GOINGDOWN\n);
+ }
+ syslog(LOG_WARNING, xfstests-induced forced shutdown of %s:\n,
+ mnt_dir);
+ if ((ioctl(fd, F2FS_IOC_GOINGDOWN)) == -1) {
+ fprintf(stderr, %s: error on ioctl(GOINGDOWN) of \%s\: %s\n,
+ xprogname, mnt_dir, strerror(errno));
+ return 1;
+ }
+ return 0;
+
}
int
main(int argc, char *argv[])
{
- int c;
- int flag;
- int flushlog_opt = 0;
- int verbose_opt = 0;
+ int c, fd;
struct stat st;
- char *mnt_dir;
- int fd;
+ int ret = 0;
xprogname = argv[0];
- while ((c = getopt(argc, argv, fv)) != -1) {
+ while ((c = getopt(argc, argv, fs:v)) != -1) {
switch (c) {
case 'f':
flushlog_opt = 1;
break;
+ case 's':
+ fs = atoi(optarg);
+ break;
case 'v':
verbose_opt = 1;
break;
@@ -94,10 +143,6 @@ main(int argc, char *argv[])
}
#endif
-
- flag = (flushlog_opt ? XFS_FSOP_GOING_FLAGS_LOGFLUSH
- : XFS_FSOP_GOING_FLAGS_NOLOGFLUSH);
-
if (verbose_opt) {
printf(Opening \%s\\n, mnt_dir);
}
@@ -107,18 +152,15 @@ main(int argc, char *argv[])
return 1;
}
- if (verbose_opt) {
- printf(Calling XFS_IOC_GOINGDOWN\n);
+ switch (fs) {
+ case XFS_FS:
+ ret = xfs_goingdown(fd);
+ break;
+ case F2FS_FS:
+ ret = f2fs_goingdown(fd);
+ break;
}
- syslog(LOG_WARNING, xfstests-induced forced shutdown of %s:\n,
- mnt_dir);
- if ((xfsctl(mnt_dir, fd, XFS_IOC_GOINGDOWN, flag)) == -1) {
- fprintf(stderr, %s: error on xfsctl(GOINGDOWN) of \%s\:
%s\n,
- xprogname, mnt_dir, strerror(errno));
- return 1;
- }
-
close(fd);
- return 0;
+ return ret;
}
--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
Re: [f2fs-dev] [PATCH 2/6] f2fs: support goingdown for fs shutdown
On 1/8/15 2:18 PM, Jaegeuk Kim wrote: On Thu, Jan 08, 2015 at 01:54:20PM -0600, Eric Sandeen wrote: On 1/8/15 12:10 PM, Jaegeuk Kim wrote: This patch add an ioctl to shutdown f2fs, which stops all the further block writes after this point. would it make sense to just re-use the xfs ioctl nr, if the semantics are the same? The semantics are not same for now. In order to reuse xfs ioctl, it needs to support options for flushing logs. the xfs iotl has 3 behaviors optional: #define XFS_FSOP_GOING_FLAGS_DEFAULT0x0 /* going down */ #define XFS_FSOP_GOING_FLAGS_LOGFLUSH 0x1 /* flush log but not data */ #define XFS_FSOP_GOING_FLAGS_NOLOGFLUSH 0x2 /* don't flush log nor data */ if f2fs currently supports a subset, you could just -EOPNOTSUPP on the others. If the semantics are completely different, maybe it shouldn't share the name at all. ;) Just a thought... -Eric Thanks, That way any test using it will just work on f2fs... -Eric -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
