On Tue, Aug 14, 2018 at 09:32:51AM +0200, Menion wrote:
> Hi
> Well, I think it is worth to give more details on the array.
> the array is built with 5x8TB HDD in an esternal USB3.0 to SATAIII enclosure
> The enclosure is a cheap JMicron based chinese stuff (from Orico).
> There is one USB3.0 link
On Tue, Aug 14, 2018 at 12:46:00PM +0200, David Sterba wrote:
> On Tue, Aug 14, 2018 at 10:47:09AM +0800, Liu Bo wrote:
> > The btrfs_release_path() is just useless as path is only used in error
> > handling.
>
> Where is it duplicated? And I don't think it's useless, while the
> changelog does
On 08/10/2018 12:07 PM, Cerem Cem ASLAN wrote:
> Original question is here: https://superuser.com/questions/1347843
>
> How can we sure that a readonly snapshot is not corrupted due to a disk
> failure?
>
> Is the only way calculating the checksums one on another and store it
> for further
On 08/14/2018 07:09 PM, Andrei Borzenkov wrote:
> 14.08.2018 18:16, Hans van Kranenburg пишет:
>> On 08/14/2018 03:00 PM, Dmitrii Tcvetkov wrote:
Scott E. Blomquist writes:
> Hi All,
>
> [...]
>>>
>>> I'm not a dev, just user.
>>> btrfs-zero-log is for very specific
On 08/14/2018 11:05 AM, ethanwu wrote:
> Item key collision is allowed for some item types, like dir item and
> inode refs, but the overall item size is limited by the leafsize.
>
> item size(ins_len) passed from btrfs_insert_empty_items to
> btrfs_search_slot already contains size of btrfs_item.
On Tue, Aug 14, 2018 at 12:04:05PM -0700, Omar Sandoval wrote:
> On Mon, Jun 18, 2018 at 01:06:16PM +0200, David Sterba wrote:
> > On Fri, Jun 15, 2018 at 05:19:07PM +0100, Filipe Manana wrote:
> > > On Fri, Jun 15, 2018 at 4:54 PM, David Sterba wrote:
> > > > On Mon, Jun 11, 2018 at 07:24:28PM
On Tue, 14 Aug 2018 16:41:11 +0300
Dmitrii Tcvetkov wrote:
> If usebackuproot doesn't help then filesystem is beyond repair and you
> should try to refresh your backups with "btrfs restore" and restore from
> them[1].
>
> [1]
>
On Mon, Jun 18, 2018 at 01:06:16PM +0200, David Sterba wrote:
> On Fri, Jun 15, 2018 at 05:19:07PM +0100, Filipe Manana wrote:
> > On Fri, Jun 15, 2018 at 4:54 PM, David Sterba wrote:
> > > On Mon, Jun 11, 2018 at 07:24:28PM +0100, fdman...@kernel.org wrote:
> > >> From: Filipe Manana
> > >>
From: Omar Sandoval
struct scrub_ctx has an ->is_dev_replace member, so there's no point in
passing around is_dev_replace where sctx is available.
Signed-off-by: Omar Sandoval
---
fs/btrfs/scrub.c | 23 +--
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git
14.08.2018 18:16, Hans van Kranenburg пишет:
> On 08/14/2018 03:00 PM, Dmitrii Tcvetkov wrote:
>>> Scott E. Blomquist writes:
>>> > Hi All,
>>> >
>>> > [...]
>>
>> I'm not a dev, just user.
>> btrfs-zero-log is for very specific case[1], not for transid errors.
>> Transid errors mean that some
On 08/14/2018 03:00 PM, Dmitrii Tcvetkov wrote:
>> Scott E. Blomquist writes:
>> > Hi All,
>> >
>> > [...]
>
> I'm not a dev, just user.
> btrfs-zero-log is for very specific case[1], not for transid errors.
> Transid errors mean that some metadata writes are missing, if
> they prevent you
On 08/12/2018 09:19 PM, Scott E. Blomquist wrote:
>
> Hi All,
>
> Early this morning there was a power glitch that affected our system.
>
> The second enclosure went offline but the file system stayed up for a
> bit before rebooting and recovering the 2 missing arrays sdb1 and
> sdc1.
>
> When
Dmitrii Tcvetkov writes:
> On Tue, 14 Aug 2018 09:31:56 -0400
> "Scott E. Blomquist" wrote:
>
> > Dmitrii Tcvetkov writes:
> > > > Scott E. Blomquist writes:
> > > > > Hi All,
> > > > >
> > > > > Early this morning there was a power glitch that affected our
> > > > >
On 2018/8/14 上午1:37, David Sterba wrote:
> On Mon, Aug 06, 2018 at 02:17:54PM +0800, Qu Wenruo wrote:
>>> - u64 objectid;
>>
>> Off topic crazy idea here.
>>
>> I think it is a little crazy, but it should save a lot of objectid
>> related modification:
>>
>> diff --git a/fs/btrfs/ctree.h
> Scott E. Blomquist writes:
> > Hi All,
> >
> > Early this morning there was a power glitch that affected our
> > system.
> >
> > The second enclosure went offline but the file system stayed up
> > for a bit before rebooting and recovering the 2 missing arrays
> > sdb1 and sdc1.
> >
>
Hi All,
Is there any more info needed here?
I can restore from backup if needed but that will take a bit of time.
Checking around it looks like I could try...
btrfs-zero-log /dev/sda1
Or maybe ..
btrfsck --repair /dev/sda1
I am just not sure here and would prefer to do the right
On Tue, Aug 14, 2018 at 10:46:53AM +0800, Liu Bo wrote:
> As we're going to return, it doesn't make sense to get a new
> write_lock_level from unlock_up.
>
> Signed-off-by: Liu Bo
Reviewed-by: David Sterba
On Tue, Aug 14, 2018 at 10:47:09AM +0800, Liu Bo wrote:
> The btrfs_release_path() is just useless as path is only used in error
> handling.
Where is it duplicated? And I don't think it's useless, while the
changelog does not explain why and it's not obvious from the context. If
the path is
Item key collision is allowed for some item types, like dir item and
inode refs, but the overall item size is limited by the leafsize.
item size(ins_len) passed from btrfs_insert_empty_items to
btrfs_search_slot already contains size of btrfs_item.
When btrfs_search_slot reaches leaf, we'll see
Hi
Well, I think it is worth to give more details on the array.
the array is built with 5x8TB HDD in an esternal USB3.0 to SATAIII enclosure
The enclosure is a cheap JMicron based chinese stuff (from Orico).
There is one USB3.0 link for all the 5 HDD with a SATAIII 3.0Gb
multiplexer behind it. So
20 matches
Mail list logo
