It isn't android storage emulated esdfs or sdcardfs problem, i test mount bind /data/media on /storage/emulated, can reproduce my problem. Let me say clear my problem, "ext4: Stop providing .writepage hook" cause android gallery app unable read pictures thumbnails. I test linux kernel 6.3 Revert "ext4: Stop providing .writepage hook", android gallery can read pictures thumbnails, this is mount bind /data/media on /storage/emulated /dev/nvme0n1p1 on /storage/emulated type ext4 (rw,seclabel,noatime) /dev/nvme0n1p1 on /mnt/runtime/default/emulated type ext4 (rw,seclabel,noatime) /dev/nvme0n1p1 on /mnt/runtime/read/emulated type ext4 (rw,seclabel,noatime) /dev/nvme0n1p1 on /mnt/runtime/write/emulated type ext4 (rw,seclabel,noatime) /dev/nvme0n1p1 on /mnt/runtime/full/emulated type ext4 (rw,seclabel,noatime) this is esdfs, /data/media on /mnt/runtime/default/emulated type esdfs (rw,nosuid,nodev,noexec,noatime,lower=1023:1023:664:775,upper=0:1015:771:771,derive=multi,noconfine,derive_gid,default_normal,unshared_obb) /data/media on /storage/emulated type esdfs (rw,nosuid,nodev,noexec,noatime,lower=1023:1023:664:775,upper=0:1015:771:771,derive=multi,noconfine,derive_gid,default_normal,unshared_obb) /data/media on /mnt/runtime/read/emulated type esdfs (rw,nosuid,nodev,noexec,noatime,lower=1023:1023:664:775,upper=0:9997:750:750,derive=multi,noconfine,derive_gid,default_normal,unshared_obb) /data/media on /mnt/runtime/write/emulated type esdfs (rw,nosuid,nodev,noexec,noatime,lower=1023:1023:664:775,upper=0:9997:770:770,derive=multi,noconfine,derive_gid,default_normal,unshared_obb) /data/media on /mnt/runtime/full/emulated type esdfs (rw,nosuid,nodev,noexec,noatime,lower=1023:1023:664:775,upper=0:9997:770:770,derive=multi,noconfine,derive_gid,default_normal,unshared_obb) if i do mount bind data/media on storage/emulated, take a screenshot, will create /data/media/0/Pictures/Screenshots/Screenshot_20230510-130020.png file, chmod -R 0777 /data/media/0/Pictures/Screenshots, on linux 6.3 Revert "ext4: Stop providing .writepage hook", android gallery app can read /storage/emulated/0/Pictures/Screenshots/Screenshot_20230510-130020.png thumbnail, linux 6.4 removed .writepage hook, android gallery unable read thumbnail. 2023-05-10 2:36 GMT+08:00, Theodore Ts'o <tytso@xxxxxxx>: > On Mon, May 08, 2023 at 10:02:27PM -0700, Eric Biggers wrote: >> On Tue, May 09, 2023 at 01:51:08AM +0800, youling257 wrote: >> > I using linux mainline kernel on android. >> > https://github.com/youling257/android-mainline/commits/6.4 >> > https://github.com/youling257/android-mainline/commits/6.3 >> > "ext4: Stop providing .writepage hook" cause some android app unable to >> > read storage/emulated/0 files, i need to say android esdfs file system >> > storage/emulated is ext4 data/media bind mount. >> > I want to ask, why android storage/emulated need .writepage hook? >> >> "esdfs" doesn't exist upstream, so linux-ext4 can't provide support for >> it. >> >> Also, it doesn't exist in the Android Common Kernels either, so the >> Android team >> cannot help you either. > > The problem with esdfs is that it's based on the old stackable file > system paradigm which is filled with races and is inherently > unreliable (just for fun, try running fsstress on the upper and lower > file systems of a stackable file system simultaneously, and watch the > kernel crash and burn). For that reason, some number of us have been > working for a while to eliminate the need for stacking file systems, > such as sdcardfs. esdfs, etc. from the Android kernel. > > The other thing I would add is that upstream has been working[1] on > getting rid of writepage function. So out-of-tree file systems are > going to need to adapt --- or die. > > [1] https://lore.kernel.org/all/20221202102644.770505-1-hch@xxxxxx/ > > It looks like esdfs is coming from the Chromium kernel? The latest > Chromium kernel I can find is 5.15 based, and it has esdfs in it. I'm > sad to see that esdfs hasn't been removed from the Chromium kernel > yet, and replaced with something more stable and reliable, but maybe > we can find someone who is more familiar with the Chromium kernel to > comment. > > Cheers, > > - Ted >
