On Tue, Jan 9, 2018 at 10:09 AM, Mark Millard <markmi_at_dsl-only.net> wrote: > > On 2018-Jan-8, at 1:15 AM, blubee blubeeme <gurenchan at gmail.com> wrote: > > > On Mon, Jan 8, 2018 at 3:20 PM, Mark Millard <markmi at dsl-only.net> > wrote: > >> [The involvement of sysutils/fusefs-simple-mtpfs > >> and sysutils/fusefs-libs and multimedia/libmtp > >> in order to use the Media Transfer Protocol (MTP) > >> against the LG v30 likely explains much of the > >> performance difference vs. local UFS file > >> systems. I provide some related notes.] > >> > >> blubee blubeeme gurenchan at gmail.com wrote on > >> Mon Jan 8 05:17:24 UTC 2018 : > >> > >> [Note: the original was in a reply to a Jon Brawn > >> post. I've merged it back with my post.] > >> > >> > On 2018-Jan-7, at 11:46 AM, Mark Millard <markmi at dsl-only.net> > wrote: > >> > > >> >> On 2018-Jan-7, at 10:23 AM, blubee blubeeme <gurenchan at gmail.com> > wrote: > >> >> > >> >> > >> >> > >> >>> On Mon, Jan 8, 2018 at 1:41 AM, Mark Millard <markmi at > dsl-only.net> wrote: > >> >>> > >> >>>> On 2018-Jan-7, at 7:50 AM, blubee blubeeme <gurenchan at gmail.com> > wrote: > >> >>>> > >> >>>>> I ran this test and here's some results. > >> >>>>> gstat -pd images: > >> >>>>> > >> >>>>> 18GB file from laptop to phone: https://imgur.com/a/7iHwv > >> >>>>> 18GB file from laptop to ssd: https://imgur.com/a/40Q6V > >> >>>>> multiple small files from laptop to phone: > https://imgur.com/a/B4v4y > >> >>>>> multiple small files from laptop to ssd: > https://imgur.com/a/mDiMu > >> >>>>> > >> >>>>> The files are missing timestamps but the originals were taken > with scrot and have timestamps available here: https://nofile.io/f/ > mzKnkpM9CyC/stats.tar.gz2 > >> >>>>> > >> >>>>> as far as why there's such high deletions? I can't say I'm only > using cp. > >> >>>> > >> >>>> I assume that md99 is for a file-based swap-space, such as > >> >>>> via /var/swap0 file. (As a side note I warn about bugzilla > >> >>>> 206048 for such contexts.) Otherwise please describe how > >> >>>> md99 is created. (Below I assume the swap-space usage of > >> >>>> md99.) > >> >>>> > >> >>>> The only other device that your pictures show is your > >> >>>> NVMe device nvd0. > >> >>>> > >> >>>> No picture shows a device for the LG v30 when it is mentioned > >> >>>> above as being copied to or from. How is it that there is no > >> >>>> mounted device shown for the LG v30? > >> >>>> > >> >>>> No picture shows a device for the SSD when it is mentioned > >> >>>> above as being copied to or from. How is it that there > >> >>>> is no mounted device shown for the SSD? > >> >>>> > >> >>>> Without a device displayed for the LG-v30/SSD there is nothing > >> >>>> displayed for its reads or writes. This makes the gstat -pd > >> >>>> useless. > >> >>>> > >> >>>> May be the p needs to be omitted for some reason? gstat -d > >> >>>> > >> >>>> === > >> >>>> Mark Millard > >> >>>> markmi at dsl-only.net > >> >>> > >> >>> You are correct that md99 is a file backed swap disk, I am aware of > the issues but I had to test some things out. > >> >>> > >> >>> Those tests earlier was a huge time sink. > >> >>> Here's the dmesg output from earlier: > >> >>> . . . > >> >>> ---------------------------------- > >> >>> > >> >>> I don't know why gstat isn't showing the info u are looking for. > >> >>> > >> >>> You said earlier that something was getting deleted, > >> >>> I don't know what could be causing that. > >> >> > >> >> Those "deletes" are more commonly called TRIM on SSD's. > >> >> FreeBSD called them, BIO_DELETE as I remember. > >> >> > >> >> Those deletes have nothing to do with umounting, deleteing > >> >> devices, etc. > >> >> > >> >>> I've provided tons of debug out, logs, pciconf, dmesg, etc... > >> >>> Even say forget the mobile device and go from > >> >>> zpool > >> >> > >> >> From which I've not been able to figure out the kind of > >> >> information that I'm looking for. > >> >> > >> >> Just because a device is present, does not mean that it > >> >> is available as a file system. I'm more interested in > >> >> how the file systems are made available --or if some > >> >> non-file system way of working is involved. > >> >> > >> >>> Are you saying that there's something misconfigured on my end? > >> >>> What other info do you need me to provide to try to figure out > >> >>> what's going on or why I'm getting these transfer rates? > >> >> > >> >> I'm saying I still can not tell how you make the SSD or the > >> >> LGv 30 available to FreeBSD (mount?). Or why no matching > >> >> mounted device shows up in gstat's display. > >> >> > >> >> If you wish to keep trying to help me help you, . . . > >> >> > >> >> Please show how you make the file system on the > >> >> SSD available to FreeBSD: what FreeBSD commands make > >> >> the device available for use. (I'd guess that mount > >> >> is used or that something like /etc/fstab is used > >> >> to do mounts more implicitly.) > >> >> > >> >> Please show how you make the LG v30 available to FreeBSD: > >> >> what FreeBSD commands make the device available for > >> >> use. (I'd guess that mount is used or that something like > >> >> /etc/fstab is used to do mounts more implicitly.) > >> >> > >> >> (I would expect these are mount commands, or at least > >> >> involve mount commands/calls. Some of the following makes > >> >> that presumption.) > >> >> > >> >> For each of those: with the device available show the > >> >> output of: > >> >> > >> >> mount > >> >> > >> >> and of: > >> >> > >> >> df -m > >> >> > >> >> Similarly, show the exact commands used to make the > >> >> copies to and from the SSD. Show the exact commands > >> >> used to make the copies to and from the LG v30. > >> >> > >> >> (You can for now stop the commands early or just > >> >> not start any that would take a long time.) > >> >> > >> >> I'm looking for a way to get information similar to > >> >> what I expected gstat to show. I'd expect a mounted > >> >> file system but may be something else is involved? > >> > > >> [Extracted from a reply to a Jon Brawn post.] > >> > _at_Mark Millard > >> > I use sysutils/simple-mtpfs to mount the android device. > >> > when I mount the phone through USB this is the relevant section: > >> > /dev/fuse 356311 78912 277398 22% > >> > /mnt > >> > > >> > That's the most complicated mount process that I use, > >> > for the ssd it's just a simple mount /dev/device /mnt > >> > relevant output: > >> > /dev/da0 923913 121450 728550 > 14% > >> > /mnt > >> > > >> > Can you tell me what information you're looking for so that I can > gather it > >> > all up and send it. > >> > >> > >> I do not find a /usr/ports/sysutils/simple-mtpfs . But I > >> do find: > >> > >> # ls -lTd /usr/ports/sysutils/*simple* > >> drwxr-xr-x 3 root wheel 512 Sep 23 19:51:59 2017 > /usr/ports/sysutils/fusefs-simple-mtpfs > >> > >> And that was very important to know. > >> > >> . . . > > > > > > OK, forget the android specific usb issues for now; > > there is quite a few layers of crud between the laptop and the android > device. > > > > I have this SSD. > > > > What are some tests that you'd like to run to test the speeds > > on my end? > > Returning to just the SSD context. . . > > Because your pictures were missing the SSD for some > reason, we first need to figure out if and how to > see the SSD activity levels, such as via gstat. > > For now I focus on just that. > > You provided as information about the SSD: > > /dev/da0 923913 121450 728550 14% > /mnt > > which is from "df -m". But I'd also asked for "mount" > output. As an example for one of my contexts: > > # mount > /dev/gpt/FBSDFSSDroot on / (ufs, NFS exported, local, noatime, > soft-updates) > devfs on /dev (devfs, local, multilabel) > > Note the types of information displayed, which is very different from > what df -m reports. > > ( /dev/gpt/FBSDFSSDroot is a label reference instead of a physical > device and partition/slice number notation.) > > After mounting the partition/slice from the SSD, can you show the > mount command's description of the partition/slice that you mounted? > > (Actually, your "df -m" output does not show a partition/slice > notation. I'm not sure what to make of that.) > > There is another view of things that can be handy. . . > (output is from one of my example contexts) > > # gpart show -p da0 > => 40 937703008 da0 GPT (447G) > 40 1024 da0p1 freebsd-boot (512K) > 1064 746586112 da0p2 freebsd-ufs (356G) > 746587176 31457280 da0p3 freebsd-swap (15G) > 778044456 159383552 da0p4 freebsd-swap (76G) > 937428008 275040 - free - (134M) > > Note: Normally da0 would not show up in a mount > line, instead it would be /dev/da0p2 for the UFS > partition being mounted in my example. > > Your da0 might not show GPT or any other partition > or slice structure (given the "df -m" output that > you listed). > > (If zfs is involved, there may be better commands > for some types of information above, but I've minimal > ZFS background knowledge. You may have to explain > your configuration if ZFS is in use on the SSD.) > > With that much information (if non-ZFS), I know what > I expect to be listed in gstat -pd and in gstat -d . > > It is possible to use just: > > gstat -d > > and the same device and its partitions will show up > multiple times for different ways they can be > accessed. For example: > > dT: 1.073s w: 1.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| fd0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da1 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da2 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| cd0 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da0p1 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da0p2 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da0p3 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da0p4 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| label/FBSDx64Cboot > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| gpt/FBSDFSSDboot > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| gpt/FBSDFSSDroot > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| gpt/FBSDFSSDswap > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| gpt/FBSDFSSDswap2 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da1p1 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da2p1 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da2p2 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da2p3 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| da2p4 > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| gpt/FBSDFSSDbkp > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| ufsid/<REPLACED> > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| gpt/FBSDFSboot > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| gpt/FBSDFSroot > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| ufsid/<REPLACED> > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| gpt/FBSDFBswap > 0 0 0 0 0.0 0 0 0.0 0 0 > 0.0 0.0| gpt/FBSDFSswap > > The sorter list from gstat -pd can be nicer to look at > when its content happens to be sufficient for ones > purpose at the time. Otherwise the fuller list can be > used, giving specific rates and such for individual > partitions. > > > The initial question for gstat seems to be: can we find the mounted > SSD partition/slice and/or the overall SSD device in the gstat output. > Can you check on that? If you find the partition and/or overall device, > can you show those lines so that I know what they look like? > > (gstat might not be an appropriate tool if the SSD is a ZFS-only > device.) > > === > Mark Millard > markmi at dsl-only.net > > > I didn't restart gstat between the tests... so It didn't update to show the devices after they were added. dT: 1.064s w: 1.000s filter: d L(q) ops/s r/s kBps ms/r w/s kBps ms/w %busy Name 0 0 0 0 0.0 0 0 0.0 0.0| nvd0 0 0 0 0 0.0 0 0 0.0 0.0| nvd0p1 0 0 0 0 0.0 0 0 0.0 0.0| nvd0p2 0 0 0 0 0.0 0 0 0.0 0.0| nvd0p3 0 0 0 0 0.0 0 0 0.0 0.0| nvd0p4 0 0 0 0 0.0 0 0 0.0 0.0| msdosfs/EFI 0 0 0 0 0.0 0 0 0.0 0.0| da0 0 0 0 0 0.0 0 0 0.0 0.0| ufsid/xxxx 0 0 0 0 0.0 0 0 0.0 0.0| msdosfs/TRANSCEND This is the current output for a simple USB device but this brings up a whole new slew of errors; not related to speed but of encodings.Received on Fri Jan 12 2018 - 16:41:14 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:14 UTC