冬瓜头

引用:

原帖由 林肯 于 2008-1-23 09:46 发表

冬瓜头我不知道你是真的不了解还是在绕，netapp算不算软件公司和这个问题没有任何关系
你记得你以前还天天在问磁盘的写缓存要不要打开的问题？因为会导致数据丢失，而且当时你还不断challenge说如果即使数据库有一 ...

好吧好吧：）
原来那个帖已经解决了。数据库在重启时会根据保存在磁盘上的image来检测是否需要replay。ram缓存中的所有写操作都会被记录到log中一份，只要log被记录了（先写入log buffer，触发一致点时同步写入磁盘），那么就可以向上位返回ack。如果log记录成功，而突然掉电，那么buffer数据丢失，但是log在磁盘上，没有丢失，重启时数据库会redo和undo日志，恢复到一致的状态。
“数据库这层写到阵列了，轮到阵列来保持一致性了”。没错，可以说是两个数据库，a先写入b，b在记录log后（到nvram，电池保护），即刻给a返回ack，而此时buffer还没有被flush到存储的物理磁盘，此时掉电，没事，重启时存储redo和undo日志，将未被flush的数据写盘，不会造成丝毫丢失数据。这也就是为何netapp不需要保护ram buffer，而只保护nvram的道理。
我你还不知道么，回答不出的绝对不会找接口掩盖，不会就是不会，而且必须弄会。这次您老哥真不了解小弟了。

林肯

引用:

原帖由 冬瓜头 于 2008-1-23 11:15 发表

好吧好吧：）
原来那个帖已经解决了。数据库在重启时会根据保存在磁盘上的image来检测是否需要replay。ram缓存中的所有写操作都会被记录到log中一份，只要log被记录了（先写入log buffer，触发一致点时同步写入磁 ...

谢谢冬瓜的解释，接下来的问题是:
1 我的理解，你说的RAM是内存，不带电保护，所以写到log里面对不？
2 log在NAS头里面是什么个东西，是怎么存在的，是NVRAM还是什么东西
3 LOG和NVRAM的关系是什么？
4 log和物理写数据缓存之间的关系是什么呢，据说log要不写缓存数据小，那怎么能够实现呢？

冬瓜头

1 我的理解，你说的RAM是内存，不带电保护，所以写到log里面对不？
ram是指内存。io进来是先写到ram，同时将操作日志写入nvram（也就是留一份存根）

2 log在NAS头里面是什么个东西，是怎么存在的，是NVRAM还是什么东西
这个如果林总了解一下数据库就可以明白了。比如某时刻一个io说：向某某文件某offset开始，长度128字节，写入128字节的如下数据：……◎％※＃※，此时，程序会从read buffer中读出这些数据块到write buffer，然后将数据更新到buffer块中。而同时将这个操作日志记录到log中（nvram中），writer buffer对应的这些块可能是512字节（裸数据加开销）。但是log对应的这条帐目，远小于512字节，只有裸数据＋描述动作的信息。这就是log。

3 LOG和NVRAM的关系是什么？
log存放在nvram中，nvram是介质，log存放在其中。

4 log和物理写数据缓存之间的关系是什么呢，据说log要不写缓存数据小，那怎么能够实现呢？
答案在第一个问题回答中。

冬瓜头

另，澄清一点，nvram与raid4优化没有任何关系。以前有人说wafl对raid4优化是靠nvram，完全没有任何根据和底层原理支持。

林肯

引用:

原帖由 冬瓜头 于 2008-1-23 11:50 发表
1 我的理解，你说的RAM是内存，不带电保护，所以写到log里面对不？
ram是指内存。io进来是先写到ram，同时将操作日志写入nvram（也就是留一份存根）

2 log在NAS头里面是什么个东西，是怎么存在的，是NVRAM还是什 ...

这个如果林总了解一下数据库就可以明白了。比如某时刻一个io说：向某某文件某offset开始，长度128字节，写入128字节的如下数据：……◎％※＃※，此时，程序会从read buffer中读出这些数据块到write buffer，然后将数据更新到buffer块中。而同时将这个操作日志记录到log中（nvram中），writer buffer对应的这些块可能是512字节（裸数据加开销）。但是log对应的这条帐目，远小于512字节，只有裸数据＋描述动作的信息。这就是log。

谢谢冬瓜的回答，但是依然有个问题，数据库里面关有log是不够的，我的理解你这里讲的log只是为了rollforward和rollback时的SCN序列号，但是log最终需要调用redo log里面真实的记录来，如果真实记录不存在，光有id有什么用，online和archive redo log和里面记录的才是实实在在的数据，这里的数据才是恢复时所需要的真正数据，这个数据保存在哪里呢?
1 是机头的内存里面，不带电保护？
2 是机头根据变化量和现有数据，算出一个差量的log，然后把这个差量变化的log写入NVRAM里面，恢复的时候通过现有硬盘的数据和差量log可以得出最新的数据
是哪一种呢，冬瓜头

冬瓜头

哪一种都不是。
nvram里切切实实的就是数据，只不过不是block结构，而是描述性的结构，可以想象成txt文本。所以很小。

林肯

引用:

原帖由 冬瓜头 于 2008-1-23 15:18 发表
哪一种都不是。
nvram里切切实实的就是数据，只不过不是block结构，而是描述性的结构，可以想象成txt文本。所以很小。

1 那要把真正的数据转换成你说的“nvram里切切实实的就是数据，只不过不是block结构，而是描述性的结构，可以想象成txt文本。所以很小。”要花多少时间和控制器多少性能呢，而且这应该是通过计算得出来的所谓描述性结构。
2 如果这是一个incremental的增量，那么要和原来的磁盘数据对比不？

冬瓜头

1那要把真正的数据转换成你说的“nvram里切切实实的就是数据，只不过不是block结构，而是描述性的结构，可以想象成txt文本。所以很小。”要花多少时间和控制器多少性能呢，而且这应该是通过计算得出来的所谓描述性结构。

这个转换，耗费cpu cycle不多的。我没写过代码更没做过程序优化。但是至少我可以说，将数据从ram拷贝到nvram，然后加上描述信息，这个逻辑不复杂。


2 如果这是一个incremental的增量，那么要和原来的磁盘数据对比不？
这里没有增量的概念，只有IO的概念。上层IO给什么数据，就记录什么数据，不管是否在底层是增量或者非增量。所以更不用与原来的对比了。

林肯

引用:

原帖由 冬瓜头 于 2008-1-23 16:43 发表
1那要把真正的数据转换成你说的“nvram里切切实实的就是数据，只不过不是block结构，而是描述性的结构，可以想象成txt文本。所以很小。”要花多少时间和控制器多少性能呢，而且这应该是通过计算得出来的所谓描述性结 ...

通过计算得出来的所谓描述性结构。
这个转换，耗费cpu cycle不多的。我没写过代码更没做过程序优化。但是至少我可以说，将数据从ram拷贝到nvram，然后加上描述信息，这个逻辑不复杂。
问题1 ：耗费多少CPU呢，将数据从ram拷贝到nvram，然后加上描述信息这个逻辑是不复杂，但是其他磁盘系统都不会采用这种方法，因为这肯定是需要有时延迟的，对不
问题2： 消耗多少资源，我是不是可以设想成oracle在没有打开archive模式和打开archivie模式之间所需要消耗CPU和latency的时延，来比较netapp的写机制和其他的写机制的区别呢？ 要知道即使是IBM DS800用POWER 6的芯片，也不敢在NVS里面再来异步你所谓的把block结构改成描述性结构的过程，这里面需要计算能力和延迟是不可能忽略的！！！

zchshao

整个过程大概是这样的 － 一个文件系统的写操作首先要创建一个transaction，然后他把数据读到ram里来，做些修改，当他提交这个transaction的时候，他所修改的data buffer（包括metadata buffer）以及这些buffer的描述都要写到log里面（应该是整个buffer，而不是只被修改的那些bytes），这个log可以在磁盘上，也可以在nvram里，也可以在battery backed memory(BBM)里面，当然后面两个的速度快。当写log成功返回之后，再把数据提交给io真正写到磁盘上（其实是磁盘的CACHE），如果返回成功，这个transaction就算提交成功了，这个写操作也可以成功返回了。至于是否磁盘cache里的东西确实写到了磁盘上面，文件系统并不关心，所以磁盘的cache一定是有电池的。文件系统的log机制只是保护那些正在进行当中的transaction。