On Thu, Oct 18, 2018 at 6:04 AM Jean-Denis Girard wrote:
>
> Hi list,
>
> My goal is to duplicate some SD cards, to prepare 50 similar Raspberry Pi.
>
> First, I made a tar of my master SD card (unmounted). Then I made a
> script, which creates 2 partitions (50 MB for boot, 14 GB for /),
> creates
On Wed, 17 Oct 2018 17:57:25 -0700 Qu Wenruo
wrote
...
> > But after chrooting to update-initramfs and cataloging resulting image
> > content, usb_storage and uas were present under /lib/modules/xxx already,
> > and failing systems still just busybox without a real rootfs rather
On Thu, Oct 18, 2018 at 05:54:29AM +0100, Al Viro wrote:
> On Wed, Oct 17, 2018 at 09:47:18PM -0700, Darrick J. Wong wrote:
>
> > > > +#define REMAP_FILE_DEDUP (1 << 0)
> > > > +
> > > > +/*
> > > > + * These flags should be taken care of by the implementation (possibly
> > > > usin
On Wed, Oct 17, 2018 at 09:47:18PM -0700, Darrick J. Wong wrote:
> > > +#define REMAP_FILE_DEDUP (1 << 0)
> > > +
> > > +/*
> > > + * These flags should be taken care of by the implementation (possibly
> > > using
> > > + * vfs helpers) but can be ignored by the implementation.
> > > + */
On Thu, Oct 18, 2018 at 01:48:26AM +0100, Al Viro wrote:
> On Wed, Oct 17, 2018 at 03:45:17PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong
> >
> > Combine the clone_file_range and dedupe_file_range operations into a
> > single remap_file_range file operation dispatch since they're
> >
On Thu, Oct 18, 2018 at 01:41:56AM +0100, Al Viro wrote:
> On Wed, Oct 17, 2018 at 03:44:43PM -0700, Darrick J. Wong wrote:
> > +static int generic_access_check_limits(struct file *file, loff_t pos,
> > + loff_t *count)
> > +{
> > + struct inode *inode = file->f_m
Hi list,
My goal is to duplicate some SD cards, to prepare 50 similar Raspberry Pi.
First, I made a tar of my master SD card (unmounted). Then I made a
script, which creates 2 partitions (50 MB for boot, 14 GB for /),
creates the file-systems (vfat and btrfs, default options), mounts the
two part
On 2018/10/18 上午12:38, Tony Prokott wrote:
> Good day. My technical trouble seems to be beyond the scope of active helpers
> on debian's irc support channel. Reasonable supposition that it's quite
> particular to the development stage of btrfs infrastructure on 4.17.xxx
> backport kernels and
On Wed, Oct 17, 2018 at 03:45:17PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong
>
> Combine the clone_file_range and dedupe_file_range operations into a
> single remap_file_range file operation dispatch since they're
> fundamentally the same operation. The differences between the two ca
On 2018/10/17 下午11:50, Michael Post wrote:
> Hello Qu,
> Hello Hugo,
>
> i got this result when i try to recover the chunk tree.
>
> # btrfs check /dev/mapper/vg0-virtualbox
> bytenr mismatch, want=1263835381760, have=0
> ERROR: cannot open file system
This means some essential trees get corru
On Wed, Oct 17, 2018 at 03:44:43PM -0700, Darrick J. Wong wrote:
> +static int generic_access_check_limits(struct file *file, loff_t pos,
> +loff_t *count)
> +{
> + struct inode *inode = file->f_mapping->host;
> +
> + /* Don't exceed the LFS limits. */
>
From: Darrick J. Wong
Prior to remapping blocks, it is necessary to remove pages from the
destination file's page cache. Unfortunately, the truncation is not
aggressive enough -- if page size > block size, we'll end up zeroing
subpage blocks instead of removing them. So, round the start offset
From: Darrick J. Wong
Since the remap prep function can update the length of the remap
request, we can change this function to return the usual return status
instead of the odd behavior it has now.
Signed-off-by: Darrick J. Wong
Reviewed-by: Christoph Hellwig
---
fs/ocfs2/refcounttree.c |
From: Darrick J. Wong
There are no callers of vfs_dedupe_file_range_compare, so we might as
well make it a static helper and remove the export.
Signed-off-by: Darrick J. Wong
Reviewed-by: Amir Goldstein
Reviewed-by: Christoph Hellwig
---
fs/read_write.c| 187 +---
From: Darrick J. Wong
Now that we've moved the partial EOF block checks to the VFS helpers, we
can remove the redundant functionality from XFS.
Signed-off-by: Darrick J. Wong
Reviewed-by: Dave Chinner
---
fs/xfs/xfs_reflink.c | 19 ---
1 file changed, 19 deletions(-)
diff
From: Darrick J. Wong
Now that the vfs remap helper dirties the inode [cm]time for us, xfs no
longer needs to do that on its own.
Signed-off-by: Darrick J. Wong
---
fs/xfs/xfs_reflink.c |7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/fs/xfs/xfs_reflink.c b/fs/xfs/
From: Darrick J. Wong
Since xfs_file_remap_range is a thin wrapper, move the contents of
xfs_reflink_remap_range into the shell. This cuts down on the vfs
calls being made from internal xfs code.
Signed-off-by: Darrick J. Wong
---
fs/xfs/xfs_file.c| 65 ++
From: Darrick J. Wong
Back when the XFS reflink code only supported clone_file_range, we were
only able to return zero or negative error codes to userspace. However,
now that copy_file_range (which returns bytes copied) can use XFS'
clone_file_range, we have the opportunity to return partial res
From: Darrick J. Wong
Move the offset <-> blocks unit conversions into
xfs_reflink_remap_blocks to make the call site less ugly.
Signed-off-by: Darrick J. Wong
---
fs/xfs/xfs_reflink.c | 37 ++---
1 file changed, 18 insertions(+), 19 deletions(-)
diff --git
From: Darrick J. Wong
Add a "xfs_tprintk" macro so that developers can use trace_printk to
print out arbitrary debugging information with the XFS device name
attached to the trace output.
Signed-off-by: Darrick J. Wong
---
fs/xfs/xfs_error.h |6 ++
1 file changed, 6 insertions(+)
dif
From: Darrick J. Wong
Change the ocfs2 remap code to allow for returning partial results.
Signed-off-by: Darrick J. Wong
---
fs/ocfs2/file.c |7 +
fs/ocfs2/refcounttree.c | 72 +--
fs/ocfs2/refcounttree.h | 12
3 files ch
From: Darrick J. Wong
Since ocfs2_remap_file_range is a thin shell around
ocfs2_remap_remap_range, move everything from the latter into the
former.
Signed-off-by: Darrick J. Wong
---
fs/ocfs2/file.c | 68 +++-
fs/ocfs2/refcounttree.c | 113 +++
From: Darrick J. Wong
Plumb in a remap flag that enables the filesystem remap handler to
shorten remapping requests for callers that can handle it. Now
copy_file_range can report partial success (in case we run up against
alignment problems, resource limits, etc.).
We also enable CAN_SHORTEN fo
From: Darrick J. Wong
When cloning blocks into another file, truncate the page cache before we
start remapping blocks so that concurrent reads wait for us to finish.
Signed-off-by: Darrick J. Wong
---
fs/ocfs2/refcounttree.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
From: Darrick J. Wong
Prior to remapping blocks, it is necessary to remove pages from the
destination file's page cache. Unfortunately, the truncation is not
aggressive enough -- if page size > block size, we'll end up zeroing
subpage blocks instead of removing them. So, round the start offset
From: Darrick J. Wong
Change the remap_file_range functions to take a number of bytes to
operate upon and return the number of bytes they operated on. This is a
requirement for allowing fs implementations to return short clone/dedupe
results to the user, which will enable us to obey resource lim
From: Darrick J. Wong
Extend generic_remap_file_range_prep to handle inode metadata updates
when remapping into a file. If the operation can possibly alter the
file contents, we must update the ctime and mtime and remove security
privileges, just like we do for regular file writes.
Signed-off-b
From: Darrick J. Wong
Plumb a remap_flags argument through the vfs_dedupe_file_range_one
functions so that dedupe can take advantage of it.
Signed-off-by: Darrick J. Wong
Reviewed-by: Amir Goldstein
---
fs/overlayfs/file.c |3 ++-
fs/read_write.c |9 ++---
include/linux/fs.h
From: Darrick J. Wong
Plumb a remap_flags argument through the {do,vfs}_clone_file_range
functions so that clone can take advantage of it.
Signed-off-by: Darrick J. Wong
Reviewed-by: Amir Goldstein
---
fs/ioctl.c |2 +-
fs/nfsd/vfs.c |2 +-
fs/overlayfs/copy_up.c
From: Darrick J. Wong
Pass the same remap flags to generic_remap_checks for consistency.
Signed-off-by: Darrick J. Wong
Reviewed-by: Amir Goldstein
Reviewed-by: Christoph Hellwig
---
fs/read_write.c|2 +-
include/linux/fs.h |2 +-
mm/filemap.c |4 ++--
3 files changed,
From: Darrick J. Wong
Plumb the remap flags through the filesystem from the vfs function
dispatcher all the way to the prep function to prepare for behavior
changes in subsequent patches.
Signed-off-by: Darrick J. Wong
Reviewed-by: Amir Goldstein
Reviewed-by: Christoph Hellwig
---
fs/ocfs2/f
From: Darrick J. Wong
Combine the clone_file_range and dedupe_file_range operations into a
single remap_file_range file operation dispatch since they're
fundamentally the same operation. The differences between the two can
be made in the prep functions.
Signed-off-by: Darrick J. Wong
Reviewed-
From: Darrick J. Wong
Don't bother calling the filesystem for a zero-length dedupe request;
we can return zero and exit.
Signed-off-by: Darrick J. Wong
Reviewed-by: Christoph Hellwig
Reviewed-by: Amir Goldstein
---
fs/read_write.c |5 +
1 file changed, 5 insertions(+)
diff --git a/
From: Darrick J. Wong
A deduplication data corruption is exposed in XFS and btrfs. It is
caused by extending the block match range to include the partial EOF
block, but then allowing unknown data beyond EOF to be considered a
"match" to data in the destination file because the comparison is only
From: Darrick J. Wong
The vfs_clone_file_prep is a generic function to be called by filesystem
implementations only. Rename the prefix to generic_ and make it more
clear that it applies to remap operations, not just clones.
Signed-off-by: Darrick J. Wong
Reviewed-by: Amir Goldstein
---
fs/oc
From: Darrick J. Wong
Since we use clone_verify_area for both clone and dedupe range checks,
rename the function to make it clear that it's for both.
Signed-off-by: Darrick J. Wong
Reviewed-by: Amir Goldstein
---
fs/read_write.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(
From: Darrick J. Wong
File range remapping, if allowed to run past the destination file's EOF,
is an optimization on a regular file write. Regular file writes that
extend the file length are subject to various constraints which are not
checked by range cloning.
This is a correctness problem bec
From: Darrick J. Wong
If a remap caller asks us to remap to the source file's EOF and the
source file length leaves us with a zero byte request, exit early.
Signed-off-by: Darrick J. Wong
Reviewed-by: Christoph Hellwig
---
fs/read_write.c |2 ++
1 file changed, 2 insertions(+)
diff --gi
From: Darrick J. Wong
Move the file range checks from vfs_clone_file_prep into a separate
generic_remap_checks function so that all the checks are collected in a
central location. This forms the basis for adding more checks from
generic_write_checks that will make cloning's input checking more
c
Hi all,
Dave, Eric, and I have been chasing a stale data exposure bug in the XFS
reflink implementation, and tracked it down to reflink forgetting to do
some of the file-extending activities that must happen for regular
writes.
We then started auditing the clone, dedupe, and copyfile code and
rea
From: Darrick J. Wong
vfs_clone_file_prep_inodes cannot return 0 if it is asked to remap from
a zero byte file because that's what btrfs does.
Signed-off-by: Darrick J. Wong
Reviewed-by: Christoph Hellwig
---
fs/read_write.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/fs/read_wr
On Mon, Oct 15, 2018 at 02:25:38PM +0800, Lu Fengqi wrote:
> The find_ref_head shouldn't return the first entry even if no exact match
> is found. So move the hidden behavior to higher level.
>
> Besides, remove the useless local variables in the btrfs_select_ref_head.
>
> Signed-off-by: Lu Fengq
Good day. My technical trouble seems to be beyond the scope of active helpers
on debian's irc support channel. Reasonable supposition that it's quite
particular to the development stage of btrfs infrastructure on 4.17.xxx
backport kernels and userland tools available on debian 9.5 stretch as wel
On Wed, Oct 17, 2018 at 01:40:02AM -0700, Christoph Hellwig wrote:
> > @@ -1415,11 +1419,17 @@ xfs_reflink_remap_range(
> >
> > trace_xfs_reflink_remap_range(src, pos_in, len, dest, pos_out);
> >
> > + if (len == 0) {
> > + ret = 0;
> > + goto out_unlock;
> > + }
> >
On Wed, Oct 17, 2018 at 01:36:52AM -0700, Christoph Hellwig wrote:
> > /* Update inode timestamps and remove security privileges when remapping.
> > */
> > @@ -2023,7 +2034,8 @@ loff_t vfs_dedupe_file_range_one(struct file
> > *src_file, loff_t src_pos,
> > {
> > loff_t ret;
> >
> > - W
Hello Qu,
Hello Hugo,
i got this result when i try to recover the chunk tree.
# btrfs check /dev/mapper/vg0-virtualbox
bytenr mismatch, want=1263835381760, have=0
ERROR: cannot open file system
# btrfs rescue chunk-recover -y /dev/mapper/vg0-virtualbox
Scanning: DONE in dev0
open with broken c
On Mon, Oct 15, 2018 at 09:51:00AM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> When using the NO_HOLES feature and logging a regular file, we were
> expecting that if we find an inline extent, that either its size in ram
> (uncompressed and unenconded) matches the size of the file
On Wed, Oct 17, 2018 at 02:56:02PM +0800, Qu Wenruo wrote:
> Can be fetched from github:
> https://github.com/adam900710/linux/tree/refactor_find_free_extent
>
> Which is based on v4.19-rc1.
>
> extent-tree.c::find_free_extent() could be one of the most
> ill-structured functions, it has at least
On Wed, Oct 17, 2018 at 02:56:04PM +0800, Qu Wenruo wrote:
> --- a/fs/btrfs/extent-tree.c
> +++ b/fs/btrfs/extent-tree.c
> @@ -7261,6 +7261,115 @@ struct find_free_extent_ctl {
> u64 found_offset;
> };
>
> +
No extra newlines.
> +/*
> + * Helper function for find_free_extent().
> + *
> +
On Fri, Oct 12, 2018 at 10:03:55AM +0100, fdman...@kernel.org wrote:
> From: Filipe Manana
>
> When writing out a block group free space cache we can end deadlocking
> with ourseves on an extent buffer lock resulting in a warning like the
> following:
>
> [245043.379979] WARNING: CPU: 4 PID: 2
On Thu, Oct 11, 2018 at 08:51:03PM +0200, Goffredo Baroncelli wrote:
> From: Goffredo Baroncelli
>
> Add the RAID 6 recovery, in order to use a RAID 6 filesystem even if some
> disks (up to two) are missing. This code use the md RAID 6 code already
> present in grub.
>
> Signed-off-by: Goffredo Ba
On Thu, Oct 11, 2018 at 08:51:01PM +0200, Goffredo Baroncelli wrote:
> From: Goffredo Baroncelli
>
> Add support for recovery for a RAID 5 btrfs profile. In addition
> it is added some code as preparatory work for RAID 6 recovery code.
>
> Signed-off-by: Goffredo Baroncelli
> ---
> grub-core/fs/
On Wed, Oct 17, 2018 at 11:13:59AM +0200, Christophe JAILLET wrote:
> We return 0 unconditionally in most of the error handling paths of
> 'btrfs_mark_extent_written()'.
> However, 'ret' is set to some error codes in several error handling paths.
>
> Return 'ret' instead to propagate the error cod
On Thu, Oct 11, 2018 at 08:50:58PM +0200, Goffredo Baroncelli wrote:
> From: Goffredo Baroncelli
>
> Currently read from missing device triggers rescan. However, it is never
> recorded that the device is missing. So, each read of a missing device
> triggers rescan again and again. This behavior ca
On Thu, Oct 11, 2018 at 08:50:55PM +0200, Goffredo Baroncelli wrote:
> From: Goffredo Baroncelli
>
> Signed-off-by: Goffredo Baroncelli
> Signed-off-by: Daniel Kiper
One nit pick below...
Otherwise you can add Reviewed-by: Daniel Kiper
> ---
> grub-core/fs/btrfs.c | 73 +
On 2018-10-16 16:27, Chris Murphy wrote:
On Tue, Oct 16, 2018 at 9:42 AM, Austin S. Hemmelgarn
wrote:
On 2018-10-16 11:30, Anton Shepelev wrote:
Hello, all
What may be the reason of a CRC mismatch on a BTRFS file in
a virutal machine:
csum failed ino 175524 off 1876295680 csum 45176055
On Fri, Oct 12, 2018 at 03:32:56PM -0400, Josef Bacik wrote:
> This could result in a really bad case where we do something like
>
> evict
> evict_refill_and_join
> btrfs_commit_transaction
> btrfs_run_delayed_iputs
> evict
> evict_refill_and_join
> btrfs_
On Fri, Oct 12, 2018 at 03:32:33PM -0400, Josef Bacik wrote:
> From: Josef Bacik
>
> We can't use entry->bytes if our entry is a bitmap entry, we need to use
> entry->max_extent_size in that case. Fix up all the logic to make this
> consistent.
>
> Signed-off-by: Josef Bacik
> ---
> fs/btrfs/
I am Peter Wong director of operations, Hong Kong and Shanghai Banking
Corporation Limited Hong Kong. I have a very confidential business
proposition involving transfer of $18.350.000.00 that will be of great
benefit for both of us. Reply for more details as regards this
transaction
Best Regards
P
On Wed, Oct 17, 2018 at 10:29 AM Libor Klepáč wrote:
>
> Hello,
> i have new 32GB SSD in my intel nuc, installed debian9 on it, using btrfs as
> a rootfs.
> Then i created subvolumes /system and /home and moved system there.
>
> System was installed using kernel 4.9.x and filesystem created using
On 2018/10/17 下午5:27, Michael Post wrote:
> Hello Hugo,
>
> thanks for your information.
>
> I have an 1 TB BTRFS-Partition which suddenly could not be mounted.
>
> I tried the following commands
>
>
> host@:btrfs check -b /dev/mapper/vg0-virtualbox
>
This is the important part.
Please
Hello Hugo,
thanks for your information.
I have an 1 TB BTRFS-Partition which suddenly could not be mounted.
I tried the following commands
host@:btrfs check -b /dev/mapper/vg0-virtualbox
Errors found in extent allocation tree or chunk allocation
bytenr mismatch, want=1263661723648, have=
Hi, Michael,
On Wed, Oct 17, 2018 at 09:58:31AM +0200, Michael Post wrote:
> Hello together,
>
> i need a BTRFS-Expert for remote support.
>
> Anyone who can assist me?
This is generally the wrong approach to take in open-source
circles. Instead, if you describe your problem here on this
[I accdientally replied to Chris instead of the mailing list]
Chris Murphy:
>Is there still that O_DIRECT related "bug" (or more of a
>limitation) if the guest is using cache=none on the block
>device?
I know nothing about it.
>Anton what virtual machine tech are you using? qemu/kvm
>managed wi
We return 0 unconditionally in most of the error handling paths of
'btrfs_mark_extent_written()'.
However, 'ret' is set to some error codes in several error handling paths.
Return 'ret' instead to propagate the error code.
Fixes: 9c8e63db1de9 ("Btrfs: kill BUG_ON()'s in btrfs_mark_extent_written"
On Mon, Oct 15, 2018 at 08:21:02PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong
>
> Now that we've moved the partial EOF block checks to the VFS helpers, we
> can remove the redundant functionality from XFS.
>
> Signed-off-by: Darrick J. Wong
> Reviewed-by: Dave Chinner
Looks fine,
> @@ -1415,11 +1419,17 @@ xfs_reflink_remap_range(
>
> trace_xfs_reflink_remap_range(src, pos_in, len, dest, pos_out);
>
> + if (len == 0) {
> + ret = 0;
> + goto out_unlock;
> + }
> +
As pointed out last time this check is superflous, right above we have
On Mon, Oct 15, 2018 at 08:20:48PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong
>
> Prior to remapping blocks, it is necessary to remove pages from the
> destination file's page cache. Unfortunately, the truncation is not
> aggressive enough -- if page size > block size, we'll end up ze
On Mon, Oct 15, 2018 at 08:20:14PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong
>
> Since the remap prep function can update the length of the remap
> request, we can change this function to return the usual return status
> instead of the odd behavior it has now.
>
> Signed-off-by: Darr
> /* Update inode timestamps and remove security privileges when remapping. */
> @@ -2023,7 +2034,8 @@ loff_t vfs_dedupe_file_range_one(struct file *src_file,
> loff_t src_pos,
> {
> loff_t ret;
>
> - WARN_ON_ONCE(remap_flags & ~(REMAP_FILE_DEDUP));
> + WARN_ON_ONCE(remap_flags &
On Mon, Oct 15, 2018 at 08:19:26PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong
>
> Create a new VFS helper to handle inode metadata updates when remapping
> into a file. If the operation can possibly alter the file contents, we
> must update the ctime and mtime and remove security priv
On Mon, Oct 15, 2018 at 08:11:19PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong
>
> Pass the same remap flags to generic_remap_checks for consistency.
>
> Signed-off-by: Darrick J. Wong
> Reviewed-by: Amir Goldstein
Looks good,
Reviewed-by: Christoph Hellwig
On Mon, Oct 15, 2018 at 08:11:12PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong
>
> Plumb the remap flags through the filesystem from the vfs function
> dispatcher all the way to the prep function to prepare for behavior
> changes in subsequent patches.
Looks good,
Reviewed-by: Christo
> +/* All valid REMAP_FILE flags */
> +#define REMAP_FILE_VALID_FLAGS (REMAP_FILE_DEDUP)
It looks like this still isn't used after the whole series.
With it removed:
Reviewed-by: Christoph Hellwig
Hello,
i have new 32GB SSD in my intel nuc, installed debian9 on it, using btrfs as a
rootfs.
Then i created subvolumes /system and /home and moved system there.
System was installed using kernel 4.9.x and filesystem created using
btrfs-progs 4.7.x
Details follow:
main filesystem
# btrfs filesy
On Mon, Oct 15, 2018 at 08:10:23PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong
>
> If a remap caller asks us to remap to the source file's EOF and the
> source file has zero bytes, exit early.
>
> Signed-off-by: Darrick J. Wong
Looks good,
Reviewed-by: Christoph Hellwig
Hello together,
i need a BTRFS-Expert for remote support.
Anyone who can assist me via Skype or teamviewer?
I will pay for it.
Please let me know,
Michael Post
Hello together,
i need a BTRFS-Expert for remote support.
Anyone who can assist me?
Please let me know,
Michael Post
78 matches
Mail list logo
