2019-07-31 23:57:31 +08:00
|
|
|
|
2018-07-26 20:21:47 +08:00
|
|
|
|
|
|
|
|
|
2020-07-13 15:09:44 +02:00
|
|
|
|
2021-08-20 18:00:19 +08:00
|
|
|
|
2018-07-26 20:21:47 +08:00
|
|
|
|
|
|
|
|
|
2026-01-08 12:12:59 -05:00
|
|
|
|
2022-04-25 20:21:39 +08:00
|
|
|
|
2018-07-26 20:21:55 +08:00
|
|
|
|
|
|
|
|
|
2022-01-02 12:00:13 +08:00
|
|
|
|
|
|
|
|
|
2024-11-14 17:58:13 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-01-02 12:00:13 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-07-23 15:30:24 +08:00
|
|
|
|
2022-01-02 12:00:13 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-02-17 04:31:41 -05:00
|
|
|
|
2022-01-02 12:00:13 +08:00
|
|
|
|
2025-05-17 17:05:43 +08:00
|
|
|
|
2024-07-23 15:30:24 +08:00
|
|
|
|
2022-01-02 12:00:13 +08:00
|
|
|
|
2024-07-23 15:30:24 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-01-02 12:00:13 +08:00
|
|
|
|
2026-08-11 17:07:17 +08:00
|
|
|
|
|
|
|
|
|
2022-04-25 20:21:39 +08:00
|
|
|
|
|
|
|
|
|
2022-01-02 12:00:13 +08:00
|
|
|
|
2024-07-23 15:30:24 +08:00
|
|
|
|
2025-02-17 04:31:41 -05:00
|
|
|
|
2022-01-02 12:00:13 +08:00
|
|
|
|
2025-02-17 04:31:41 -05:00
|
|
|
|
|
|
|
|
|
erofs: add missing buf->off in erofs_bread()
erofs_bread() locates the target folio with
index = (buf->off + offset) >> PAGE_SHIFT;
but computes the in-folio offset without taking buf->off into account:
return buf->base + (offset & ~PAGE_MASK);
If buf->off is not page-aligned, the returned pointer misses the in-page
component of buf->off, so callers end up fetching data from a wrong
offset.
buf->off is set to sbi->dif0.fsoff in erofs_init_metabuf(), and fsoff can
be specified via the "fsoffset=" mount option, which only requires
block-size alignment. Therefore, on an image with a sub-page block size
(e.g. 512 bytes), a non-page-aligned fsoff (e.g. 512) triggers the issue,
since 512 is a multiple of the block size but not of PAGE_SIZE.
It can be reproduced by mounting an image that is placed at a
non-page-aligned offset:
mkfs.erofs -b512 -zlz4hc sub.erofs src/
# prepend 512 bytes of padding to the image
mount -t erofs -o loop,fsoffset=512 padded.erofs /mnt
which fails with
erofs (device loop0): cannot find valid erofs superblock
because the on-disk superblock (at offset 1024 within the image, i.e.
1536 within the padded file) is read from a wrong in-folio offset. With
this fixed, the very same image mounts successfully and its file contents
match those read from the unpadded image.
Fix it by including buf->off in the in-folio offset calculation, so that
it is consistent with the folio index calculation.
Fixes: c36ec00d7f67 ("erofs: add 'fsoffset' mount option to specify filesystem offset")
Signed-off-by: Binglei Wang <l3b2w1@gmail.com>
Reviewed-by: Gao Xiang <xiang@kernel.org>
Signed-off-by: Gao Xiang <xiang@kernel.org>
2026-09-11 12:11:33 +08:00
|
|
|
|
2022-01-02 12:00:13 +08:00
|
|
|
|
|
|
|
|
|
2025-07-22 08:32:29 +08:00
|
|
|
|
|
|
|
|
|
2023-04-07 22:17:04 +08:00
|
|
|
|
erofs: add file-backed mount support
It actually has been around for years: For containers and other sandbox
use cases, there will be thousands (and even more) of authenticated
(sub)images running on the same host, unlike OS images.
Of course, all scenarios can use the same EROFS on-disk format, but
bdev-backed mounts just work well for OS images since golden data is
dumped into real block devices. However, it's somewhat hard for
container runtimes to manage and isolate so many unnecessary virtual
block devices safely and efficiently [1]: they just look like a burden
to orchestrators and file-backed mounts are preferred indeed. There
were already enough attempts such as Incremental FS, the original
ComposeFS and PuzzleFS acting in the same way for immutable fses. As
for current EROFS users, ComposeFS, containerd and Android APEXs will
be directly benefited from it.
On the other hand, previous experimental feature "erofs over fscache"
was once also intended to provide a similar solution (inspired by
Incremental FS discussion [2]), but the following facts show file-backed
mounts will be a better approach:
- Fscache infrastructure has recently been moved into new Netfslib
which is an unexpected dependency to EROFS really, although it
originally claims "it could be used for caching other things such as
ISO9660 filesystems too." [3]
- It takes an unexpectedly long time to upstream Fscache/Cachefiles
enhancements. For example, the failover feature took more than
one year, and the deamonless feature is still far behind now;
- Ongoing HSM "fanotify pre-content hooks" [4] together with this will
perfectly supersede "erofs over fscache" in a simpler way since
developers (mainly containerd folks) could leverage their existing
caching mechanism entirely in userspace instead of strictly following
the predefined in-kernel caching tree hierarchy.
After "fanotify pre-content hooks" lands upstream to provide the same
functionality, "erofs over fscache" will be removed then (as an EROFS
internal improvement and EROFS will not have to bother with on-demand
fetching and/or caching improvements anymore.)
[1] https://github.com/containers/storage/pull/2039
[2] https://lore.kernel.org/r/CAOQ4uxjbVxnubaPjVaGYiSwoGDTdpWbB=w_AeM6YM=zVixsUfQ@mail.gmail.com
[3] https://docs.kernel.org/filesystems/caching/fscache.html
[4] https://lore.kernel.org/r/cover.1723670362.git.josef@toxicpanda.com
Closes: https://github.com/containers/composefs/issues/144
Reviewed-by: Sandeep Dhavale <dhavale@google.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Link: https://lore.kernel.org/r/20240830032840.3783206-1-hsiangkao@linux.alibaba.com
2024-08-30 11:28:37 +08:00
|
|
|
|
|
|
|
|
|
2026-08-11 17:07:17 +08:00
|
|
|
|
2025-07-22 08:32:29 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-11-15 07:49:05 +08:00
|
|
|
|
2026-08-11 17:07:17 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-04-11 15:53:37 +01:00
|
|
|
|
2026-08-11 17:07:17 +08:00
|
|
|
|
2025-07-22 08:32:29 +08:00
|
|
|
|
2023-04-07 22:17:04 +08:00
|
|
|
|
|
|
|
|
|
2022-03-16 09:22:45 +08:00
|
|
|
|
2025-07-22 08:32:29 +08:00
|
|
|
|
2022-03-16 09:22:45 +08:00
|
|
|
|
2025-07-22 08:32:29 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-14 17:09:06 +08:00
|
|
|
|
2022-03-16 09:22:45 +08:00
|
|
|
|
|
|
|
|
|
2026-06-15 15:37:35 +08:00
|
|
|
|
2021-08-20 18:00:19 +08:00
|
|
|
|
2025-03-10 17:54:51 +08:00
|
|
|
|
2021-08-20 18:00:19 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-06-15 15:37:35 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-20 18:00:19 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-02-09 10:48:25 +08:00
|
|
|
|
2021-10-14 16:10:10 +08:00
|
|
|
|
2025-03-10 17:54:51 +08:00
|
|
|
|
|
|
|
|
|
2021-08-20 18:00:19 +08:00
|
|
|
|
2026-06-15 15:37:35 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-03-10 17:54:51 +08:00
|
|
|
|
|
|
|
|
|
2025-03-10 17:54:53 +08:00
|
|
|
|
2025-03-10 17:54:51 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-06-15 15:37:35 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-20 18:00:19 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-06-15 15:37:35 +08:00
|
|
|
|
2023-02-09 10:48:25 +08:00
|
|
|
|
2021-08-20 18:00:19 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
erofs: add file-backed mount support
It actually has been around for years: For containers and other sandbox
use cases, there will be thousands (and even more) of authenticated
(sub)images running on the same host, unlike OS images.
Of course, all scenarios can use the same EROFS on-disk format, but
bdev-backed mounts just work well for OS images since golden data is
dumped into real block devices. However, it's somewhat hard for
container runtimes to manage and isolate so many unnecessary virtual
block devices safely and efficiently [1]: they just look like a burden
to orchestrators and file-backed mounts are preferred indeed. There
were already enough attempts such as Incremental FS, the original
ComposeFS and PuzzleFS acting in the same way for immutable fses. As
for current EROFS users, ComposeFS, containerd and Android APEXs will
be directly benefited from it.
On the other hand, previous experimental feature "erofs over fscache"
was once also intended to provide a similar solution (inspired by
Incremental FS discussion [2]), but the following facts show file-backed
mounts will be a better approach:
- Fscache infrastructure has recently been moved into new Netfslib
which is an unexpected dependency to EROFS really, although it
originally claims "it could be used for caching other things such as
ISO9660 filesystems too." [3]
- It takes an unexpectedly long time to upstream Fscache/Cachefiles
enhancements. For example, the failover feature took more than
one year, and the deamonless feature is still far behind now;
- Ongoing HSM "fanotify pre-content hooks" [4] together with this will
perfectly supersede "erofs over fscache" in a simpler way since
developers (mainly containerd folks) could leverage their existing
caching mechanism entirely in userspace instead of strictly following
the predefined in-kernel caching tree hierarchy.
After "fanotify pre-content hooks" lands upstream to provide the same
functionality, "erofs over fscache" will be removed then (as an EROFS
internal improvement and EROFS will not have to bother with on-demand
fetching and/or caching improvements anymore.)
[1] https://github.com/containers/storage/pull/2039
[2] https://lore.kernel.org/r/CAOQ4uxjbVxnubaPjVaGYiSwoGDTdpWbB=w_AeM6YM=zVixsUfQ@mail.gmail.com
[3] https://docs.kernel.org/filesystems/caching/fscache.html
[4] https://lore.kernel.org/r/cover.1723670362.git.josef@toxicpanda.com
Closes: https://github.com/containers/composefs/issues/144
Reviewed-by: Sandeep Dhavale <dhavale@google.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Link: https://lore.kernel.org/r/20240830032840.3783206-1-hsiangkao@linux.alibaba.com
2024-08-30 11:28:37 +08:00
|
|
|
|
2024-12-13 07:54:01 +08:00
|
|
|
|
erofs: add file-backed mount support
It actually has been around for years: For containers and other sandbox
use cases, there will be thousands (and even more) of authenticated
(sub)images running on the same host, unlike OS images.
Of course, all scenarios can use the same EROFS on-disk format, but
bdev-backed mounts just work well for OS images since golden data is
dumped into real block devices. However, it's somewhat hard for
container runtimes to manage and isolate so many unnecessary virtual
block devices safely and efficiently [1]: they just look like a burden
to orchestrators and file-backed mounts are preferred indeed. There
were already enough attempts such as Incremental FS, the original
ComposeFS and PuzzleFS acting in the same way for immutable fses. As
for current EROFS users, ComposeFS, containerd and Android APEXs will
be directly benefited from it.
On the other hand, previous experimental feature "erofs over fscache"
was once also intended to provide a similar solution (inspired by
Incremental FS discussion [2]), but the following facts show file-backed
mounts will be a better approach:
- Fscache infrastructure has recently been moved into new Netfslib
which is an unexpected dependency to EROFS really, although it
originally claims "it could be used for caching other things such as
ISO9660 filesystems too." [3]
- It takes an unexpectedly long time to upstream Fscache/Cachefiles
enhancements. For example, the failover feature took more than
one year, and the deamonless feature is still far behind now;
- Ongoing HSM "fanotify pre-content hooks" [4] together with this will
perfectly supersede "erofs over fscache" in a simpler way since
developers (mainly containerd folks) could leverage their existing
caching mechanism entirely in userspace instead of strictly following
the predefined in-kernel caching tree hierarchy.
After "fanotify pre-content hooks" lands upstream to provide the same
functionality, "erofs over fscache" will be removed then (as an EROFS
internal improvement and EROFS will not have to bother with on-demand
fetching and/or caching improvements anymore.)
[1] https://github.com/containers/storage/pull/2039
[2] https://lore.kernel.org/r/CAOQ4uxjbVxnubaPjVaGYiSwoGDTdpWbB=w_AeM6YM=zVixsUfQ@mail.gmail.com
[3] https://docs.kernel.org/filesystems/caching/fscache.html
[4] https://lore.kernel.org/r/cover.1723670362.git.josef@toxicpanda.com
Closes: https://github.com/containers/composefs/issues/144
Reviewed-by: Sandeep Dhavale <dhavale@google.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Link: https://lore.kernel.org/r/20240830032840.3783206-1-hsiangkao@linux.alibaba.com
2024-08-30 11:28:37 +08:00
|
|
|
|
2024-12-13 07:54:01 +08:00
|
|
|
|
|
|
|
|
|
erofs: add file-backed mount support
It actually has been around for years: For containers and other sandbox
use cases, there will be thousands (and even more) of authenticated
(sub)images running on the same host, unlike OS images.
Of course, all scenarios can use the same EROFS on-disk format, but
bdev-backed mounts just work well for OS images since golden data is
dumped into real block devices. However, it's somewhat hard for
container runtimes to manage and isolate so many unnecessary virtual
block devices safely and efficiently [1]: they just look like a burden
to orchestrators and file-backed mounts are preferred indeed. There
were already enough attempts such as Incremental FS, the original
ComposeFS and PuzzleFS acting in the same way for immutable fses. As
for current EROFS users, ComposeFS, containerd and Android APEXs will
be directly benefited from it.
On the other hand, previous experimental feature "erofs over fscache"
was once also intended to provide a similar solution (inspired by
Incremental FS discussion [2]), but the following facts show file-backed
mounts will be a better approach:
- Fscache infrastructure has recently been moved into new Netfslib
which is an unexpected dependency to EROFS really, although it
originally claims "it could be used for caching other things such as
ISO9660 filesystems too." [3]
- It takes an unexpectedly long time to upstream Fscache/Cachefiles
enhancements. For example, the failover feature took more than
one year, and the deamonless feature is still far behind now;
- Ongoing HSM "fanotify pre-content hooks" [4] together with this will
perfectly supersede "erofs over fscache" in a simpler way since
developers (mainly containerd folks) could leverage their existing
caching mechanism entirely in userspace instead of strictly following
the predefined in-kernel caching tree hierarchy.
After "fanotify pre-content hooks" lands upstream to provide the same
functionality, "erofs over fscache" will be removed then (as an EROFS
internal improvement and EROFS will not have to bother with on-demand
fetching and/or caching improvements anymore.)
[1] https://github.com/containers/storage/pull/2039
[2] https://lore.kernel.org/r/CAOQ4uxjbVxnubaPjVaGYiSwoGDTdpWbB=w_AeM6YM=zVixsUfQ@mail.gmail.com
[3] https://docs.kernel.org/filesystems/caching/fscache.html
[4] https://lore.kernel.org/r/cover.1723670362.git.josef@toxicpanda.com
Closes: https://github.com/containers/composefs/issues/144
Reviewed-by: Sandeep Dhavale <dhavale@google.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Link: https://lore.kernel.org/r/20240830032840.3783206-1-hsiangkao@linux.alibaba.com
2024-08-30 11:28:37 +08:00
|
|
|
|
2024-12-13 07:54:01 +08:00
|
|
|
|
|
|
|
|
|
erofs: add file-backed mount support
It actually has been around for years: For containers and other sandbox
use cases, there will be thousands (and even more) of authenticated
(sub)images running on the same host, unlike OS images.
Of course, all scenarios can use the same EROFS on-disk format, but
bdev-backed mounts just work well for OS images since golden data is
dumped into real block devices. However, it's somewhat hard for
container runtimes to manage and isolate so many unnecessary virtual
block devices safely and efficiently [1]: they just look like a burden
to orchestrators and file-backed mounts are preferred indeed. There
were already enough attempts such as Incremental FS, the original
ComposeFS and PuzzleFS acting in the same way for immutable fses. As
for current EROFS users, ComposeFS, containerd and Android APEXs will
be directly benefited from it.
On the other hand, previous experimental feature "erofs over fscache"
was once also intended to provide a similar solution (inspired by
Incremental FS discussion [2]), but the following facts show file-backed
mounts will be a better approach:
- Fscache infrastructure has recently been moved into new Netfslib
which is an unexpected dependency to EROFS really, although it
originally claims "it could be used for caching other things such as
ISO9660 filesystems too." [3]
- It takes an unexpectedly long time to upstream Fscache/Cachefiles
enhancements. For example, the failover feature took more than
one year, and the deamonless feature is still far behind now;
- Ongoing HSM "fanotify pre-content hooks" [4] together with this will
perfectly supersede "erofs over fscache" in a simpler way since
developers (mainly containerd folks) could leverage their existing
caching mechanism entirely in userspace instead of strictly following
the predefined in-kernel caching tree hierarchy.
After "fanotify pre-content hooks" lands upstream to provide the same
functionality, "erofs over fscache" will be removed then (as an EROFS
internal improvement and EROFS will not have to bother with on-demand
fetching and/or caching improvements anymore.)
[1] https://github.com/containers/storage/pull/2039
[2] https://lore.kernel.org/r/CAOQ4uxjbVxnubaPjVaGYiSwoGDTdpWbB=w_AeM6YM=zVixsUfQ@mail.gmail.com
[3] https://docs.kernel.org/filesystems/caching/fscache.html
[4] https://lore.kernel.org/r/cover.1723670362.git.josef@toxicpanda.com
Closes: https://github.com/containers/composefs/issues/144
Reviewed-by: Sandeep Dhavale <dhavale@google.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Link: https://lore.kernel.org/r/20240830032840.3783206-1-hsiangkao@linux.alibaba.com
2024-08-30 11:28:37 +08:00
|
|
|
|
|
|
|
|
|
2021-10-14 16:10:10 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-03-10 17:54:53 +08:00
|
|
|
|
2021-10-14 16:10:10 +08:00
|
|
|
|
|
|
|
|
|
2024-12-13 07:54:01 +08:00
|
|
|
|
2024-12-16 20:53:08 +08:00
|
|
|
|
2021-10-14 16:10:10 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-03-02 15:17:51 +08:00
|
|
|
|
2025-03-10 17:54:53 +08:00
|
|
|
|
2023-03-02 15:17:51 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-12-13 07:54:01 +08:00
|
|
|
|
2021-10-14 16:10:10 +08:00
|
|
|
|
2023-03-02 15:17:51 +08:00
|
|
|
|
2021-10-14 16:10:10 +08:00
|
|
|
|
|
|
|
|
|
2025-03-10 17:54:53 +08:00
|
|
|
|
2021-10-14 16:10:10 +08:00
|
|
|
|
erofs: add file-backed mount support
It actually has been around for years: For containers and other sandbox
use cases, there will be thousands (and even more) of authenticated
(sub)images running on the same host, unlike OS images.
Of course, all scenarios can use the same EROFS on-disk format, but
bdev-backed mounts just work well for OS images since golden data is
dumped into real block devices. However, it's somewhat hard for
container runtimes to manage and isolate so many unnecessary virtual
block devices safely and efficiently [1]: they just look like a burden
to orchestrators and file-backed mounts are preferred indeed. There
were already enough attempts such as Incremental FS, the original
ComposeFS and PuzzleFS acting in the same way for immutable fses. As
for current EROFS users, ComposeFS, containerd and Android APEXs will
be directly benefited from it.
On the other hand, previous experimental feature "erofs over fscache"
was once also intended to provide a similar solution (inspired by
Incremental FS discussion [2]), but the following facts show file-backed
mounts will be a better approach:
- Fscache infrastructure has recently been moved into new Netfslib
which is an unexpected dependency to EROFS really, although it
originally claims "it could be used for caching other things such as
ISO9660 filesystems too." [3]
- It takes an unexpectedly long time to upstream Fscache/Cachefiles
enhancements. For example, the failover feature took more than
one year, and the deamonless feature is still far behind now;
- Ongoing HSM "fanotify pre-content hooks" [4] together with this will
perfectly supersede "erofs over fscache" in a simpler way since
developers (mainly containerd folks) could leverage their existing
caching mechanism entirely in userspace instead of strictly following
the predefined in-kernel caching tree hierarchy.
After "fanotify pre-content hooks" lands upstream to provide the same
functionality, "erofs over fscache" will be removed then (as an EROFS
internal improvement and EROFS will not have to bother with on-demand
fetching and/or caching improvements anymore.)
[1] https://github.com/containers/storage/pull/2039
[2] https://lore.kernel.org/r/CAOQ4uxjbVxnubaPjVaGYiSwoGDTdpWbB=w_AeM6YM=zVixsUfQ@mail.gmail.com
[3] https://docs.kernel.org/filesystems/caching/fscache.html
[4] https://lore.kernel.org/r/cover.1723670362.git.josef@toxicpanda.com
Closes: https://github.com/containers/composefs/issues/144
Reviewed-by: Sandeep Dhavale <dhavale@google.com>
Reviewed-by: Chao Yu <chao@kernel.org>
Signed-off-by: Gao Xiang <hsiangkao@linux.alibaba.com>
Link: https://lore.kernel.org/r/20240830032840.3783206-1-hsiangkao@linux.alibaba.com
2024-08-30 11:28:37 +08:00
|
|
|
|
2025-03-10 17:54:53 +08:00
|
|
|
|
2021-10-14 16:10:10 +08:00
|
|
|
|
2025-03-10 17:54:53 +08:00
|
|
|
|
2021-10-14 16:10:10 +08:00
|
|
|
|
2024-12-13 07:54:01 +08:00
|
|
|
|
2021-10-14 16:10:10 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-09-05 17:30:31 +08:00
|
|
|
|
|
|
|
|
|
2025-07-09 11:46:14 +08:00
|
|
|
|
2024-09-05 17:30:31 +08:00
|
|
|
|
|
|
|
|
|
2025-07-09 11:46:14 +08:00
|
|
|
|
|
|
|
|
|
2024-09-05 17:30:31 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-09 11:46:14 +08:00
|
|
|
|
2024-09-05 17:30:31 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-09 11:46:14 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-09-05 17:30:31 +08:00
|
|
|
|
|
|
|
|
|
2025-07-09 11:46:14 +08:00
|
|
|
|
2024-09-05 17:30:31 +08:00
|
|
|
|
|
|
|
|
|
2025-07-09 11:46:14 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-09-05 17:30:31 +08:00
|
|
|
|
|
|
|
|
|
2026-01-09 10:28:48 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-23 01:31:30 +00:00
|
|
|
|
2026-01-09 10:28:48 +00:00
|
|
|
|
|
|
|
|
|
2021-08-05 08:35:59 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-09 10:28:48 +00:00
|
|
|
|
|
|
|
|
|
2026-01-23 01:31:30 +00:00
|
|
|
|
|
|
|
|
|
2021-08-05 08:35:59 +08:00
|
|
|
|
2021-10-14 16:10:10 +08:00
|
|
|
|
2026-01-09 10:28:48 +00:00
|
|
|
|
2021-08-05 08:35:59 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-23 01:31:30 +00:00
|
|
|
|
2021-08-05 08:35:59 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-16 17:22:54 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-22 08:32:29 +08:00
|
|
|
|
2025-07-16 17:22:54 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-23 01:31:30 +00:00
|
|
|
|
2025-07-22 08:32:29 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-10-14 16:10:10 +08:00
|
|
|
|
2025-07-22 08:32:29 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-05 08:35:59 +08:00
|
|
|
|
|
|
|
|
|
2021-08-05 08:36:01 +08:00
|
|
|
|
2026-01-09 10:28:48 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-23 01:31:30 +00:00
|
|
|
|
2026-01-09 10:28:48 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-05 08:36:01 +08:00
|
|
|
|
|
|
|
|
|
2021-08-05 08:35:59 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-05 08:36:01 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-09 10:28:48 +00:00
|
|
|
|
|
|
|
|
|
2022-01-02 12:00:13 +08:00
|
|
|
|
2026-01-09 10:28:48 +00:00
|
|
|
|
2022-01-02 12:00:13 +08:00
|
|
|
|
2026-01-09 10:28:48 +00:00
|
|
|
|
|
|
|
|
|
2022-01-02 12:00:13 +08:00
|
|
|
|
2021-08-05 08:36:01 +08:00
|
|
|
|
|
|
|
|
|
2022-01-02 12:00:13 +08:00
|
|
|
|
2026-01-09 10:28:48 +00:00
|
|
|
|
2021-08-05 08:36:01 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-07-29 12:27:26 -07:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-05 08:35:59 +08:00
|
|
|
|
2026-07-29 12:27:26 -07:00
|
|
|
|
2021-08-05 08:35:59 +08:00
|
|
|
|
|
|
|
|
|
2021-08-13 13:29:31 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-02 11:09:09 +08:00
|
|
|
|
|
|
|
|
|
2021-08-13 13:29:31 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-05 08:36:01 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2022-04-29 08:54:32 -04:00
|
|
|
|
2021-08-05 08:36:01 +08:00
|
|
|
|
2026-01-09 10:28:48 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-23 01:31:30 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-08 19:19:42 +08:00
|
|
|
|
2026-01-23 01:31:30 +00:00
|
|
|
|
2026-01-09 10:28:48 +00:00
|
|
|
|
2026-01-23 01:31:30 +00:00
|
|
|
|
|
|
|
|
|
2025-09-25 17:26:04 -07:00
|
|
|
|
2021-08-05 08:36:01 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-09 10:28:48 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-23 01:31:30 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2025-07-07 16:48:32 +08:00
|
|
|
|
2026-01-23 01:31:30 +00:00
|
|
|
|
2026-01-23 01:31:29 +00:00
|
|
|
|
2026-01-09 10:28:48 +00:00
|
|
|
|
2026-01-23 01:31:30 +00:00
|
|
|
|
|
|
|
|
|
2021-08-05 08:36:01 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-05 08:35:59 +08:00
|
|
|
|
|
|
|
|
|
2022-07-20 16:22:29 +08:00
|
|
|
|
|
|
|
|
|
2021-08-05 08:35:59 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-02 11:09:09 +08:00
|
|
|
|
2021-08-05 08:36:00 +08:00
|
|
|
|
2026-02-02 11:09:09 +08:00
|
|
|
|
2026-01-09 10:28:48 +00:00
|
|
|
|
2026-01-23 01:31:30 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-01-09 10:28:48 +00:00
|
|
|
|
2022-07-20 16:22:29 +08:00
|
|
|
|
2026-01-09 10:28:48 +00:00
|
|
|
|
|
|
|
|
|
2021-08-05 08:35:59 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2018-07-26 20:21:47 +08:00
|
|
|
|
2024-09-05 17:30:31 +08:00
|
|
|
|
2022-04-29 08:54:32 -04:00
|
|
|
|
2021-08-05 08:36:01 +08:00
|
|
|
|
2019-07-16 17:32:56 +08:00
|
|
|
|
2021-08-05 08:35:59 +08:00
|
|
|
|
2022-11-30 14:04:55 +08:00
|
|
|
|
|
|
|
|
|
2021-08-05 08:35:59 +08:00
|
|
|
|
|
|
|
|
|
2021-08-05 08:36:00 +08:00
|
|
|
|
|
|
|
|
|
2023-08-18 21:23:35 +01:00
|
|
|
|
2021-08-05 08:36:00 +08:00
|
|
|
|
2023-08-18 21:23:35 +01:00
|
|
|
|
2021-08-05 08:36:00 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2023-08-18 21:23:35 +01:00
|
|
|
|
2021-08-05 08:36:00 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
fs: convert most other generic_file_*mmap() users to .mmap_prepare()
Update nearly all generic_file_mmap() and generic_file_readonly_mmap()
callers to use generic_file_mmap_prepare() and
generic_file_readonly_mmap_prepare() respectively.
We update blkdev, 9p, afs, erofs, ext2, nfs, ntfs3, smb, ubifs and vboxsf
file systems this way.
Remaining users we cannot yet update are ecryptfs, fuse and cramfs. The
former two are nested file systems that must support any underlying file
ssytem, and cramfs inserts a mixed mapping which currently requires a VMA.
Once all file systems have been converted to mmap_prepare(), we can then
update nested file systems.
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Link: https://lore.kernel.org/08db85970d89b17a995d2cffae96fb4cc462377f.1750099179.git.lorenzo.stoakes@oracle.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-06-16 20:33:28 +01:00
|
|
|
|
2021-08-05 08:36:00 +08:00
|
|
|
|
fs: convert most other generic_file_*mmap() users to .mmap_prepare()
Update nearly all generic_file_mmap() and generic_file_readonly_mmap()
callers to use generic_file_mmap_prepare() and
generic_file_readonly_mmap_prepare() respectively.
We update blkdev, 9p, afs, erofs, ext2, nfs, ntfs3, smb, ubifs and vboxsf
file systems this way.
Remaining users we cannot yet update are ecryptfs, fuse and cramfs. The
former two are nested file systems that must support any underlying file
ssytem, and cramfs inserts a mixed mapping which currently requires a VMA.
Once all file systems have been converted to mmap_prepare(), we can then
update nested file systems.
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Link: https://lore.kernel.org/08db85970d89b17a995d2cffae96fb4cc462377f.1750099179.git.lorenzo.stoakes@oracle.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-06-16 20:33:28 +01:00
|
|
|
|
|
|
|
|
|
2021-08-05 08:36:00 +08:00
|
|
|
|
2026-03-05 10:50:15 +00:00
|
|
|
|
2021-08-05 08:36:00 +08:00
|
|
|
|
|
|
|
|
|
fs: convert most other generic_file_*mmap() users to .mmap_prepare()
Update nearly all generic_file_mmap() and generic_file_readonly_mmap()
callers to use generic_file_mmap_prepare() and
generic_file_readonly_mmap_prepare() respectively.
We update blkdev, 9p, afs, erofs, ext2, nfs, ntfs3, smb, ubifs and vboxsf
file systems this way.
Remaining users we cannot yet update are ecryptfs, fuse and cramfs. The
former two are nested file systems that must support any underlying file
ssytem, and cramfs inserts a mixed mapping which currently requires a VMA.
Once all file systems have been converted to mmap_prepare(), we can then
update nested file systems.
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Link: https://lore.kernel.org/08db85970d89b17a995d2cffae96fb4cc462377f.1750099179.git.lorenzo.stoakes@oracle.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-06-16 20:33:28 +01:00
|
|
|
|
2026-01-22 16:06:18 +00:00
|
|
|
|
2021-08-05 08:36:00 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
fs: convert most other generic_file_*mmap() users to .mmap_prepare()
Update nearly all generic_file_mmap() and generic_file_readonly_mmap()
callers to use generic_file_mmap_prepare() and
generic_file_readonly_mmap_prepare() respectively.
We update blkdev, 9p, afs, erofs, ext2, nfs, ntfs3, smb, ubifs and vboxsf
file systems this way.
Remaining users we cannot yet update are ecryptfs, fuse and cramfs. The
former two are nested file systems that must support any underlying file
ssytem, and cramfs inserts a mixed mapping which currently requires a VMA.
Once all file systems have been converted to mmap_prepare(), we can then
update nested file systems.
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Link: https://lore.kernel.org/08db85970d89b17a995d2cffae96fb4cc462377f.1750099179.git.lorenzo.stoakes@oracle.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-06-16 20:33:28 +01:00
|
|
|
|
2021-08-05 08:36:00 +08:00
|
|
|
|
|
|
|
|
|
2026-08-20 21:40:06 +08:00
|
|
|
|
2024-10-11 14:51:28 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2026-02-02 11:09:09 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2024-10-11 14:51:28 +08:00
|
|
|
|
2026-02-02 11:09:09 +08:00
|
|
|
|
2024-10-11 14:51:28 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
2021-08-05 08:35:59 +08:00
|
|
|
|
2024-10-11 14:51:28 +08:00
|
|
|
|
2021-08-05 08:35:59 +08:00
|
|
|
|
2025-09-23 15:01:12 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
fs: convert most other generic_file_*mmap() users to .mmap_prepare()
Update nearly all generic_file_mmap() and generic_file_readonly_mmap()
callers to use generic_file_mmap_prepare() and
generic_file_readonly_mmap_prepare() respectively.
We update blkdev, 9p, afs, erofs, ext2, nfs, ntfs3, smb, ubifs and vboxsf
file systems this way.
Remaining users we cannot yet update are ecryptfs, fuse and cramfs. The
former two are nested file systems that must support any underlying file
ssytem, and cramfs inserts a mixed mapping which currently requires a VMA.
Once all file systems have been converted to mmap_prepare(), we can then
update nested file systems.
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Link: https://lore.kernel.org/08db85970d89b17a995d2cffae96fb4cc462377f.1750099179.git.lorenzo.stoakes@oracle.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
2025-06-16 20:33:28 +01:00
|
|
|
|
2024-03-06 13:31:38 +08:00
|
|
|
|
2023-05-22 14:50:15 +01:00
|
|
|
|
2026-01-08 12:12:59 -05:00
|
|
|
|
2018-07-26 20:21:47 +08:00
|
|
|
|
