On Fri, Feb 19, 2021 at 10:01 PM Qu Wenruo wrote:
> On 2021/2/20 下午12:28, Erik Jensen wrote:
> > [...]
> > Brainstorming some ideas, is compacting the address space something
> > that could be done offline? E.g., maybe some two-pass process: first
> > something balance
On Sat, Feb 20, 2021 at 3:23 PM Matthew Wilcox wrote:
> On Sat, Feb 20, 2021 at 03:02:26PM -0800, Erik Jensen wrote:
> > Out of curiosity, would it be at all feasible to use 64-bits for the page
> > offset *without* changing XArray, perhaps by indexing by the lower 32-bits,
>
On 2/18/21 5:39 AM, Matthew Wilcox wrote:
On Thu, Feb 18, 2021 at 08:42:14PM +0800, Qu Wenruo wrote:
[...]
BTW, what would be the extra cost by converting page::index to u64?
I know tons of printk() would cause warning, but most 64bit systems
should not be affected anyway.
No effect for 64-bit
On Fri, Feb 19, 2021 at 7:16 PM Qu Wenruo wrote:
> On 2021/2/20 上午10:47, Erik Jensen wrote:
> > Given that it sounds like the issue is the metadata address space, and
> > given that I surely don't actually have 16TiB of metadata on a 24TiB
> > file system (indeed, Metad
On Thu, Feb 18, 2021 at 12:59 AM Qu Wenruo wrote:
> Just send a mail to the fs-devel mail list, titled "page->index
> limitation on 32bit system?".
>
> I guess your experience as a real world user would definitely bring more
> weight to the discussion.
>
> Thanks,
> Qu
Given that it sounds like t
On 2/19/21 8:12 AM, Theodore Ts'o wrote:
On Fri, Feb 19, 2021 at 08:37:30AM +0800, Qu Wenruo wrote:
So it means the 32bit archs are already 2nd tier targets for at least
upstream linux kernel?
At least as far as btrfs is concerned, anyway
Or would it be possible to make it an option to m
On 2/18/21 4:15 AM, Matthew Wilcox wrote:
On Thu, Feb 18, 2021 at 04:54:46PM +0800, Qu Wenruo wrote:
Recently we got a strange bug report that, one 32bit systems like armv6
or non-64bit x86, certain large btrfs can't be mounted.
It turns out that, since page->index is just unsigned long, and o
On Thu, Feb 18, 2021 at 12:38 AM Qu Wenruo wrote:
> We got it!
>
> The eb->start mismatch with page_offset(), this means something is wrong
> with page->index.
>
> Considering page->index is just unsigned long thus when we initialize
> page->index using a real u64, we truncated some high bits.
>
>
On Wed, Feb 17, 2021 at 11:24 PM Qu Wenruo wrote:
> On 2021/2/18 下午2:59, Erik Jensen wrote:
> > On Wed, Feb 17, 2021 at 10:09 PM Qu Wenruo wrote:
> >> On 2021/2/18 下午1:49, Erik Jensen wrote:
> >>> On Wed, Feb 17, 2021 at 9:24 PM Qu Wenruo wrote:
> >>>
On Wed, Feb 17, 2021 at 10:59 PM Erik Jensen wrote:
> On Wed, Feb 17, 2021 at 10:09 PM Qu Wenruo wrote:
> > On 2021/2/18 下午1:49, Erik Jensen wrote:
> > > On Wed, Feb 17, 2021 at 9:24 PM Qu Wenruo wrote:
> > >> Got it now.
> > >>
> > >&
On Wed, Feb 17, 2021 at 10:09 PM Qu Wenruo wrote:
> On 2021/2/18 下午1:49, Erik Jensen wrote:
> > On Wed, Feb 17, 2021 at 9:24 PM Qu Wenruo wrote:
> >> Got it now.
> >>
> >> [ 295.249182] read_extent_buffer_pages: eb->start=26207780683776 mirror=0
> &g
On Wed, Feb 17, 2021 at 9:24 PM Qu Wenruo wrote:
> Got it now.
>
> [ 295.249182] read_extent_buffer_pages: eb->start=26207780683776 mirror=0
> [ 295.249188] __btrfs_map_block: logical=8615594639360 chunk
> start=8614760677376 len=4294967296 type=0x81
> [ 295.249189] __btrfs_map_block: stripe[0]
On Wed, Feb 17, 2021 at 5:24 PM Qu Wenruo wrote:
> On 2021/2/11 上午7:47, Qu Wenruo wrote:
> > On 2021/2/11 上午6:17, Erik Jensen wrote:
> >> On Tue, Feb 9, 2021 at 9:47 PM Qu Wenruo wrote:
> > [...]
> >>>
> >>> Unfortunately I didn't get much use
On Tue, Feb 9, 2021 at 9:47 PM Qu Wenruo wrote:
> On 2021/2/6 上午9:57, Erik Jensen wrote:
> > On Wed, Feb 3, 2021 at 10:16 PM Erik Jensen wrote:
> >> On Sun, Jan 31, 2021 at 9:50 PM Su Yue wrote:
> >>> On Mon 01 Feb 2021 at 10:35, Qu Wenruo
> >>> wrot
On Wed, Feb 3, 2021 at 10:16 PM Erik Jensen wrote:
> On Sun, Jan 31, 2021 at 9:50 PM Su Yue wrote:
> > On Mon 01 Feb 2021 at 10:35, Qu Wenruo
> > wrote:
> > > On 2021/1/29 下午2:39, Erik Jensen wrote:
> > >> On Mon, Jan 25, 2021 at 8:54 PM Erik Jensen
> &g
On Sun, Jan 31, 2021 at 9:50 PM Su Yue wrote:
> On Mon 01 Feb 2021 at 10:35, Qu Wenruo
> wrote:
> > On 2021/1/29 下午2:39, Erik Jensen wrote:
> >> On Mon, Jan 25, 2021 at 8:54 PM Erik Jensen
> >> wrote:
> >>> On Wed, Jan 20, 2021 at 1:08 AM Erik Jensen
&g
On Mon, Jan 25, 2021 at 8:54 PM Erik Jensen wrote:
> On Wed, Jan 20, 2021 at 1:08 AM Erik Jensen wrote:
> > On Wed, Jan 20, 2021 at 12:31 AM Qu Wenruo wrote:
> > > On 2021/1/20 下午4:21, Qu Wenruo wrote:
> > > > On 2021/1/19 下午5:28, Erik Jensen wrote:
> > >
On Wed, Jan 20, 2021 at 1:08 AM Erik Jensen wrote:
>
> On Wed, Jan 20, 2021 at 12:31 AM Qu Wenruo wrote:
> > On 2021/1/20 下午4:21, Qu Wenruo wrote:
> > > On 2021/1/19 下午5:28, Erik Jensen wrote:
> > >> On Mon, Jan 18, 2021 at 9:22 PM Erik Jensen
> > >>
On Mon, Jan 18, 2021 at 9:22 PM Erik Jensen wrote:
>
> On Mon, Jan 18, 2021 at 4:12 AM Erik Jensen wrote:
> >
> > The offending system is indeed ARMv7 (specifically a Marvell ARMADA®
> > 388), but I believe the Broadcom BCM2835 in my Raspberry Pi is
> > actua
On Mon, Jan 18, 2021 at 4:12 AM Erik Jensen wrote:
>
> The offending system is indeed ARMv7 (specifically a Marvell ARMADA®
> 388), but I believe the Broadcom BCM2835 in my Raspberry Pi is
> actually ARMv6 (with hardware float support).
Using NBD, I have verified that I receive th
The offending system is indeed ARMv7 (specifically a Marvell ARMADA®
388), but I believe the Broadcom BCM2835 in my Raspberry Pi is
actually ARMv6 (with hardware float support).
On Mon, Jan 18, 2021 at 4:01 AM Qu Wenruo wrote:
>
>
>
> On 2021/1/18 下午7:55, Erik Jensen wrote:
> &
On Mon, Jan 18, 2021 at 3:07 AM Qu Wenruo wrote:
> On 2021/1/18 下午6:33, Erik Jensen wrote:
> > I ended up having other priorities occupying my time since 2019, and the
> > "solution" of exporting the individual drives on my NAS using NBD and
> > mounting them o
19 at 1:15 AM Qu Wenruo wrote:
>
>
>
> On 2019/6/28 下午4:00, Erik Jensen wrote:
> >> So it's either the block layer reading some wrong from the disk or btrfs
> >> layer doesn't do correct endian convert.
> >
> > My ARM board is running in little endian mode
I'm still seeing this. Anything else I can try?
On Wed, May 22, 2019 at 9:02 AM Erik Jensen wrote:
>
> On Tue, May 21, 2019 at 2:18 AM Hugo Mills wrote:
> >
> > On Tue, May 21, 2019 at 01:34:42AM -0700, Erik Jensen wrote:
> > > I have a 5-drive btrfs filesystem
On Tue, May 21, 2019 at 2:18 AM Hugo Mills wrote:
>
> On Tue, May 21, 2019 at 01:34:42AM -0700, Erik Jensen wrote:
> > I have a 5-drive btrfs filesystem. (raid-5 data, dup metadata). I can
> > mount it fine on my x86_64 system, and running `btrfs check` there
> > reveals
Whoops, sorry. I actually meant RAID1. Data is RAID5, Metadata and
System are RAID1.
On Tue, May 21, 2019 at 1:56 AM Patrik Lundquist
wrote:
>
> On Tue, 21 May 2019 at 10:35, Erik Jensen wrote:
> >
> > I have a 5-drive btrfs filesystem. (raid-5 data, dup metadata).
>
>
I have a 5-drive btrfs filesystem. (raid-5 data, dup metadata). I can
mount it fine on my x86_64 system, and running `btrfs check` there
reveals no errors. However, I am not able to mount the filesystem on
my 32-bit ARM board, which I am hoping to use for lower-power file
serving. dmesg shows the f
iew of the file system to pull off the bits I need?
Any help would be greatly appreciated.
Thanks.
-- Erik Jensen
--
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
Chris,
Now that you're back from vacation, I was wondering if you would be
able to provide a revised estimate on how long this will take. Also,
of the four parts, which will be necessary to correct a 'parent
transid verify failed' error?
Thank you for your time,
--Erik
On Thu, Aug 18, 2011 at 1:
r to
wait or cut my losses.
I understand that everyone is working hard, and I deeply appreciate
the effort being put into this filesystem. I'm not looking for an
exact date, just a rough order of magnitude on which to base
decisions.
Thank you very much.
--Erik Jensen
--
To unsubscribe from this lis
On Thu, Jul 14, 2011 at 12:50 PM, John Stoffel wrote:
>> "Alasdair" == Alasdair G Kergon writes:
>
> Alasdair> On Thu, Jul 14, 2011 at 04:38:36PM +1000, Neil Brown wrote:
>>> It might make sense for a device to be able to report what the maximum
>>> 'N' supported is... that might make stacke
On Wed, Jun 29, 2011 at 3:47 AM, A. James Lewis wrote:
> Is there a possibility that one could have a 3 disk RAID5 array, and
> then add a 4th disk and then do a balance, growing the RAID5 onto 4
> disks and gaining the space still with RAID5? It seems that to be
> consistent, BTRFS would have t
7:16PM -0700, Erik Jensen wrote:
> > One of my drives on my six drive btrfs setup recently died. I
> > initially wasn't too worried about it, since both my data and metadata
> > are raid1. However, I have so far not been able to remove the missing
> > drive af
After some more investigation, I discovered that for some reason btrfs
is trying to write to the missing drive (devid 5) in the course of
removing it from the array. Since this drive is missing, it is
naturally not writable, leading to the BUG.
If any other tests would be helpful in tracking down
One of my drives on my six drive btrfs setup recently died. I
initially wasn't too worried about it, since both my data and metadata
are raid1. However, I have so far not been able to remove the missing
drive after several attempts.
After discussing my problem on IRC, Chris Mason asked me to lis
I have an six-drive array I use for television recordings (4 2TB and 2 1.5TB).
Yesterday, I had one of the 1.5TBs die on me, so I did a "mount -o
degraded /dev/sdb /mnt/media" followed by a "btrfs-vol -r missing
/mnt/media", but the latter command almost immediately generated a
kernel BUG message,
e relevant part of the dmesg output: http://fpaste.org/jnz8/
The part of the kernel state that seemed like they might be relevant:
http://fpaste.org/0KKR/
btrfs-vol is towards the bottom. The entire state dump didn't fit in
my dmesg buffer so there might be something missing.
Thanks,
Er
37 matches
Mail list logo
