At 11/07/2016 10:55 PM, Marc MERLIN wrote:
On Mon, Nov 07, 2016 at 02:16:37PM +0800, Qu Wenruo wrote:
At 11/07/2016 01:36 PM, Marc MERLIN wrote:
(sorry for the bad subject line from the mdadm list on the previous mail)
On Mon, Nov 07, 2016 at 12:18:10PM +0800, Qu Wenruo wrote:
I'm totally wrong here.
DirectIO needs the 'buf' parameter of read()/pread() to be 512 bytes
aligned.
While we are using a lot of stack memory() and normal malloc()/calloc()
allocated memory, which are seldom aligned to 512 bytes.
So to *workaround* the problem in btrfs-progs, we may need to change any
pread() caller to use aligned memory allocation.
I really don't think David will accept such huge change for a workdaround...
Thanks for looking into it.
So basically should we just document that btrfs filesystems past 8TB in
size are not supported on 32bit architectures?
(as in you can mount them and use them I believe, but you cannot create,
or repair them)
Marc
Add David to this thread.
For create, it should be OK. As at create time, we hardly write beyond 3G.
So it won't be a big problem.
For repair, we do have a possibility that btrfsck can't handle it.
Anyway, I'd like to see how David thinks what we should do the handle the
problem.
Understood. One big thing (for me) I forgot to confirm:
1) btrfs receive
Unfortunately, receive is completely done in userspace.
Only send works inside kernel.
So, receive will fail to reconstruct any file larger beyond 8T.
Despite that, any other normal file smaller than 8T is not affected.
2) btrfs scrub
Scrub does work in kernel, so it's unaffected.
Thanks,
Qu
should both be able to work because the IO operations are done directly
inside the kernel and not from user space, correct?
Thanks,
Marc
--
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
