-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
zpool create - internal error: out of memory #13538
Comments
How much RAM do you have. Is an OOM (out of memory) ... maybe just a OOM ? |
The ram is not problem and strace in attached file from create pool on 1GB file (real device like /dev/sdb, or other device same error) |
I see no failures there :-( |
I change all yes, kerenel is self build, but is vanilla (no extra patches included). I used kernel 4.4 before and on zfs 2.x i had the same problem with zpool ;( , 0.8.6 no problem on both 4.4 and 4.9 |
This is the source where the error is reported... can you try to patch you zfs with this diff:
This will report the real problem function ... |
First of all, I would like to thank you for your help.
|
replace this: |
|
This shows us, that within the function
Can you debug the function |
gchmurka123_6 so i think lio_listio() function is problem there is my debug gchmurka123 brake points:
|
Can you extend the printf a bit, to get more details? Maybe like this: |
|
Did you get these errors from the can you replace the:
with this:
|
This patch work for me...
It looks like my problem started to occur with optimization of zpool_read_label with AIO: |
@behlendorf - should this change make it into OpenZFS? @gchmurka123 - can you mark this issue solved and close it? |
If I understand correctly and calling |
It'd be nice to understand why |
In my opinion kernel 4.9 it will be AOL on Jan. 2023, so I don't know if there is any point in investigating this bug further. For some reasons, I have to use 4.9 + zfs 2.x it in my environments for a while. If my patch is safe for me, I will close issiue, but you don't have to make changes to the main ZFS branches. |
The proposed change is definitely safe for you to use. Why it's needed is just a bit mysterious and I suppose it must be due to a quirk of your environment. Then I'll close this out. |
FWIW this bug seems to be happening on more recent kernels too. Same issue. Error: 'internal error: out of memory' after a The hardware itself is somewhat old - PC from 2013ish, disks potentially even older. In case that helps. |
First to check and rule out a hardware/disk problem try create pool on file:
|
I saw the same issue. However, in my case the reason was that there was a regular file with zero size instead of a block device for the underlying disk. So, the error message |
The minimum size of each device in a pool is 64 MB |
I met the same issue with you. The zero file is located in /tmp/(tmpfs) directory. I think zfs should be able to create a pool from a memory file for testing purpose. |
We encountered a similar issue. A running zpool ( Current error message is confusing. Anything we can do to improve it? |
Drop the no_memory() call from zpool_in_use() when reading the label fails and instead return the error to the caller. This prevents a misleading "internal error: out of memory" error when the label can't be read. This will result in is_spare() returning B_FALSE instead of aborting, which is already safely handled. Furthermore, on Linux it's possible for EREMOTEIO to returned by an NVMVe device if the device has been low-level formatted and not rescanned. In this case we want to fallback to the legacy scanning method and read any of the labels we can. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue openzfs#13538
Drop the no_memory() call from zpool_in_use() when reading the label fails and instead return the error to the caller. This prevents a misleading "internal error: out of memory" error when the label can't be read. This will result in is_spare() returning B_FALSE instead of aborting, which is already safely handled. Furthermore, on Linux it's possible for EREMOTEIO to returned by an NVMe device if the device has been low-level formatted and not rescanned. In this case we want to fallback to the legacy scanning method and read any of the labels we can. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue openzfs#13538
Drop the no_memory() call from zpool_in_use() when reading the label fails and instead return the error to the caller. This prevents a misleading "internal error: out of memory" error when the label can't be read. This will result in is_spare() returning B_FALSE instead of aborting, which is already safely handled. Furthermore, on Linux it's possible for EREMOTEIO to returned by an NVMe device if the device has been low-level formatted and not rescanned. In this case we want to fallback to the legacy scanning method and read any of the labels we can. Reviewed-by: Brian Atkinson <batkinson@lanl.gov> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue #13538 Closes #15747
Drop the no_memory() call from zpool_in_use() when reading the label fails and instead return the error to the caller. This prevents a misleading "internal error: out of memory" error when the label can't be read. This will result in is_spare() returning B_FALSE instead of aborting, which is already safely handled. Furthermore, on Linux it's possible for EREMOTEIO to returned by an NVMe device if the device has been low-level formatted and not rescanned. In this case we want to fallback to the legacy scanning method and read any of the labels we can. Reviewed-by: Brian Atkinson <batkinson@lanl.gov> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue openzfs#13538 Closes openzfs#15747
Drop the no_memory() call from zpool_in_use() when reading the label fails and instead return the error to the caller. This prevents a misleading "internal error: out of memory" error when the label can't be read. This will result in is_spare() returning B_FALSE instead of aborting, which is already safely handled. Furthermore, on Linux it's possible for EREMOTEIO to returned by an NVMe device if the device has been low-level formatted and not rescanned. In this case we want to fallback to the legacy scanning method and read any of the labels we can. Reviewed-by: Brian Atkinson <batkinson@lanl.gov> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue #13538 Closes #15747
Drop the no_memory() call from zpool_in_use() when reading the label fails and instead return the error to the caller. This prevents a misleading "internal error: out of memory" error when the label can't be read. This will result in is_spare() returning B_FALSE instead of aborting, which is already safely handled. Furthermore, on Linux it's possible for EREMOTEIO to returned by an NVMe device if the device has been low-level formatted and not rescanned. In this case we want to fallback to the legacy scanning method and read any of the labels we can. Reviewed-by: Brian Atkinson <batkinson@lanl.gov> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue openzfs#13538 Closes openzfs#15747
Drop the no_memory() call from zpool_in_use() when reading the label fails and instead return the error to the caller. This prevents a misleading "internal error: out of memory" error when the label can't be read. This will result in is_spare() returning B_FALSE instead of aborting, which is already safely handled. Furthermore, on Linux it's possible for EREMOTEIO to returned by an NVMe device if the device has been low-level formatted and not rescanned. In this case we want to fallback to the legacy scanning method and read any of the labels we can. Reviewed-by: Brian Atkinson <batkinson@lanl.gov> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Issue openzfs#13538 Closes openzfs#15747
Hello disk layout I created new partition 4 as "extended" and did:
deleting part4 with fdisk and recreating as primary works. |
@go-while Thanks, that fixed it for me as well. I had the exact same scenario. |
System information
Debian
x86_64-linux-gnu
zfs-2.1.4-1
zfs-kmod-2.1.4-1
Linux chmura 4.9.316 #5 SMP Tue Jun 7 13:02:00 CEST 2022 x86_64 GNU/Linux
Describe the problem you're observing
I am facing the development of a new zfs for very old systems with
kernel 4.9.316 (new build)
glibc 2.13
gcc version 4.7.2 (Debian 4.7.2-5)
Everything builds correctly, the zfs kernel module works, I can import the old pool created on zfs 0.8.6, update them, the tools work (like zfs create, destroy, snapshot, etc ) except for one command:
zpool create test device (or file)
always return
internal error: out of memory
Describe how to reproduce the problem
cd /build/zfs/zfs-2.1.4
./autogen.sh
./configure --disable-pyzfs --disable-systemd --with-linux=/build/linux-4.9.316 --with-linux-obj=/build/linux-4.9.316
make
make install
after make install (or make deb and install packages) command
zpool create test /dev/sdb
returns
internal error: out of memory
built old versions of zfs 0.8.6 work perfectly fine
The text was updated successfully, but these errors were encountered: