If
you do have scripted snapshots being taken, be sure you have a script
thinning down your snapshot history as well.
I know Ivan P never mentioned qgroups, but just a warning for future
readers: *with qgroups don't let this script delete more than couple
dozen snapshots at once*, then wait f
On 28 May 2017 at 15:56, Duncan <1i5t5.dun...@cox.net> wrote:
> Bill Williamson posted on Sun, 28 May 2017 12:46:00 +1000 as excerpted:
>
>> At first I got the failed to read log tree error, so I ran
>> btrfs-zero-log. It walked back 3-4 transactions but now seems okay.
>>
>> After that fix:
>> -
unsubscribe linux-btrfs
--
-
Ilan Schwarts
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
> Changes since v8:
> + Err out AIO reads with -EINVAL flagged as RWF_NOWAIT
Ugg, why? Reads aren't really treated any different than writes in
the direct I/O code.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
Mo
Despite my previous reviewed-by tag this will need another fix:
xfs_file_iomap_begin needs to return EAGAIN if we don't have the extent
list in memoery already. E.g. something like this:
if ((flags & IOMAP_NOWAIT) && !(ip->i_d.if_flags & XFS_IFEXTENTS)) {
error = -EAGAIN;
On Fri, May 26, 2017 at 04:24:42PM -0400, Martin K. Petersen wrote:
>
> Christoph,
>
> > We will only have sense data if the command exectured and got a SCSI
> > result, so this is pointless.
>
> "executed"
Thanks, fixed.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs"
On Fri, May 26, 2017 at 11:12:31AM +0200, Johannes Thumshirn wrote:
> On 05/26/2017 10:56 AM, Christoph Hellwig wrote:
> > Once we move the block layer to its own status code we'll still want to
> > propagate the bio_iov_iter_get_pages, so restructure __blkdev_direct_IO
> > to take ret into account
On Sun, May 28, 2017 at 6:56 AM, Duncan <1i5t5.dun...@cox.net> wrote:
> [This mail was also posted to gmane.comp.file-systems.btrfs.]
>
> Ivan P posted on Sat, 27 May 2017 22:54:31 +0200 as excerpted:
>
>> Please add me to CC when replying, as I am not
>> subscribed to the mailing list.
>
>
On 05/18/2017 04:07 AM, Darrick J. Wong wrote:
> Document the new GETFSMAP ioctl that returns the physical layout of a
> (disk-based) filesystem.
Thanks, Darrick! Applied (with a few minor edits). (Currently sitting in
a local branch, just in case anyone sends review comments that need
integrating
I just tagged v7 of the python btrfs library:
https://github.com/knorrie/python-btrfs
This is a small release, with some fixes and a few new examples:
python-btrfs v7, May 28 2017
* Also unpack bitmaps when showing the free space tree
* Fixes:
- A few unfortunate typos in __str__ methods
Bill Williamson posted on Sun, 28 May 2017 17:27:47 +1000 as excerpted:
> I'm not asking for a specific endorsement, but should I be considering
> something like the seagate ironwolf or WD red drives?
There's a (well, at least one) guy here that knows much more about that
than I do, and FWIW, my
On Sat, May 27, 2017 at 8:46 PM, Bill Williamson wrote:
> btrfs_async_reclaim_metadata_space
I only found this:
https://www.spinics.net/lists/linux-btrfs/msg62382.html
I can't tell if it's related though.
I'd include the results from btrfs check and btrfs check
--mode=lowmem, using btrfs-progs
At 05/27/2017 02:37 AM, Goffredo Baroncelli wrote:
Hi Qu,
On 2017-05-25 08:21, Qu Wenruo wrote:
And since kernel scrub won't account P/Q corruption, it makes us quite
hard to detect error like kernel screwing up P/Q when scrubbing.
could you elaborate the above sentence: in my test the ker
At 05/27/2017 04:20 AM, Liu Bo wrote:
On Fri, May 26, 2017 at 08:33:16PM +0200, David Sterba wrote:
On Thu, May 25, 2017 at 06:26:31PM -0600, Liu Bo wrote:
Currently scrub only verify checksum of both metadata and data and
couldn't detect an invalid extent_item.
This is a different kind of
On 05/28/2017 04:31 AM, Christoph Hellwig wrote:
> Despite my previous reviewed-by tag this will need another fix:
>
> xfs_file_iomap_begin needs to return EAGAIN if we don't have the extent
> list in memoery already. E.g. something like this:
>
> if ((flags & IOMAP_NOWAIT) && !(ip->i_d.
On 05/28/2017 04:27 AM, Christoph Hellwig wrote:
>> Changes since v8:
>> + Err out AIO reads with -EINVAL flagged as RWF_NOWAIT
>
> Ugg, why? Reads aren't really treated any different than writes in
> the direct I/O code.
This effort focused on writes only.
>From the point of view of the ap
Hello,
I use Arch, the system is entirely on btrfs (on a LUKS partition). I
use snap-sync[0] to sync snapshots to an external drive. When 4.11
came out, snap-sync errors out with the message: ERROR: unable to
resolve -c.
Reverting back to 4.10 fixed the issue. I'm using kernel 4.9.29-lts
and the
On 2017/05/29 12:41, Wael M. Nasreddine wrote:
> Hello,
>
> I use Arch, the system is entirely on btrfs (on a LUKS partition). I
> use snap-sync[0] to sync snapshots to an external drive. When 4.11
> came out, snap-sync errors out with the message: ERROR: unable to
> resolve -c.
>
> Reverting bac
Thank you for pointing that out, I sent a PR to snap-sync
https://github.com/wesbarnett/snap-sync/pull/34
Wael
On Sun, May 28, 2017 at 10:31 PM, Tsutomu Itoh wrote:
> On 2017/05/29 12:41, Wael M. Nasreddine wrote:
>> Hello,
>>
>> I use Arch, the system is entirely on btrfs (on a LUKS partition).
Commit 5f39d397dfbe ("Btrfs: Create extent_buffer interface
for large blocksizes") refactored btrfs_leaf_data function to take
extent_buffer rather than struct btrfs_leaf. However, as it turns out the
parameter being passed is never used. Furthermore this function no longer
returns the leaf data bu
20 matches
Mail list logo
