changetime和modifytime的区别

https://stackoverflow.com/questions/3385203/regarding-access-time-unix

The stat(2) structure keeps track of all the file date/times:

   struct stat {
       dev_t     st_dev;     /* ID of device containing file */
       ino_t     st_ino;     /* inode number */
       mode_t    st_mode;    /* protection */
       nlink_t   st_nlink;   /* number of hard links */
       uid_t     st_uid;     /* user ID of owner */
       gid_t     st_gid;     /* group ID of owner */
       dev_t     st_rdev;    /* device ID (if special file) */
       off_t     st_size;    /* total size, in bytes */
       blksize_t st_blksize; /* blocksize for file system I/O */
       blkcnt_t  st_blocks;  /* number of 512B blocks allocated */
       time_t    st_atime;   /* time of last access */
       time_t    st_mtime;   /* time of last modification */
       time_t    st_ctime;   /* time of last status change */
   }; st_atime is the access time, updated on read(2) calls (and probably also when open(2) opens a file for reading) -- it is NOT updated when files are read via mmap(2). (Which is why I assume open(2) will mark the access time.)

st_mtime is the data modification time, either via write(2) or truncate(2) or open(2) for writing. (Again, it is NOT updated when files are written via mmap(2).)

st_ctime is the metadata modification time: when any of the other data in the struct stat gets modified.

You can change the timestamps on files with utime(2):

   struct utimbuf {
       time_t actime;       /* access time */
       time_t modtime;      /* modification time */
   }; Note you can only change the access time and (data) modification time. You can set either of these to arbitrary times, but the ctime is going to be set to the current time -- because you changed the metadata for the file.

There is no create time in this structure, so it’s not possible to find out when a file was created directly from the system.

If you really need to know the create time, you can narrow it down to a range by looking at your backups – assuming the file you’re interested in has been backed up, along with its metadata.

mmap的两篇文章

http://blog.csdn.net/streetlight8023/article/details/42168403 http://0xffffff.org/2017/05/01/41-linux-io/ mmap和磁盘读写的两篇文章, 不过还是没明白为啥堆外内存小的时候, ES使用mmap index storage会有大量磁盘读写

mail中的Content-Transfer-Encoding定义和用法

python发送邮件时出现乱码, 搜索了一下可以通过更改Content-Transfer-Encoding定义解决.

msg = MIMEText(None, "plain")
msg.replace_header('content-transfer-encoding', 'quoted-printable')
msg.set_payload(content, 'utf-8')

https://stackoverflow.com/questions/25710599/content-transfer-encoding-7bit-or-8-bit

https://www.w3.org/Protocols/rfc1341/5_Content-Transfer-Encoding.html

vm

https://www.kernel.org/doc/Documentation/sysctl/vm.txt留着后面看

可是

可是, 我看到微信有消息, 还是希望是你的.

在身边

看到这张照片好开心, 有种”一直在身边”的感觉.

差不多先生

我不会计较和攀比谁和工资高, 谁先把女孩约出来, 我是差不多先生. 但是我愿意去思考这背后的原因, 否则真的连差不多先生都做不了.

安心

不管生活和工作多么的烦心, 想到有个可以说话的人在身边, 就会觉得很开心, 内心顿时平静下来.

golang http note

没看懂这是啥, 先继续往下看.

TrailerPrefix is a magic prefix for ResponseWriter.Header map keys that, if present, signals that the map entry is actually for the response trailers, and not the response headers. The prefix is stripped after the ServeHTTP call finishes and the values are sent in the trailers.

This mechanism is intended only for trailers that are not known prior to the headers being written. If the set of trailers is fixed or known before the header is written, the normal Go trailers mechanism is preferred:

https://golang.org/pkg/net/http/#ResponseWriter https://golang.org/pkg/net/http/#example_ResponseWriter_trailers const TrailerPrefix = “Trailer:”

MDN web docs里面的解释 https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Trailer

情绪

我还是抑制住, 不想让你觉得被打扰.

可是我有点事情就想告诉你, 看到微信有消息就多少希望是你的.