From: Darrick J. Wong
Clean up the calling convention since we're editing the fsxattr struct
anyway.
Signed-off-by: Darrick J. Wong
---
fs/xfs/xfs_ioctl.c | 32 ++--
1 file changed, 14 insertions(+), 18 deletions(-)
diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_i
From: Darrick J. Wong
Move the extent size hint checks that aren't xfs-specific to the vfs.
Signed-off-by: Darrick J. Wong
---
fs/inode.c | 18 +
fs/xfs/xfs_ioctl.c | 70 ++--
2 files changed, 47 insertions(+), 41 deletion
From: Darrick J. Wong
The chattr manpage has this to say about immutable files:
"A file with the 'i' attribute cannot be modified: it cannot be deleted
or renamed, no link can be created to this file, most of the file's
metadata can not be modified, and the file can not be opened in write
mode."
From: Darrick J. Wong
The chattr manpage has this to say about immutable files:
"A file with the 'i' attribute cannot be modified: it cannot be deleted
or renamed, no link can be created to this file, most of the file's
metadata can not be modified, and the file can not be opened in write
mode."
From: Darrick J. Wong
Refactor the SETFLAGS implementation to use the SETXATTR code directly
instead of partially constructing a struct fsxattr and calling bits and
pieces of the setxattr code. This reduces code size and becomes
necessary in the next patch to maintain the behavior of allowing
us
From: Darrick J. Wong
Create a generic checking function for the incoming FS_IOC_SETFLAGS flag
values so that we can standardize the implementations that follow ext4's
flag values.
Signed-off-by: Darrick J. Wong
---
fs/btrfs/ioctl.c| 13 +
fs/efivarfs/file.c | 18 +
Hi all,
The chattr(1) manpage has this to say about the immutable bit that
system administrators can set on files:
"A file with the 'i' attribute cannot be modified: it cannot be deleted
or renamed, no link can be created to this file, most of the file's
metadata can not be modified, and the file
From: Darrick J. Wong
When we're using FS_IOC_SETFLAGS to set the immutable flag on a file, we
need to ensure that userspace can't continue to write the file after the
file becomes immutable. To make that happen, we have to flush all the
dirty pagecache pages to disk to ensure that we can fail a
From: Darrick J. Wong
When we're using FS_IOC_FSSETXATTR to set the immutable flag on a file,
we need to ensure that userspace can't continue to write the file after
the file becomes immutable. To make that happen, we have to flush all
the dirty pagecache pages to disk to ensure that we can fail
On Monday, June 10, 2019 11:39:53 PM EDT Andrei Borzenkov wrote:
> 11.06.2019 4:10, Chris Murphy пишет:
> > It's most useful if you show exact commands because actually it's not
> > always obvious to everyone what the logic should be and the error
> > handling doesn't always stop a user from doing
On Mon, Jun 10, 2019 at 04:41:54PM -0400, Theodore Ts'o wrote:
> On Mon, Jun 10, 2019 at 09:09:34AM -0700, Darrick J. Wong wrote:
> > > I was planning on only taking 8/8 through the ext4 tree. I also added
> > > a patch which filtered writes, truncates, and page_mkwrites (but not
> > > mmap) for i
On Monday, June 10, 2019 9:10:17 PM EDT Chris Murphy wrote:
> On Mon, Jun 10, 2019 at 6:03 PM Eric Mesa wrote:
> > When I did the btrfs send / receive for SSDHome it took 2.5 days to send
> > ~500GiB over a 1GBps cable to the 3GBps drive in the server. It also had
> > the error:
> > ERROR: failed
11.06.2019 4:10, Chris Murphy пишет:
>
> It's most useful if you show exact commands because actually it's not
> always obvious to everyone what the logic should be and the error
> handling doesn't always stop a user from doing something that doesn't
> make a lot of sense. We need to know the name
On Mon, Jun 11, 2019 at 04:41:54PM -0400, Theodore Ts'o wrote:
> On Mon, Jun 10, 2019 at 09:09:34AM -0700, Darrick J. Wong wrote:
> > > I was planning on only taking 8/8 through the ext4 tree. I also added
> > > a patch which filtered writes, truncates, and page_mkwrites (but not
> > > mmap) for i
On 2019-06-10 7:56 p.m., Eric Mesa wrote:
> ERROR: link ermesa/.mozilla/firefox/n35gu0fb.default/bookmarkbackups/
> bookmarks-2019-06-09_679_I1bs5PtgsPwtyXvcvcRdSg==.jsonlz4 -> ermesa/.mozilla/
> firefox/n35gu0fb.default/bookmarkbackups/
> bookmarks-2019-06-08_679_I1bs5PtgsPwtyXvcvcRdSg==.jsonlz4
On Mon, Jun 10, 2019 at 6:03 PM Eric Mesa wrote:
> When I did the btrfs send / receive for SSDHome it took 2.5 days to send
> ~500GiB over a 1GBps cable to the 3GBps drive in the server. It also had the
> error:
> ERROR: failed to clone extents to ermesa/.cache/krunner/
> bookmarkrunnerfirefoxfav
First of all, as per instruction on the wiki for the mailing list, you can
find everything asked for from the "What information to provide when asking a
support question" section is at the end of my email. Look for a series of ##
to know when this info is located.
So, the setup is that I've got
On Thu, Jun 07, 2018 at 06:52:13PM +0200, David Sterba wrote:
> On Thu, Jun 07, 2018 at 06:28:02PM +0200, Dmitry Vyukov wrote:
> > > Normally the GFP_NOFS allocations do not fail so I think the fuzzer
> > > environment is tuned to allow that, which is fine for coverage but does
> > > not happen in
On Mon, Jun 10, 2019 at 09:09:34AM -0700, Darrick J. Wong wrote:
> > I was planning on only taking 8/8 through the ext4 tree. I also added
> > a patch which filtered writes, truncates, and page_mkwrites (but not
> > mmap) for immutable files at the ext4 level.
>
> *Oh*. I saw your reply attached
On Mon, Jun 10, 2019 at 09:14:17AM -0400, Theodore Ts'o wrote:
> On Sun, Jun 09, 2019 at 09:41:44PM -0700, Darrick J. Wong wrote:
> > On Sun, Jun 09, 2019 at 09:51:45PM -0400, Theodore Ts'o wrote:
> > > On Wed, Apr 17, 2019 at 12:04:33PM -0700, Darrick J. Wong wrote:
> >
> > > Shouldn't this check
On Mon, Jun 10, 2019 at 04:02:36PM +0200, David Sterba wrote:
> On Mon, Jun 10, 2019 at 12:42:26PM +, Hugo Mills wrote:
> >Hi, David,
> >
> > On Mon, Jun 10, 2019 at 02:29:40PM +0200, David Sterba wrote:
> > > this patchset brings the RAID1 with 3 and 4 copies as a separate
> > > feature a
On Mon, Jun 10, 2019 at 12:42:26PM +, Hugo Mills wrote:
>Hi, David,
>
> On Mon, Jun 10, 2019 at 02:29:40PM +0200, David Sterba wrote:
> > this patchset brings the RAID1 with 3 and 4 copies as a separate
> > feature as outlined in V1
> > (https://lore.kernel.org/linux-btrfs/cover.1531503452
On Sun, Jun 09, 2019 at 09:41:44PM -0700, Darrick J. Wong wrote:
> On Sun, Jun 09, 2019 at 09:51:45PM -0400, Theodore Ts'o wrote:
> > On Wed, Apr 17, 2019 at 12:04:33PM -0700, Darrick J. Wong wrote:
>
> > Shouldn't this check be moved before the modification of vmf->flags?
> > It looks like do_page
Hi, David,
On Mon, Jun 10, 2019 at 02:29:40PM +0200, David Sterba wrote:
> this patchset brings the RAID1 with 3 and 4 copies as a separate
> feature as outlined in V1
> (https://lore.kernel.org/linux-btrfs/cover.1531503452.git.dste...@suse.com/).
[...]
> Compatibility
> ~
>
> The
$ ./mkfs.btrfs -m raid1c4 -d raid1c3 /dev/sd[abcd]
Label: (null)
UUID: f1f988ab-6750-4bc2-957b-98a4ebe98631
Node size: 16384
Sector size:4096
Filesystem size:8.00GiB
Block group profiles:
Data: RAID1C3 273.06MiB
Metadata:
The RAID1 with more copies will be identified as 'raid1c34'.
Signed-off-by: David Sterba
---
fs/btrfs/ctree.h | 3 ++-
fs/btrfs/sysfs.c | 2 ++
fs/btrfs/volumes.c | 9 +
include/uapi/linux/btrfs.h | 1 +
4 files changed, 14 insertions(+), 1 deletion(-)
diff -
Add new block group profile to store 4 copies in a simliar way that
current RAID1 does. The profile name is temporary and may change in the
future.
Signed-off-by: David Sterba
---
fs/btrfs/ctree.h| 4 ++--
fs/btrfs/super.c| 3 +++
fs/btrfs/volumes.c
The real meaning of that constant is not clear from the context due to
the target device inclusion.
Signed-off-by: David Sterba
---
fs/btrfs/ctree.h | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index fb7435533478..31198499f17
Preparatory patch for additional RAID1 profiles with more copies. The
mask will contain 3-copy and 4-copy, most of the checks for plain RAID1
work the same for the other profiles.
Signed-off-by: David Sterba
---
fs/btrfs/extent-tree.c | 8
fs/btrfs/scrub.c| 2 +-
Add new block group profile to store 3 copies in a simliar way that
current RAID1 does. The profile name is temporary and may change in the
future.
Signed-off-by: David Sterba
---
fs/btrfs/ctree.h| 4 ++--
fs/btrfs/extent-tree.c | 2 ++
fs/btrfs/super.c
Hi,
this patchset brings the RAID1 with 3 and 4 copies as a separate
feature as outlined in V1
(https://lore.kernel.org/linux-btrfs/cover.1531503452.git.dste...@suse.com/).
This should help a bit in the raid56 situation, where the write hole
hurts most for metadata, without a block group profile
We don't need to enumerate the profiles, use the mask for consistency.
Signed-off-by: David Sterba
---
fs/btrfs/extent-tree.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 3413f78a3032..556deb03c215 100644
--- a
32 matches
Mail list logo
