fsync

What's the correct way to durably rename a file in a POSIX file system? Specifically wondering about fsyncs on the directories . (If this depends on the OS/FS, I'm asking about Linux and ext3/ext4). Note : there are other questions on StackOverflow about durable renames, but AFAICT they don't address fsync-ing the directories (which is what matters to me - I'm not even modifying file data). I currently have (in Python): dstdirfd = open(dstdirpath, O_DIRECTORY|O_RDONLY) rename(srcdirpath + '/' + filename, dstdirpath + '/' + filename) fsync(dstdirfd) Specific questions : Does this also

更多内容，欢迎关注微信公众号：全菜工程师小辉~ Redis提供了将数据定期自动持久化至硬盘的能力，包括RDB和AOF两种方案，两种方案分别有其长处和短板，可以配合起来同时运行，确保数据的稳定性。 RDB 保存数据快照至一个RDB文件中，用于持久化。RDB操作和Mysql Dump相似。 执行方式 save。同步操作，会阻塞Redis。 bgsave。调用linux的fork()，然后使用新的线程执行复制。但是fork期间也会阻塞Redis，但是阻塞时间通常很短。 自动保存。Redis配置文件中设置了自动保存的触发机制，可以自定义修改，运行原理同bgsave。 save和bgsave的对比 注意： 如果机器上运行多个Redis，需要配置RDB文件名称，否则多个Redis的RDB文件会相互覆盖。 除了上述三种执行方式，以下情况也会生成RDB文件： 主从的全量复制时，主机会生成RDB文件。 Redis中的debug reload提供debug级别的重启，不清空内存的一种重启，这种方式也会触发RDB文件的生成。 执行shutdown时，会触发RDB文件的生成。 RDB的缺点 全量数据存储，耗时。 虽然fork()采用copy-on-write策略，但仍消耗内存 写RDB文件消耗大量IO性能。 AOF 采用AOF持久方式时，Redis会把每一个写请求都记录在一个日志文件里

mysql的innodb_flush_method这个参数控制着innodb数据文件及redo log的打开、刷写模式，对于这个参数，文档上是这样描述的： 有三个值：fdatasync(默认)，O_DSYNC，O_DIRECT 默认是fdatasync，调用fsync()去刷数据文件与redo log的buffer 为O_DSYNC时，innodb会使用O_SYNC方式打开和刷写redo log,使用fsync()刷写数据文件 为O_DIRECT时，innodb使用O_DIRECT打开数据文件，使用fsync()刷写数据文件跟redo log 首先文件的写操作包括三步：open,write,flush 上面最常提到的fsync(int fd)函数，该函数作用是flush时将与fd文件描述符所指文件有关的buffer刷写到磁盘，并且flush完元数据信息(比如修改日期、创建日期等)才算flush成功。 使用O_DSYNC方式打开redo文件表示当write日志时，数据都write到磁盘，并且元数据也需要更新，才返回成功。 O_DIRECT则表示我们的write操作是从MySQL innodb buffer里直接向磁盘上写。 这三种模式写数据方式具体如下： fdatasync模式：写数据时，write这一步并不需要真正写到磁盘才算完成（可能写入到操作系统buffer中就会返回完成）

Redis 和 Memcache 都是基于内存的数据存储系统。Memcached是高性能分布式内存缓存服务；Redis是一个开源的key-value存储系统。与Memcached类似，Redis将大部分数据存储在内存中，支持的数据类型包括：字符串、哈希 表、链表等数据类型的相关操作。下面我们来进行来看一下redis和memcached的区别。 权威比较 Redis的作者Salvatore Sanfilippo曾经对这两种基于内存的数据存储系统进行过比较： Redis支持服务器端的数据操作：Redis相比Memcached来说，拥有更多的数据结构和并支持更丰富的数据操作，通常在Memcached里，你需要将数据拿到客户端来进行类似的修改再set回去。这大大增加了网络IO的次数和数据体积。在Redis中，这些复杂的操作通常和一般的GET/SET一样高效。所以，如果需要缓存能够支持更复杂的结构和操作，那么Redis会是不错的选择。 内存使用效率对比：使用简单的key-value存储的话，Memcached的内存利用率更高，而如果Redis采用hash结构来做key-value存储，由于其组合式的压缩，其内存利用率会高于Memcached。 性能对比：由于Redis只使用单核，而Memcached可以使用多核，所以平均每一个核上Redis在存储小数据时比Memcached性能更高

> 新搭建的个人博客，欢迎光临 < 一． Binlog格式介绍 模式1 Row ：日志中会记录成每一行数据被修改的形式，然后在slave端再对相同的数据进行修改。 优点： row level模式下，bin-log中可以不记录执行的sql语句的上下文相关的信息，仅仅只需要记录那一条记录被修改了，修改成什么样了。所以row level的日志内容会非常清楚的记录下每一行数据修改的细节。且不会出现某些特定情况下的存储过程，或function，以及 trigger的调用和触发无法被正确复制的问题。 缺点： row level模式下，所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容，比如有这样一条update语句：update product set owner_member_id = ‘b’ where owner_member_id = ‘a’，执行之后，日志中记录的不是这条update语句所对应额事件(MySQL以事件的形式来记录bin-log日志)，而是这条语句所更新的每一条记录的变化情况，这样就记录成很多条记录被更新的很多个事件。自然，bin-log日志的量就会很大。尤其是当执行alter table之类的语句的时候，产生的日志量是惊人的。因为MySQL对于alter table之类的表结构变更语句的处理方式是整个表的每一条记录都需要变动

磁盘优化思路 性能定位套路 和之前类似,我们不可能出现性能问题就把所有工具都跑一遍,而是先运行那几个支持指标较多的工具，如 top,iostat,vmstat等来缩小范围 先用top, iostat 发现磁盘 I/O 性能瓶颈； 再借助 iotop, pidstat 等定位出导致瓶颈的进程； 随后用strace, lsof等分析进程的 I/O 行为； 最后，结合应用程序的原理，分析这些 I/O 的来源。 性能优化思路 由于影响磁盘I/O性能的因素众多,我们对磁盘I/O优化分应用程序,文件系统,磁盘三方面来说 1.应用程序优化 应用程序处于整个 I/O 栈的最上端，它可以通过系统调用，来调整 I/O 模式（如顺序还是随机、同步还是异步）， 同时，它也是 I/O 数据的最终来源。 在我看来，可以有这么几种方式来优化应用程序的 I/O 性能: 1).可以用追加写代替随机写，减少寻址开销，加快 I/O 写的速度。 2).可以借助缓存 I/O ，充分利用系统缓存，降低实际 I/O 的次数。 3).可以在应用程序内部构建自己的缓存，或者用 Redis 这类外部缓存系统。这样，一方面，能在应用程序内部，控制缓存的数据和生命周期；另一方面，也能降低其他应用程序使用缓存对自身的影响。 4).在需要频繁读写同一块磁盘空间时，可以用 mmap 代替 read/write，减少内存的拷贝次数。 5)

I found this in the Python documentation for File Objects : flush() does not necessarily write the file’s data to disk. Use flush() followed by os.fsync() to ensure this behavior. So my question is: what exactly is Python's flush doing? I thought that it forces to write data to the disk, but now I see that it doesn't. Why? There's typically two levels of buffering involved: Internal buffers Operating system buffers The internal buffers are buffers created by the runtime/library/language that you're programming against and is meant to speed things up by avoiding system calls for every write.