yashsingh1/xdaforums huggingface dataset:
[General Omni Discussion] bassmanitram:
After another freeze-free day I took the plunge with the internal storage - worked like a charm. Had to do the following (for any intrepid user who might wanna know). I dare say this is a slightly long way round but I wanted to use the android exFAT utilities to make sure that whatever happened was as compatible with the rest of android as possible:

Shutdown and removed external SD card (otherwise TWRP "Mount USB" kept mounting that instead on internal card)

Rebooted into recovery

Connected to Ubuntu 12.04 system with android-tools-adb package installed (available in standard deb repo), and exFat utils installed (see post 210)

On phone, tapped on Mount button, then on Mount USB

The internal SD card was now visible in Ubuntu. I copied all the contents to the Ubuntu system

Unmounted the SD Card from Ubuntu and tapped on Unmount in TWRP

Got back to the mount menu in TWRP - made sure "Internal Storage" was checked

On Ubuntu, at a command line entered the following:

adb shell
mount

Session looked like this

bartlett@famillebartlett:~$ adb shell
~ # mount
rootfs on / type rootfs (rw)
tmpfs on /dev type tmpfs (rw,seclabel,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,seclabel,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,seclabel,relatime)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
/dev/block/mmcblk0p11 on /emmc type vfat (rw,relatime,fmask=0000,dmask=0000,allow_utime=0022,codepage=cp437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)
/dev/block/mmcblk0p7 on /cache type ext4 (rw,seclabel,relatime,user_xattr,barrier=1,data=ordered)
~ #

noted the following line in the output

/dev/block/mmcblk0p11 on /emmc type vfat ...

returned to TWRP and UNchecked "Internal Strorage"

returned to Ubuntu and entered (still in adb shell!!):

mount
mkfs.exfat /dev/block/mmcblk0p11

(the mount was to ensure that /emmc was NOT mounted any longer)

Session looked like this:

~ # mount
rootfs on / type rootfs (rw)
tmpfs on /dev type tmpfs (rw,seclabel,nosuid,relatime,mode=755)
devpts on /dev/pts type devpts (rw,seclabel,relatime,mode=600)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,seclabel,relatime)
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
/dev/block/mmcblk0p7 on /cache type ext4 (rw,seclabel,relatime,user_xattr,barrier=1,data=ordered)
~ # mkfs.exfat /dev/block/mmcblk0p11
mkexfatfs 1.0.0
done.
File system created successfully.
~ #

When that finished, returned to TWRP mount menu and tapped on Mount USB

Returned to Ubuntu and copied all the backed up files onto the (newly visible) SD Card (which took about one tenth of the time of the backup!)

Unmounted the SD Card from Ubuntu AND WAITED TILL IT WAS FULLY UNMOUNTED

Tapped on Unmount in TWRP

Rebooted the phone

All appears to have gone fine. I am now exFAT-complete (and still with no freezes). Plans for kernel mount hacks are a fast disappearing memory (no doubt causing [MENTION=591147]Entropy512[/MENTION] endless relief: :D)
[General Omni Discussion] dimspace:
re-formatted external sd to exfat this morning. so far, touch wood, have had the phone playing for 2 hours on internal speaker.

didnt re-format internal

hmmm

(CM 11 Nightly)
[General Omni Discussion] NaminatoR1254jaime.sier:
Try moving a big file within the internal sd card and see if you can.

Enviado desde mi GT-I9100 mediante Tapatalk
[General Omni Discussion] Resync:
Is there a way to check what Filesystem the internal uses?

On Windows if possible?

My external is exfat.
[General Omni Discussion] jeffsf:
adb shell mount

---

Posted from whatever phone booted today
[General Omni Discussion] kl0ndike:
exfat is not fully supported in cm 11/ very sad

http://xdaforums.com/showpost.php?p=51050302&postcount=802
[General Omni Discussion] lerkin:
Issues you listed are minor, compared to music bug. Repartition your internal storage to have more space for apps and install them all on internal storage.
[General Omni Discussion] kl0ndike:
The inability to move apps to SD are not minor for me.
[General Omni Discussion] FrodgE:
Another option is to mount the internal SD as USB mass storage from TWRP recovery and then check the device properties in windows explorer.
[General Omni Discussion] dimspace:
Based on what? Your own forum post?

I have external as exfat, (not internal yet) and have no problem with a2sd. Just tested, rebooted, all fine.
[General Omni Discussion] Entropy512:
It looks like that's related to handling a command to force an fsync() of an entire directory. Without that, FSYNCDIR just gets ignored I think.

If anything it would increase timing stress since instead of doing nothing, it would flush an entire directory.

The other commit about direct access implies it's only for certain special cases which I don't think apply here, but who knows - there could be a chance.

I finally remembered to push out test kernels. First up - one with the two upstream commits from gustavo's kernel discussed a few pages back. If people want me to relink the commits let me know. See attachments for this post.
[General Omni Discussion] Entropy512:
Next up, these have the big mega-squash from gerrit that has been discussed (will add gerrit link later...)
[General Omni Discussion] kl0ndike:
The Move to SD Card action moves app to the Internal storage and not to Ext. SD.

As you said, you didn't formated the internal storage. So, of course, everything would work because your internal SD is FAT32.
[General Omni Discussion] dimspace:
Yes. Sorry. I had only just woken up when I replied. :)

my bad. Brain was asleep
[General Omni Discussion] A_Kirsh:
I have a small and not-entirely-unrelated question: I've read in several places that our i9100 supports 64GB MicroSDXC cards, but only if formatted to FAT32. Can anyone confirm this? I wouldn't want to buy one of those cards just to be unable to play music from it....
[General Omni Discussion] Wing2468:
It does support 64GB card. Both my i777 & i9100 are using it. Not 100% sure it has to be formatted to FAT32. I formatted them using FAT32 because my i777 (running CM 10.1.3) couldn't recognize the default exFAT. HTH.
[General Omni Discussion] Entropy512:
stock I9100 lacks exFAT - Omni uses fuse-exfat to support it on all devices
[General Omni Discussion] A_Kirsh:
My current SD card is 32GB and it's running great with exFAT on CM11. I personally don't have a filesystem preference, it just happens to work around the music bug. Could you please try using it in exFAT on CM11 or a derived ROM?
[General Omni Discussion] cgx:
I tested both kernels and see no improvement :(

Test results here:

Device i9100

from adb root shell while phone screen off:

# mount

...snip...

/dev/block/vold/179:9 /mnt/media_rw/sdcard1 vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1023,gid=1023,fmask=0007,dmask=0007,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0

/dev/block/vold/259:3 /mnt/media_rw/sdcard0 vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1023,gid=1023,fmask=0007,dmask=0007,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0

...

# ls /sdcard/testfile1 -l

-rwxrwx--- root sdcard_r 500000000 2014-02-07 21:57 testfile1

# cp /sdcard/testfile1 extSdCard/

omni 13th mar stock kernel:

# uname -a

Linux localhost 3.0.64-OMNI-g9de8607 #1 SMP PREEMPT Thu Mar 13 16:53:57 CET 2014 armv7l GNU/Linux

run 1: copy stopped at 0 bytes!

run 2: copy stopped at 4849664 bytes

run 3: copy stopped at 56885248 bytes

kernel-omni-4.4-20140310-i9100-upstream.zip:

# uname -a

Linux localhost 3.0.64-CM-g0b7c89b #3 SMP PREEMPT Mon Mar 10 20:33:42 EDT 2014 armv7l GNU/Linux

run 1: copy stopped at 148635648 bytes

run 2: copy stopped at 2883584 bytes

run 3: copy stopped at 5898240 bytes

kernel-omni-4.4-20140310-i9100-bigsquash.zip:

# uname -a

Linux localhost 3.0.64-CM-gd27ae45 #2 SMP PREEMPT Mon Mar 10 19:19:44 EDT 2014 armv7l GNU/Linux

run 1: copy stopped at 0 bytes!

run 2: copy stopped at 4587520 bytes

run 3: copy stopped at 5242880 bytes
[General Omni Discussion] Entropy512:
ok, maybe I'm barking up the wrong tree here.

Considering that all other FUSE implementations work fine, it really seems to be something in the "new" rich permissions code. (which, coincidentally, is NOT used on ANY Nexus device so probably isn't very well tested...)

But why does this only break on certain devices?

grumble I hate bugs like this
[General Omni Discussion] NaminatoR1254jaime.sier:
Considering the kernels you built, can you build ones with the bind command from [MENTION=3590131]bassmanitram[/MENTION] ?

Enviado desde mi GT-I9100 mediante Tapatalk
[General Omni Discussion] cgx:
ok, I attached both sdcard daemons (internal and external) to gdb and ran the file copy test again.

When the copy hung, breaking to gdb and doing info threads shows:

(gdb) info threads

Id Target Id Frame

3 Thread 4478 read () at bionic/libc/arch-arm/syscalls/read.S:9

2 Thread 4477 read () at bionic/libc/arch-arm/syscalls/read.S:9

* 1 Thread 4467 read () at bionic/libc/arch-arm/syscalls/read.S:10

(gdb) info threads

Id Target Id Frame

3 Thread 4475 read () at bionic/libc/arch-arm/syscalls/read.S:9

2 Thread 4474 read () at bionic/libc/arch-arm/syscalls/read.S:9

* 1 Thread 4468 read () at bionic/libc/arch-arm/syscalls/read.S:10

If I'm reading this correctly, it means that the worker threads are waiting for fuse request in line 1545

ssize_t len = read(fuse->fd, handler->request_buffer, sizeof(handler->request_buffer));

and the inotify thread is also waiting for inotify event in read()

If the hang was caused by read from sdcard, it should be pread64 syscall instead, right?
[General Omni Discussion] D4rK.F0rcE:
Apparently, [MENTION=1228651]fusionjack[/MENTION] has managed to bring exFAT support to SlimSaber Rom (which is based on SlimKat). Before I upgrade, I would like to ask some questions concerning formatting internal and external SD cards to exFAT.

1. Is it possible to run a CWM or TWRP backup of the FAT32 formatted internal SD card and restore the same backup on the exFAT formatted internal SD card? How about titanium backups?

2. Is it possible to format the internal SD Card from the recovery mode? if yes, what happens to the OS? I mean, if there is nothing on the internal SDcard, which rom will start after I reboot?! Will formatting the internal SD card to exFAT affect the recovery mode? Will the recovery mode (CWM or TWRP) recognize exFAT SD cards (ext and internal)?

Thanks in advance,

D4rK.F0rcE
[General Omni Discussion] lerkin:
After two days of testing I disappointed with exfat. Have some issues with one navigation software doesn't see maps anymore.

By the way I have a problem restoring backups from exfat formatted external sdcard (system partition restore fails in CWMR).
[General Omni Discussion] Spyr0s:
Both Sygic and Navigon work fine here with internal and external storage exfat formatted.
[General Omni Discussion] lerkin:
I use navitel (russian stuff)
[General Omni Discussion] Spyr0s:
Hm installed Navitel from Play Store, tried to open it and i get a message that some files are missing....
[General Omni Discussion] cgx:
Yay, got a trace with the file copy hanging!

pid 5050 is the first worker thread of /sdcard

pid 4594 is the second worker thread of /extSdCard

... snip a lot of writes/reads ...

[pid 4594] write(2, "[1] WRITE 0x1f25188(5) 65536@151"..., 39) = 39

[pid 4593] write(2, "[0] WRITE 0x1f25188(5) 65536@151"..., 39) = 39

[pid 5051] write(2, "[1] READ 0xa62778(15) 131072@152"..., 39) = 39

[pid 4594] write(2, "[1] WRITE 0x1f25188(5) 65536@151"..., 39) = 39

[pid 4593] write(2, "[0] WRITE 0x1f25188(5) 65536@151"..., 39) = 39

[pid 5051] write(2, "[1] READ 0xa62778(15) 131072@152"..., 39) = 39

[pid 4594] write(2, "[1] WRITE 0x1f25188(5) 65536@152"..., 39) = 39

[pid 4593] write(2, "[0] WRITE 0x1f25188(5) 65536@152"..., 39) = 39

[pid 5051] write(2, "[1] READ 0xa62778(15) 131072@152"..., 39) = 39

[pid 4594] write(2, "[1] WRITE 0x1f25188(5) 65536@152"..., 39) = 39

[pid 4593] write(2, "[0] WRITE 0x1f25188(5) 65536@152"..., 39) = 39

[pid 5050] write(2, "[0] READ 0xa62778(15) 131072@152"..., 39) = 39

[pid 5050] write(2, "*** REPLY FAILED *** 2\n", 23) = 23
[General Omni Discussion] lerkin:
Yep, went back to 10.2 with exfat - still Navitel doesnt work. Reformated to fat32 - works.
[General Omni Discussion] Entropy512:
Thanks for the info.

This is getting really weird, because it implies that the sdcard daemon is itself not hanging. All of the threads are blocking either:

1) Waiting for an inotify event (the inotify thread)

2) Waiting for a FUSE request to come from the FUSE event queue (/dev/fuse)

this is weird... Looks like the daemon is just sitting there waiting for a request and it's not getting one.

Question - when things start going badly, is it just that file affected, or do all file accesses to the sdcard get hosed?

Also, when it's broken - are you able to access the control filesystem described in https://android.googlesource.com/ke...ndroid-3.8/Documentation/filesystems/fuse.txt ?

Specifically, are there any "waiting" requests in /sys/fs/fuse/connections when it's hung?
[General Omni Discussion] cgx:
See also my previous post http://xdaforums.com/showpost.php?p=51082621&postcount=239

It shows the actual cause... sdcard has problems talking to fuse, so the writev() back to fuse code in kernel is failing for some reason...

And yes, it's only the single file failing. The daemon is quite happy to continue next operation after this.

update: /sys/fs/fuse/connections/ shows two connections:

20 and 21

fs/fuse/connections/20/waiting <

0

/fs/fuse/connections/21/waiting <

1

btw: I'm on irc also, if it might be easier to do live debugging
[General Omni Discussion] Entropy512:
Weird. Somehow I missed that previous post.

Timezone issues seem to be a bit of a headache here with catching each other on IRC. :) (I was kind of exhausted Sunday so I didn't do much at all... I've been pretty burned out for a variety of non-Android-related reasons lately.)

Seems like something isn't properly recovering from an error on the read... I'll need to do some grepping tonight.

errno 23 is:

"23 ENFILE +Too many open files in system"

So time to figure out why this only occurs on our device... Either stuff is getting "stuck open" or some limit somewhere is way too low. It would explain why the kernel gets hung - it seems like Fuse is trying to issue a response to the kernel, it fails, the kernel never gets a response, and gets stuck.

Note: Sometimes errnos can be confusing because someone didn't use the correct errno on return. But at least looking through what would cause a 23 now hints as to where to look. :)

Hmm, what does dmesg say when this happens? By any chance, something like "VFS: file-max limit reached" (looking at http://stackoverflow.com/questions/3991223/how-does-linux-file-descriptor-limits-work )
[General Omni Discussion] cgx:
I have also been mostly offline for the weekend...

Anyway, the errno is actually 2 (ENOENT). 23 is the return value of the write of the error message(23 chars) to stderr. (Sorry about my confusing log format, used strace for quick capture. Don't know how to catch the fuse trace messages properly)

I think ENOENT here is even more weird as it does not seem to be a regular errno value from any write operations.

Dmesg is not helpful here. Nothing is consistently printed when the error happens
[General Omni Discussion] Entropy512:
Whoops. Thanks for the clarification.

Sounds like this evening (if I have time, need to drive out to run an errand...) will be spent figuring out what could cause an ENOENT on write.

It kind of explains though how the sdcard daemon seems to go into la-la land. It's failing to write a reply back to the kernel FUSE daemon - so the kernel just sits there waiting for the operation to complete and never gets a response because the attempt to respond to it failed.

I wonder if libfuse normally uses some sort of retry mechanism here...
[General Omni Discussion] cgx:
Good luck :)

I think this is the relevant part from libfuse (fuse_kern_chan.c)

static int fuse_kern_chan_send(struct fuse_chan *ch, const struct iovec iov[],
size_t count)
{
if (iov) {
ssize_t res = writev(fuse_chan_fd(ch), iov, count);
int err = errno;

if (res == -1) {
struct fuse_session *se = fuse_chan_session(ch);

assert(se != NULL);

/* ENOENT means the operation was interrupted */
if (!fuse_session_exited(se) && err != ENOENT)
perror("fuse: writing device");
return -err;
}
}
return 0;
}

So it looks like operation was interrupted, hmm...

I did an experiment though: When the reply failed, I tried to repeat the writev() in a loop up to 1000 times, but it did not go through.
[General Omni Discussion] Red_Vex:
You're the only Hope to risolve this bug. Good works
[General Omni Discussion] Entropy512:
It looks like libfuse doesn't do a retry on writev(), at least not here.

However it does pass the error up, so I'm going to see what ntfs-fuse does in this case. (in the case of sdcard fuse - it just passes NO_STATUS anyway which I think is a bug)
[General Omni Discussion] Entropy512:
At least on my first attempt to trace "up" from a failure of fuse_kern_chan_send - it seems like the error gets passed up quite a few layers, but does eventually just go "nowhere" and doesn't seem to get handled in any way.

I could have misread things though... There's probably at least 4-5 layers of calls in play here.
[General Omni Discussion] D4rK.F0rcE:
As long as [MENTION=591147]Entrophy512[/MENTION] is (hopefully) trying to figure out what causes the bug, I would like to highlight the post of [MENTION=5205331]kulwinderjj[/MENTION].

Whenever the music stops, run pkill sdcard in the terminal. Here a small tutorial:

1. search for "android terminal emulator" in the play store and install it

2. once installed, run the app, type in "su" and click on enter

3. you should be asked for root rights, accept

4. type in "pkill sdcard" and wait

5. music should continue playing

For me, this is working and an temporary workaround, credits to [MENTION=5205331]kulwinderjj[/MENTION]

Keeping my fingers crossed for those who are trying to find this nasty bug! :)
[General Omni Discussion] Red_Vex:
I'm not using listen Music but How resolve copy of Big file without Take out the sd card
[General Omni Discussion] D4rK.F0rcE:
try the same procedure, maybe it works,too.
[General Omni Discussion] FrodgE:
This probably doesn't help at all but occasionally peoples observations are useful when getting your head around things like this...

I used to get this issue pretty regularly while listening to music when I had my internal & external SD cards formatted to fat32. Since formatting to exfat it's been fine. HOWEVER, I have noticed occasionally during playback that the music will briefly pause and then continue on. This is a new characteristic since running Omni/KK. Initially I put this down to bad reception since I normally stream with Google Music but it also happens when using wifi and local media. Could this suggest that the source of the "interruption" is still there but the different fuse implementation/driver handles it better ?

---------- Post added at 12:21 AM ---------- Previous post was at 12:16 AM ----------

hehe it's fun (annoying?) issues like this that make me want to set up my linux or OSX installation to build the Android source and go tinkering... but I barely get enough sleep as it is so doing that wouldn't help ! :D
[General Omni Discussion] Entropy512:
Something I just thought of...

Back when Chainfire was trying to figure this out, I know he played around with changing MAX_READ and MAX_WRITE - in that case I think he increased them to reduce the number of calls made but I'm not sure. He's on vacation so I can't ask him.

What happens if you reduce MAX_READ in sdcard.c to half its value or even 1/4 its value?

Actually... hmm, in your trace, all of the reads/writes are half of MAX_READ and MAX_WRITE. I wonder what the read/write sizes of an exFAT trace are.
[General Omni Discussion] lerkin:
It happens on file copying, it freezes for a second, then resumes. on exfat.
[General Omni Discussion] D4rK.F0rcE:
did you format internal and external sd card? do you experience any (other) bugs after formatting? Like cpu going crazy, apps not working etc.
[General Omni Discussion] cgx:
Tried reducing MAX_READ, the operation reverted to 4k blocks, but it still failed.

But I've been trying other things and look at this...

I added more debug prints and looks like something (pread64?) is smashing unique! (among other things)

The reason we are getting errno 2(ENOENT) from fuse is because fuse cannot find the request in queue as unique value has been corrupted

[pid 2749] write(2, "[0] READ 0x18f0158(5) 131072@35782656 unique=a835\n", 50) = 50

[pid 2749] write(2, "[0] READ after pread64 0x18f0158(5) 131072@35782656 unique=a835\n", 64) = 64

[pid 2749] write(2, "[0] READ after fuse_reply 0x18f0158(5) 131072@35782656 unique=a835\n", 67) = 67

[pid 2561] write(2, "[1] WRITE 0x11fd900(5) 65536@35651584 unique=6509\n", 50) = 50

[pid 2561] write(2, "[1] WRITE 0x11fd900(5) 65536@35717120 unique=650a\n", 50) = 50

[pid 2750] write(2, "[1] READ 0x18f0158(5) 131072@35913728 unique=a836\n", 50) = 50

[pid 2750] write(2, "[1] READ after pread64 0x18f0158(5) 131072@35913728 unique=a836\n", 64) = 64

[pid 2750] write(2, "[1] READ after fuse_reply 0x18f0158(5) 131072@35913728 unique=a836\n", 67) = 67

[pid 2561] write(2, "[1] WRITE 0x11fd900(5) 65536@35782656 unique=650b\n", 50) = 50

[pid 2561] write(2, "[1] WRITE 0x11fd900(5) 65536@35848192 unique=650c\n", 50) = 50

[pid 2749] write(2, "[0] READ 0x18f0158(5) 131072@36044800 unique=a837\n", 50) = 50

[pid 2749] write(2, "[0] READ after pread64 0x18f0158(5) 131072@36044800 unique=a837\n", 64) = 64

[pid 2749] write(2, "[0] READ after fuse_reply 0x18f0158(5) 131072@36044800 unique=a837\n", 67) = 67

[pid 2561] write(2, "[1] WRITE 0x11fd900(5) 65536@35913728 unique=650d\n", 50) = 50

[pid 2561] write(2, "[1] WRITE 0x11fd900(5) 65536@35979264 unique=650e\n", 50) = 50

[pid 2750] write(2, "[1] READ 0x18f0158(5) 131072@36175872 unique=a838\n", 50) = 50

[pid 2750] write(2, "[1] READ after pread64 0x18f0158(5) 131072@18446726481519312887 unique=fffffffffeffdfb7\n", 88) = 88

[pid 2750] write(2, "*** REPLY FAILED *** 2 unique=fffffffffeffdfb7\n", 47) = 47

[pid 2750] write(2, "[1] READ after fuse_reply 0x18f0158(5) 131072@18446726481519312887 unique=fffffffffeffdfb7\n", 91) = 91

code in handle_read for reference:

TRACE("[%d] READ %p(%d) %u@%llu unique=%llx\n", handler->token,
h, h->fd, size, offset, unique);
if (size > sizeof(handler->read_buffer)) {
return -EINVAL;
}
res = pread64(h->fd, handler->read_buffer, size, offset);
if (res < 0) {
return -errno;
}
TRACE("[%d] READ after pread64 %p(%d) %u@%llu unique=%llx\n", handler->token,
h, h->fd, size, offset, unique);
fuse_reply(fuse, unique, handler->read_buffer, res);
TRACE("[%d] READ after fuse_reply %p(%d) %u@%llu unique=%llx\n", handler->token,
h, h->fd, size, offset, unique);
return NO_STATUS;
[General Omni Discussion] Entropy512:
wtf?

both offset and unique are getting really clobbered by pread64... but unique is never passed to pread64 and offset is NOT passed as a pointer so it shouldn't be getting clobbered...

but it is???

WTF?

On the other hand - https://android.googlesource.com/pl...0b435a3f35795600654e9705f4b3fbbcc427a9d^!/#F0 is making changes in EXACTLY this location in the code. I probably should have tested that patch sooner, but the commit message is misleading and implies it should only matter in "special" cases.

Either way something is really weird here.
[General Omni Discussion] cgx:
Tried the patch. Did not help :(

Looks like there is some variation on the value that overwrites offs/unique

[pid 5496] write(2, "[1] READ 0x57a188(5) 131072@134873088 unique=40a\n", 49) = 49

[pid 5496] write(2, "[1] READ after pread64 0x57a188(5) 131072@18437736874454810623 unique=fffffffffeffdff7\n", 87) = 87

[pid 5496] write(2, "*** REPLY FAILED *** 2 unique=fffffffffeffdff7\n", 47) = 47

[pid 5496] write(2, "[1] READx after fuse_reply 0x57a188(5) 131072@18437736874454810623 unique=fffffffffeffdff7\n", 91) = 91