Bit Torrent Bit torrent performs 16KB random reads/writes. The 16KB writes cause read-modify-write overhead. The read-modify-write overhead can reduce performance by a factor of 16 with 128KB record sizes when the amount of data written exceeds system memory. This can be avoided by using a dedicated dataset for bit torrent downloads with recordsize=16KB.
When the files are read sequentially through a HTTP server, the random nature in which the files were generated creates fragmentation that has been observed to reduce sequential read performance by a factor of two on 7200RPM hard disks. If performance is a problem, fragmentation can be eliminated by rewriting the files sequentially in either of two ways:
The first method is to configure your client to download the files to a temporary directory and then copy them into their final location when the downloads are finished, provided that your client supports this.
The second method is to use send/recv to recreate a dataset sequentially.
In practice, defragmenting files obtained through bit torrent should only improve performance when the files are stored on magnetic storage and are subject to significant sequential read workloads after creation.
Do not set Pre-allocated disk space if you are using ZFS as your filesystem as ZFS does not support fallocate 有在 ZFS 文件系统上不要开启 Qbittorrent 预分配空间的说法，原因是 ZFS 不支持 fallocate
这几天尝试了一下，Sonarr 还是不够灵活，不能手动筛选，字幕组的命名不都是那么规范的。之前很长一段时间是在 bangumi 和 dmhy 上筛选后输出 RSS，然后再放 TTRSS 里面做归纳，Flexget 再监控 TTRSS 输出的 RSS 链接推送到 qBittorrent 自动下载，弹弹play 负责媒体库和弹幕。
这样的缺点就是新一个季度的时候得花时间去整理一下，管理也不是十分方便。
但是使用了 Sonarr 之后，还是觉得拖拉机的方案也足够灵活和好用。
又是前端“加密”的神奇玩意儿
门寒花不弃，白头觅旧居；
半生他乡客，叶落归乡泥。
TT600 200左右
TT685 350 左右
V860iiN 500 左右
笔记 https://ma.ttias.be/force-redirect-http-https-custom-port-nginx/
家用宽带的 443 端口一般不可用，只能用一个非标准端口，那如何在非标准 80/443 端口实现 SSL 跳转呢，这里可以用到 Nginx 的 409 错误代码，即是
497 - normal request was sent to HTTPS如果把 497 的错误相应页面改为 跳转 https 的 302，就可以实现，在 Server 段加一行
error_page 497 https://$host:1234$request_uri;就可以了，最后形如笔记 https://segmentfault.com/a/1190000022275523#item-3
查看进程流量可以使用 ss，是 iproute2util 包的一部分，同时 ip 也是这个包的一部分，所以一般有 ip 就会有 ss，对于像 truenas 这种高度定制且封锁了 apt 的“程序”很是方便。
tcpdump 可以用来抓包，保存的数据可以用 wireshark 打开和查看，此包也大多数都有预装。
感谢小黄，我现在看房子都有了几个关注点：
1.房屋最好朝南或东南，如果朝北，那就一定要开阔明媚，采光要好。
2.玄关鞋柜深度起码要有35，最好有一扇镜子，出门前可以整理一下外表。
3.厨房要明厨，天花板要通铺，橱柜要够用，冰箱预留位置起码要90，洗碗盆要大的，厨房要足够容纳两个人同时干活。
4.餐桌边长或直径要起码90的，要有足够的地方放餐边柜。客厅阳台外景观要视野开阔，采光要好，同时要关注对面是不是待开发区，会不会遮挡景观。
5.卫浴室要有窗，天花板要通铺，洗手台脸盆要够大够深，不然水花乱溅，洗手台下面最好做成抽屉，方便拿取收纳。镜柜根据需要，要有足够的深度。马桶上面最好打一排柜子方便收纳。淋浴间的门要么是滑动的，三开门最好，要么是往外拉的，决不能往内拉，以防老人摔倒打不开门。
6.床长度起码要2米，单人床宽度1.5米更舒适，双人床长度起码要1.8米。房间要有地方放衣柜，衣柜深度起码要60，不然大衣放不下，卧室颜色不要太花，不然影响睡眠。
看房子带把尺子去真的很实用
生年不满百，常怀千岁忧。
昼短苦夜长，何不秉烛游！
为乐当及时，何能待来兹？
愚者爱惜费，但为后世嗤。
仙人王子乔，难可与等期。
劝及时行乐，也叹毫无出路。
https://m.gushiwen.cn/mingju/juv_f2af3c0bf211.aspx
Bit Torrent
Bit torrent performs 16KB random reads/writes. The 16KB writes cause read-modify-write overhead. The read-modify-write overhead can reduce performance by a factor of 16 with 128KB record sizes when the amount of data written exceeds system memory. This can be avoided by using a dedicated dataset for bit torrent downloads with recordsize=16KB.
When the files are read sequentially through a HTTP server, the random nature in which the files were generated creates fragmentation that has been observed to reduce sequential read performance by a factor of two on 7200RPM hard disks. If performance is a problem, fragmentation can be eliminated by rewriting the files sequentially in either of two ways:
The first method is to configure your client to download the files to a temporary directory and then copy them into their final location when the downloads are finished, provided that your client supports this.
The second method is to use send/recv to recreate a dataset sequentially.
In practice, defragmenting files obtained through bit torrent should only improve performance when the files are stored on magnetic storage and are subject to significant sequential read workloads after creation.
https://openzfs.github.io/openzfs-docs/Performance%20and%20Tuning/Workload%20Tuning.html#bit-torrent
Do not set Pre-allocated disk space if you are using ZFS as your filesystem as ZFS does not support fallocate
有在 ZFS 文件系统上不要开启 Qbittorrent 预分配空间的说法，原因是 ZFS 不支持 fallocate
https://www.truenas.com/community/threads/the-path-to-success-for-block-storage.81165/ 把我看迷糊了，讨论各种 ZFS 适合什么使用场景，不应该怎么做。
笔记
一直很头疼这个 swag 的证书的目录结构，一堆软链接，不方便 copy 证书到其他服务器使用。
rsync 有替换软连接为源文件的功能
https://forums.servethehome.com/index.php?resources/supermicro-x9-x10-x11-fan-speed-control.20
关于超微 IPMI 风扇控制的方法和策略。
目前感觉系统或者其他主机接管风扇控制更加容易控制，超微的风扇控制还是比较简单了，不知道 ILO 的如何。
笔记 https://github.com/KostyaEsmukov/smtp_to_telegram
有意思可用的项目，一个 SMTP 服务器，劫持到所有发送到 SMTP 上的邮件到 Telegram 的机器人上。
能用邮件当通知的不少，这个能够不依赖 QQ SMTP 之类的服务，不受限制。
目前还是有缺点，没有 SMTP 认证的功能，放在公网还是有点害怕。
作者提到可以在前面再放一层 exim4
postfix 似乎更易用
https://aphuse.github.io/post/howtoresizelvm/
LVM管理磁盘的基本用法pvresize --setphysicalvolumesize size PhysicalVolumeLVM 是一种可用在Linux内核的逻辑分卷管理器；可用于管理磁盘驱动器或其他类似的大容量存储设备。
LVM基本组成
LVM利用Linux内核的device-mapper来实现存储系统的虚拟化。通过LVM可以实现存储空间的抽象化，并在上面建立虚拟分区，可以很简便的扩大和缩小分区大小，可以在增加或者删除分区操作时无需担心某个硬盘上没有足够的连续空间。LVM是用来方便管理的，不会提供额外的安全保证。
LVM的基本组成：
优点
比起正常的磁盘分区管理，LVM更富有弹性：
缺点
创建物理卷(PV)
注意：请确认您对正确的分区进行操作！
您可以通过以下方式找到类型“Linux LVM”的分区（这是您在分区的时候就设定好的，“Linux LVM”分区码对应的十六进制码为8e(MBR)或8e00(GPT)） ：
在该分区（假设是/dev/sda2）下创建一个物理卷(PV)：
查看创建好的物理卷(PV)
创建卷组(VG)
创建完物理卷(PV)之后，我们就可以开始创建卷组(VG)了。如果您有两个以上的物理卷(PV)（例如：/dev/sda2和/dev/sdb1），并且您希望只使用一个卷组(VG)来管理这些物理卷(PV)，那么您首先要在其中一个物理卷(PV)上创建一个卷组(VG)，然后再让该卷组(VG)扩大到其他所有的物理卷(PV)：
上面的命令中，datavg是您取得卷组名称，您可以换成您喜欢的名称。
查看卷组信息命令：
创建逻辑卷(LV)
创建完卷组(VG)之后，我们就可以开始创建逻辑卷(LV)了。下面是在datavg卷组(VG)上创建一个名为datalv大小为10G的逻辑卷(LV)：
如果要创建的是swap分区，那么需要加上-C y参数，该参数用来指定逻辑卷的空间分配是连续的，保证您所创建的swap空间不会被分散在不连续的物理空间甚至不同的硬盘中。如在datavg卷组(VG)上创建10G大小名为swaplv的逻辑卷(LV)：
如果您想要让创建的逻辑卷(LV)拥有卷组(VG)的所有未使用的空间，可以使用下面命令：
查看逻辑卷(LV)信息
现在您新建的逻辑卷应该已经在/dev/mapper和/dev/rootvg中了。如果您无法在以上位置找到它，请使用一下命令来加载模块，并扫描与激活卷组：
创建文件系统(File system)和挂载逻辑卷(LV)
现在您可以在逻辑卷(LV)上创建文件系统并像普通分区一样挂载它了。
以上就是LVM的基本使用介绍。后面还会介绍如何调整逻辑卷(LV)的大小。
腾讯企业邮箱想要拿到授权码用上第三方客户端，得去 https://exmail.qq.com/ 传统网页端，另外 pop 和 IMAP 的服务器设置也是不同的：
镜头 焦距和对应视角
在短焦段，每毫米带来的视角变化会更大，长焦变化更小，APS-C 画幅因为视角裁切问题，在超广角镜头上特别的吃亏。