Hello. Thank you for your involvement in this problem. My goal is to make ubuntu better. I accidentally encountered this incident in a real context. I knew that changing partition size is risky and impossible with a partition in use. That's why I duplicated it on an external disk. I found that the problem was reproducible. As the partition size was around 300 GiB, this took a long time. I managed to make a 40 GB test game. I was then able to reproduce the incident on 12 partitions.
I think I eliminated the material cause by doing the tests - Badblocks with a partition making up the entire disk. - Writing single sectors on approximately 95% of the disk space then re-reading with control of what is read is indeed what is expected. - Impossible to reproduce the incident if using the ext3 format - Impossible to reproduce the incident in the same session. A boot or a disconnection must take place for each incident. - Unable to carry out the incident in version 18.04.03 My diagnosis is that there is a functioning problem in the hard drive application link when the UAS driver is used. I worked as much as possible to reduce the size of the partition so that the execution times were acceptable. Now, I cause the incident systematically with an 8 GB partition. I do not know how to do less despite all the possible tests. I find it important to diagnose the problem to avoid that the future version 20.04 also have this behavior. I don't know if it's in the UAS module, the resize2fs module or maybe the mount module. You will find attached a file containing the mode of realization of the incident with 1) a script making 250 files of 30 Mio. 2) a script formatting the partition and transferring the files then deleting the first files. it seems to me that this is the key element in the making of the incident. 3) A script doing the size reduction. Another file contained resulted from an execution. I was able to do the incidents with the following quantities of files: 250 - 150 250 - 125 200 - 125 .... 176 - 102 I cannot produce the incident with the couple 174-100. This seems to me to be a problem of volumetry that UAS treats badly. I remain available to put the trace options that you will advise me. I am ready to open a new problem with the mount module and the UAS module because there is not the same function as in version 18.04.3 for the management of logical partitions which are not in the same order as the physical structure. The UAS module is now automatically disabled. It's probably better this way. I use google translation to answer you Thanks. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu. https://bugs.launchpad.net/bugs/1860917 Title: uas_eh_abort_handler uas-tag inflight OUT Status in e2fsprogs package in Ubuntu: New Bug description: 591/5000 Hello To try to understand this incident ( https://bugs.launchpad.net/ubuntu/+source/gpart/+bug/1857914 ) which systematically occurs in version 19.10 and which I cannot (yet?) reproduce in version 18.04.03, I made a test game. Using this test game consisting only of cp and diff commands, I caused a similar problem. The first visible consequence which seems serious to me: The copied file is not identical to the sending file. It seems that the blocks are shifted. It would be desirable for the user to be warned that the written files have become incorrect. Thank you for your advice. Journalctl says only janv. 26 13:29:35 a kernel: EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null) janv. 26 13:30:12 a kernel: sd 6:0:0:0: [sdb] tag#16 uas_eh_abort_handler 0 uas-tag 17 inflight: OUT janv. 26 13:30:12 a kernel: sd 6:0:0:0: [sdb] tag#16 CDB: Write(10) 2a 00 00 0f ec 00 00 04 00 00 janv. 26 14:22:48 a kernel: EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null) a@a:~$ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1860917/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
