On 2020-02-07 11:20, Nathan (PLUGAZ) wrote:
> On 2020-02-06 20:14, Matt Graham wrote:
>> The "filefrag" utility will
>> tell you how fragmented an individual file is. I don't see anything
>> about defragging tools for ext234 in portage/sys-fs/ but
> Defragging an ext4 filesystem is done with e4defrag
Putting the important stuff at the end is called "burying the lede" and
you're not supposed to do that. :-) What does e4defrag -c
/dev/whatever tell you? My ext4 filesystems are all either 0 or 1 frag
status, and the 1 frag was the one that's 87% full with a mix of file
sizes. Defragging is supposed to be necessary only if the frag status
goes over 30.
>>> Now this is running over an NFS link
>> What was the rsync displaying after 75 minutes?
>> 46,000 files seems like it should take a minute or so unless it had
>> to
>> transfer all the files in full.
> The volume on the server is mounted with noatime,nodiratime,noexec
> The export on the server is (rw,sync,no_root_squash,no_subtree_check)
OK, you may want to try async. I don't think it'll make much
difference.
> mount` shows the actual options as:
> rw,noexec,noatime,nodiratime,vers=4.2,rsize=1048576,
> wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,
> sec=sys,fsc,local_lock=none
> Both machines have their time synced.
This is probably fine. I couldn't use 4.2 for some reason, had to
leave it at 4.1, but I don't think this'll cause the problem you're
seeing.
> Reading files from the server to my desktop is as fast as I would
> expect a gigabit network to be. Writing large files to the network
> storage works as I expect. It's just all of these small files
> that are killing me.
I made an 8G ext4 LV on machine1, exported it via NFS, on machine2, I
did "mount -t nfs 192.168.1.20:/mnt/rsynctemp /mnt/other -o (the options
you had)" , then started rsyncing a 7.5G dir tree to /mnt/other from
machine2. It *crawled* and the bottleneck was file creation, not
fragmentation, since the filesystem had just been mkfs'ed. The
combination of NFS and ext4's write barriers makes creating a file at
least an order of magnitude slower than it would usually be. When the
LV is mounted with ext4 defaults, rsyncing a 10,000 file directory of
157M in size to an empty dir took 54 minutes. When the LV is mounted
with nobarrier, doing that took 2 minutes. (Curiously, the same
operation with the LV as ext3 is taking much longer even though ext3
doesn't do barriers. Of course, portage is compiling qtwebengine right
now, which is hogging the CPU.)
So: mount the thing with nobarrier if you want it to create many small
files faster. This means that if the power goes out, your data will get
corrupted. Your call. Or try running the rsync daemon on the NFS
server, since NFS is good for reading, good for writing, and horrible
for creating files? That'll show totally different network behavior
since it removes NFS's weirdnesses.
--
Crow202 Blog: http://crow202.org/wordpress
There is no Darkness in Eternity
But only Light too dim for us to see.
---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
https://lists.phxlinux.org/mailman/listinfo/plug-discuss