偶然在某个BBS上看到，神作啊~~~
恩，我决定以后每次出去办事以前都先学习一下此贴再出发！
========转载分割线====================
因为在这里的工作有很多机会要接触官员...
以下就个人经验打些建议:
1. 先了解好拜访各政府机关(尽量短时间内跑完所有关连单位), 总结需要达到的目标
2. 准备好项目构想, 资料, 方案, 愈具体愈好, 例如示意图、草案计画「书」, 要看起来势在必行
3. 找出所有相关的「局、处、所」的「各科别」
4-1. 最有效率的方式, 是透过人脉联系项目主要关系部门, 具决策能力的人, 如局长,委员会主席, 县长等-职权大于其他部门访谈对象的官员初次拜访, 首要目标是让对方下达行政公文, 第一是要跟对方有直接关系, 例如发展改革局
, 第二是阵仗要够大, 就算以后不会再出现的人也多到几个, 因为官员大多很和谐, 见到人多总要给点面子
4-2. 在当地找无人脉, 就找项目中有直接关系的单位的科长, 事先约个时间表达来意, 主动问是否再上班时间或非上班时间见个面, 「请他们指导」一下, 见面的主要程序是: 用「充分准备」的资料让对方认同项目, 多到脑袋混乱最好, 然后告诉对方, 哪方面有困难, 尤其是对方了解的领域, 打开话题后, 将话题目的围绕在让对方「表明」支持项目, 让对方上台阶..., 然后开始提出些「请求」
(这里的官员对于来者很重视以下:所属单位、职务或地方身分、有无相关部门授权等可信任程度, 不然资料一个都不给, 问题都随便打发打发)
(非绝对必要, 千万不要掏钱给官员, 不然一定会陷入无底洞或吃亏)
以上是第一阶段
在取得重要官员的支持和协助后, 开始着手对区域内各关系部门的资料索取或访会谈:
1. 列出清单, 请高层官员授权、支持和协助对各部门的会谈资格, 不然被草草了事打发的可能性很大
2. 在每个见面的行程前, 最好三天前就电话约好时间, 并且将要谈的内容和希望了解的资料列出, 让对方有充分时间准备, 相对也比较不会敷衍了事。见面前一定要在电话中就让对方信任, 或是明确的承诺会提供协助..实际见到面的态度才不会有太多落差, 事先约好也绝对好过突然拜访耽误对方午休或接小孩时间之类的...
3. 每次见面, 一个人主问, 一旁最好有人随行纪录补充。 因为会谈地点大多会在对方办公室内, 所以人不要超过三个为宜, 因为办公室通常只会多准备两张椅子...
4.事先了解对方办公处所在是必要的, 但仍然可以此为由, 装傻的问对方如何前往, 让对话多一些, 信任和情感程度也会多些。以上是有充分时间的方式, 如果时间不够, 就做好一个部门要去两次的心理准备, 不论如何一个关键「资料要准备充分、齐全、具体」
5. 确认自己的服装仪容, 在台湾, 第一次见面要以正装出席会谈可能是大家的默契了, 但在中国, 白领身分的人却随便穿着是很理所当然的.. ., 身为台湾人...更应该坚持从小教导服装仪容要整齐的文化..., 正装出席给对方好的印象, 对方通常比较愿意给面子多(中国真的有不少阶级意识),至少要白衬衫, 切忌牛仔裤和一堆装饰的「潮衣潮裤」...
见到面了:
1. 问候、再次表明来意、出示相关证明和名片
2. 先主动握个手吧! 肌肤之亲很能拉进彼此距离.. [1;31m...(握手后请勿随意处碰, 不过我在这里, 已经自动让洁癖荡然无存了...)
3.尽可能随身准备包烟和打火机, 练习点烟, 尽管自己不抽, 还是可以询问对方...以烟会友...
对方不抽, 就收起来开始进入话题对方抽了, 自己要不要跟着抽...其实影响不大..
4.有资料拿资料, 有问题提问题, 尽量提出自己困难点, 让对方有表现机会
5. 在初步的提问候, 自己一定要能摸清对方的办事性格, 不擅长奉承的人, 最好练习一下一些奉承对方的提问语气
6.不同部门不同职务的官员, 办事效率有些奇差, 堪称冗员, 但也是有无其认真的, 见人说人话, 见鬼说鬼话。
7.有求于人的关键就是让对方觉得"你这小老百姓, 看我的吧!" 千万别期待这里的官员是热心服务的.........他们可是老大...
8.还有个要提醒的...别期待这里政府无所不知, 实际上他们知道的东西真的很少, 加上细分的职权...不同部门科别的资讯交流只限会议中提到和公开的资料, 实际上大概说没有的资料就是真的没有, ...统计方面的正确性...真的参考参考就好, 把官员的官员的用途定位在"出面解决问题",像是签名敲章授权或陪同造访等...
准备结束话题了:
1.真的也没啥好问的时候, 如果对方对案子影响很重要... 就邀请对方吃个饭, 许多话是在办公室里问不到的, 另外, 如果谈得来, 从公务上拉进成朋友关系, 在这里要干点事情, 有关系真的很多事情都好办很多
2.没要请对方吃饭就直接说「下午三点了, 我们也差不多要前往下个地方了」之类的理由开即可
3.走之前一定要再次确认和总结会谈, 向对方要个名片或提醒需要提供的资讯, 免得效率太差空等待..
4.一些预约时间的事情, 就像杀价一样最好说句能否再早一点?或是先提供局部的? 可以省掉不少时间...
另外些建议:
1.这里行政都有"第XX个五年计画", 简称XX五计画, 尽量让案子和这些计画有关联, 政府会比较重视..
2.一些行政公文要请政府批示的, 事先帮那些官做好, 他们只要看过同意敲个章就能用这样的模式成功率会请政府提供些公文高很多
3.关于问卷之类的, 最好”不要”用开放式问卷给政府人员看, 把问题和对方要回答的东西都自己想好大概…写成封闭式问卷, 现场给对方写完后再根据选项作进一步询问, 是最好的资料搜集方式, 如果纯粹是要官员提供建议和指导的, 就在一开始见面问候后, 直接的说, 省得浪费彼此时间, 问得越精辟, 资料愈详细, 通常对方回覆的意愿会高上很多, 不然直接说不知道不清楚不了解带过是最常发生的事…
另外, 对于些非大城市地区:
1.很忙, 因为一天只有6小时上班时间
2.很闲, 因为地方这么小, 以前都是农村, 现在多了点厂房, 实际上没啥好做的
3.善尽职责, 因为这么小, 也不会有啥展发展, 未来规划的事情都听上面领导跟着做就好
4.政府设施很棒, 超级大办公室空荡荡的, 一个局一大栋, 各局分布在地方的四处是很正常的.....
5.很有效率, 因为统计数字多是忽悠出来的, 所以统计很快, 也明白的说没参考意义
6.一问三不知、推托责任、敷衍了事、安于现状...其他有待版友补充
2011年7月14日星期四
2011年4月8日星期五
Top 10 Reasons for NFS Stale handler error while mounting FS
1. When the kernel tries to read the first block of the device, and found all 0 in there! That is, you didn't flush writes properly to the appropriate place.
2011年3月10日星期四
Followup on academic publishing in systems
zz from http://www.thegibson.org/blog/archives/305
My personal take away from this blog:
1. Getting a faculty job in a decent university is reallllllllly hard. 2 OSDI, 3 SOSP and other publications on FAST?!?! It is hard to imagine myself making this kind of achievement in 5 years, even though I am lucky enough to work with his former advisor. (Would it be easier for research labs affilicated to companies? But you woundn't have grad students for most time of a year, and that's like a whole different ecosystem).
2. Publishing in top system conferences is kind of subjective (at least to me). You have to guess what will make PC interested, and it is still a bit mysterious to me :(
My advisor seems to have a quite different perspective on what is interesting work in the system area than I do; and I guess I should try to develop this kind of perspective too if I am seriously thinking about research as my career. (Still can not believe some debugging linux stuff get their way into OSDI, though...)
3. Congrats to Haryadi! This is like the first faculty in our group? Even though those guys in Microsoft research or national labs are also active in publishing papers (Eurosys, SIGOPS etc.), but I guess being in an university is different.
===========================================================================
I follow Ed Felten’s blog, Freedom To Tinker (which is actually now a blog for many people at Princeton’s Center for Information Technology Policy) — it has good coverage on issues like electronic voting and intellectual property. Dan Wallach, a well known security (among other things) researcher at Rice, published an interesting post titled “Acceptance rates at security conferences” assessing the state of academic CS conferences in the area of security. He points out that the conferences are getting increasingly competitive with an ever growing field of researchers and a relatively fixed number of conference venues; he notes that this will lead to certain “structural problems” in the research community and discusses potential options.
He also points to Matt Welsh‘s thoughts on similar issues in the systems community:
“Scaling up conferences”
“Scaling up program committees”
This is of particular interest to me since, as a PhD student, I am an academic systems researcher. Dan Wallach summarizes Matt first post as follows:
He argues that there’s a real disparity between the top programs / labs and everybody else and that it’s worthwhile to take steps to fix this. (I’ll argue that security conferences don’t seem to have this particular problem.) He also points out what I think is the deeper problem, which is that hotshot grad students must get themselves a long list of publications to have a crack at a decent faculty job. This was emphatically not the case ten years ago.
I definitely see what Matt is talking about in the systems community. For example, for a large subset of lower-level systems work*, SOSP and OSDI are a sort of gold standard in publication venues. Each conference is held every two years (alternating years between the two venues), so each year 20-30 papers will be accepted total (for reference, OSDI ’08 accepted 26/193 and SOSP ’07 accepted 25/131). Given the size of the systems community, that doesn’t give much leeway for up-and-coming researchers, but a publication in such a venue is virtually required to be competitive academically — as Matt describes it, a publication in these venues is “a highly prized commodity, and one that is becoming increasingly valued over time.” Matt says:
Several of us on the hiring committee were amazed at how many freshly-minted Ph.D.s were coming out with multiple papers in places like SOSP, OSDI, and NSDI. Clearly there is a lot more weight placed on getting those papers accepted than there used to be. … Somewhere along the way the ante has been upped considerably.
I notice this too. For example, Georgia Tech’s College of Computing (where I am finishing my PhD) was ranked in the top 10 graduate programs in CS (#9) by US News and World Report in 2008. For systems research specifically, we were also ranked in US News and World Report’s top 10 (#10) in 2008. Now, of course US News and World Report’s rankings are contentious and reducing the work of a whole bunch of different researchers in CS to a single dimensional ordinal representing the whole program is very subjective, but the point is only to say that our program can be considered competitive in the universe of CS graduate programs.
But if you look at our publishing track record in these two prized venues, we’re virtually unrepresented. If you look at the OSDI proceedings, you will see that a paper from Georgia Tech has never been accepted there (my 2008 submission was rejected, although it did get decently positive reviews), and we have two SOSP papers — one in 97 which was collaborative with Microsoft Research and involved only students and no Georgia Tech faculty (which makes me wonder if it was related to an internship) and one in 2007 which was a collaboration between a student in the Electrical and Computer Engineering and a professor in the College of Computing. Compare this college-wide record with that of Haryadi Gunawi, an excellent faculty candidate interviewing at Georgia Tech this year. In his career as a PhD student, he had 2 OSDI and 3 SOSP publications (plus publications in top venues in other areas, like PLDI, ISCA and FAST). As a student, he has amassed significantly more publications in these prized venues than our whole College of Computing can claim**. And other students from his advisor(s) have similarly impressive CVs. Look at the students of many other “rockstar” systems researchers and you’ll see the same pattern; we had a parade of great faculty candidates with similarly strong records.
So what am I supposed to make of this? I get a deep sense of cynicism when I see trends like this over many years. Matt says, “I don’t have hard data to back this up, but it feels that it is increasingly rare to see papers from anything other than ‘top ten’ universities and labs in the top venues.” I would go a step further and say that there’s a certain “clique” (or “cabal” if you want something sinister) of key researchers who facilitate virtually all of the publications in these venues. If you are a student of one of these researchers, or a nth-generation student (e.g. a student of a faculty member who once was a student of…), you know how to do work that appeals to the program committee and present it in the proper way — if you don’t have the right perspective on these fine points of taste, your chances are grim.*** As a student, if your advisor is a big name, you can have a paper in these top venues every year. If you don’t, you have very bleak academic job prospects. Now I’m definitely not trying to diminish Haryadi’s impressive accomplishments, and his research is very exciting. But I get the sense that there’s a very strong dis-proportionality in academic publishing in systems that is a lot worse than most other areas in computer science.
A comment to Matt’s first post and the end of Dan’s post also pointed me to another relevant article. In May’s CACM Viewpoints, Ken Birman and Fred Schneider wrote an interesting critique of the state of systems conferences titled “Program Committee Overload in Systems” (here’s a free pdf from Fred Schneider — the same content but without the fancy formatting of the CACM hardcopy). This CACM article seems like a follow-up and expansion of an earlier work of Ken’s I’ve blogged about (titled “Overcoming Challenges of Maturity”).
Anyway, I’m glad that some well-respected systems researchers are being vocal about these issues. It’s definitely good to know I’m not the only one with gripes; I’ve been somewhat cynical about this for a while, but since I have very little clout it helps to find a few senior systems researchers with some common concerns.
* Yes, I understand that “lower-level” is a matter of perspective. To my electrical and computer engineering colleagues, things like hypervisors and operating systems count as “high-level” “end-user” programming.
** If you look at DBLP, you will find a good bit more from current College of Computing faculty, but I’m counting publications where the author is at Georgia Tech when the publication is made (i.e. the author’s affiliation at the time of the publication).
*** Even presented well, good work on certain kinds of systems topics just doesn’t seem to be interesting to the PCs of these top conferences (the Europeans have been irked by this for years — leading to the establishment of EuroSys).
My personal take away from this blog:
1. Getting a faculty job in a decent university is reallllllllly hard. 2 OSDI, 3 SOSP and other publications on FAST?!?! It is hard to imagine myself making this kind of achievement in 5 years, even though I am lucky enough to work with his former advisor. (Would it be easier for research labs affilicated to companies? But you woundn't have grad students for most time of a year, and that's like a whole different ecosystem).
2. Publishing in top system conferences is kind of subjective (at least to me). You have to guess what will make PC interested, and it is still a bit mysterious to me :(
My advisor seems to have a quite different perspective on what is interesting work in the system area than I do; and I guess I should try to develop this kind of perspective too if I am seriously thinking about research as my career. (Still can not believe some debugging linux stuff get their way into OSDI, though...)
3. Congrats to Haryadi! This is like the first faculty in our group? Even though those guys in Microsoft research or national labs are also active in publishing papers (Eurosys, SIGOPS etc.), but I guess being in an university is different.
===========================================================================
I follow Ed Felten’s blog, Freedom To Tinker (which is actually now a blog for many people at Princeton’s Center for Information Technology Policy) — it has good coverage on issues like electronic voting and intellectual property. Dan Wallach, a well known security (among other things) researcher at Rice, published an interesting post titled “Acceptance rates at security conferences” assessing the state of academic CS conferences in the area of security. He points out that the conferences are getting increasingly competitive with an ever growing field of researchers and a relatively fixed number of conference venues; he notes that this will lead to certain “structural problems” in the research community and discusses potential options.
He also points to Matt Welsh‘s thoughts on similar issues in the systems community:
“Scaling up conferences”
“Scaling up program committees”
This is of particular interest to me since, as a PhD student, I am an academic systems researcher. Dan Wallach summarizes Matt first post as follows:
He argues that there’s a real disparity between the top programs / labs and everybody else and that it’s worthwhile to take steps to fix this. (I’ll argue that security conferences don’t seem to have this particular problem.) He also points out what I think is the deeper problem, which is that hotshot grad students must get themselves a long list of publications to have a crack at a decent faculty job. This was emphatically not the case ten years ago.
I definitely see what Matt is talking about in the systems community. For example, for a large subset of lower-level systems work*, SOSP and OSDI are a sort of gold standard in publication venues. Each conference is held every two years (alternating years between the two venues), so each year 20-30 papers will be accepted total (for reference, OSDI ’08 accepted 26/193 and SOSP ’07 accepted 25/131). Given the size of the systems community, that doesn’t give much leeway for up-and-coming researchers, but a publication in such a venue is virtually required to be competitive academically — as Matt describes it, a publication in these venues is “a highly prized commodity, and one that is becoming increasingly valued over time.” Matt says:
Several of us on the hiring committee were amazed at how many freshly-minted Ph.D.s were coming out with multiple papers in places like SOSP, OSDI, and NSDI. Clearly there is a lot more weight placed on getting those papers accepted than there used to be. … Somewhere along the way the ante has been upped considerably.
I notice this too. For example, Georgia Tech’s College of Computing (where I am finishing my PhD) was ranked in the top 10 graduate programs in CS (#9) by US News and World Report in 2008. For systems research specifically, we were also ranked in US News and World Report’s top 10 (#10) in 2008. Now, of course US News and World Report’s rankings are contentious and reducing the work of a whole bunch of different researchers in CS to a single dimensional ordinal representing the whole program is very subjective, but the point is only to say that our program can be considered competitive in the universe of CS graduate programs.
But if you look at our publishing track record in these two prized venues, we’re virtually unrepresented. If you look at the OSDI proceedings, you will see that a paper from Georgia Tech has never been accepted there (my 2008 submission was rejected, although it did get decently positive reviews), and we have two SOSP papers — one in 97 which was collaborative with Microsoft Research and involved only students and no Georgia Tech faculty (which makes me wonder if it was related to an internship) and one in 2007 which was a collaboration between a student in the Electrical and Computer Engineering and a professor in the College of Computing. Compare this college-wide record with that of Haryadi Gunawi, an excellent faculty candidate interviewing at Georgia Tech this year. In his career as a PhD student, he had 2 OSDI and 3 SOSP publications (plus publications in top venues in other areas, like PLDI, ISCA and FAST). As a student, he has amassed significantly more publications in these prized venues than our whole College of Computing can claim**. And other students from his advisor(s) have similarly impressive CVs. Look at the students of many other “rockstar” systems researchers and you’ll see the same pattern; we had a parade of great faculty candidates with similarly strong records.
So what am I supposed to make of this? I get a deep sense of cynicism when I see trends like this over many years. Matt says, “I don’t have hard data to back this up, but it feels that it is increasingly rare to see papers from anything other than ‘top ten’ universities and labs in the top venues.” I would go a step further and say that there’s a certain “clique” (or “cabal” if you want something sinister) of key researchers who facilitate virtually all of the publications in these venues. If you are a student of one of these researchers, or a nth-generation student (e.g. a student of a faculty member who once was a student of…), you know how to do work that appeals to the program committee and present it in the proper way — if you don’t have the right perspective on these fine points of taste, your chances are grim.*** As a student, if your advisor is a big name, you can have a paper in these top venues every year. If you don’t, you have very bleak academic job prospects. Now I’m definitely not trying to diminish Haryadi’s impressive accomplishments, and his research is very exciting. But I get the sense that there’s a very strong dis-proportionality in academic publishing in systems that is a lot worse than most other areas in computer science.
A comment to Matt’s first post and the end of Dan’s post also pointed me to another relevant article. In May’s CACM Viewpoints, Ken Birman and Fred Schneider wrote an interesting critique of the state of systems conferences titled “Program Committee Overload in Systems” (here’s a free pdf from Fred Schneider — the same content but without the fancy formatting of the CACM hardcopy). This CACM article seems like a follow-up and expansion of an earlier work of Ken’s I’ve blogged about (titled “Overcoming Challenges of Maturity”).
Anyway, I’m glad that some well-respected systems researchers are being vocal about these issues. It’s definitely good to know I’m not the only one with gripes; I’ve been somewhat cynical about this for a while, but since I have very little clout it helps to find a few senior systems researchers with some common concerns.
* Yes, I understand that “lower-level” is a matter of perspective. To my electrical and computer engineering colleagues, things like hypervisors and operating systems count as “high-level” “end-user” programming.
** If you look at DBLP, you will find a good bit more from current College of Computing faculty, but I’m counting publications where the author is at Georgia Tech when the publication is made (i.e. the author’s affiliation at the time of the publication).
*** Even presented well, good work on certain kinds of systems topics just doesn’t seem to be interesting to the PCs of these top conferences (the Europeans have been irked by this for years — leading to the establishment of EuroSys).
2010年11月28日星期日
linux software raid5 code reading notes (2)
A typical write process
1. When the bio corresponding to the write request is passed to make_request(), the sector number is first remapped into disk number and index within disk by raid5_compute_sector(), then get_active_stripe() is called to get the stripe this sector locates. Finally this bio is added to this stripe by add_stripe_bio().
2. Set STIPE_HANDLE bit of the current stripe
3. Calls into release_stripe() which will call mdev->thread (i.e, raid5d) to handle this stripe.
4. Raid5d calls into handle_stripe(), which calls handle_stripe5() for raid5.
5. Handle_stripe5() will call handle_stripe_dirtying5().
6. Handle_stripe_dirtying5() will first check whether a reconstruct-write or a read-modify-write is more preferable according to how many extra data needs to be read. Then it will make the R5_LOCKED and R5_Wantread flag for the disk buffer that needs to be read if this stripe is PREREAD_ACTIVE. (The PREREAD_ACTIVE flag is marked subject to the delay policy of raid5 described elsewhere). Handle_stripe_dirtying5() then returned w/ STRIPE_HANDLE flag cleared for the current stripe.
7. Handle_stripe5() will then call ops_run_io() to register I/O completion function to be raid5_end_read_request() and submit the read I/O requests for all the bio in rdev->req of each disk. Finally handle_stripe5() calls return_io() and returns.
8. Release_stripe() is called to clear the PREREAD_ACTIVE request. In the meantime, Raid5_end_read_request() will set R5_UPTODATE flag and STRIPE_HANDLE flag, and call release_stripe() function.
9. Again, with STRIPE_HANDLE flag, the handle_stripe5() function will be called. It calls into handle_stripe_dirtying5(), which in turn directly calls schedule_reconstruction() since all the disk buffers are uptodate.
10. Schedule_reconstruction() will mark STRIPE_OP_BIODRAIN and STRIPE_OP_RECONSTRUCT flag and R5_Wantdraian flag and set sh->reconstruct_state=reconstruct_state_drain_run for reconstruction write; or it will mark STRIPE_OP_PREXOR and STRIP_OP_BIODRAIN and STRIPE_OP_RECONSTRUCT and R5_Wantdrain flags for read-modify-write. It will also lock appropriate buffers.
11. Raid5_run_ops() is called. For read-modiry-writes, it calls ops_run_prexor() to calculate the xor results for old data and old parity block. Then ops_run_biodrain() is called (for both rcw and rmw) to copy data from bio to per-disk-cache. Finally ops_run_reconstruct5() is called, which calculates the parity block contents.
12. Ops_run_io() is called to register I/O completion function to be raid5_end_write_request() and submit I/O request for all the bio in rdev->req of each disk. Finally handle_stripe5() calls return_io() and returns.
13. Upon I/O completion, raid5_end_write_request() will clear R5_LOCKED flag and set STRIPE_HANDLE flag.
14. Again handle_stripe() is called, this time it does nothing but clear the STRIPE_HANDLE flag.
15. Control returns to make_request, which return the user-submitted bio.
1. When the bio corresponding to the write request is passed to make_request(), the sector number is first remapped into disk number and index within disk by raid5_compute_sector(), then get_active_stripe() is called to get the stripe this sector locates. Finally this bio is added to this stripe by add_stripe_bio().
2. Set STIPE_HANDLE bit of the current stripe
3. Calls into release_stripe() which will call mdev->thread (i.e, raid5d) to handle this stripe.
4. Raid5d calls into handle_stripe(), which calls handle_stripe5() for raid5.
5. Handle_stripe5() will call handle_stripe_dirtying5().
6. Handle_stripe_dirtying5() will first check whether a reconstruct-write or a read-modify-write is more preferable according to how many extra data needs to be read. Then it will make the R5_LOCKED and R5_Wantread flag for the disk buffer that needs to be read if this stripe is PREREAD_ACTIVE. (The PREREAD_ACTIVE flag is marked subject to the delay policy of raid5 described elsewhere). Handle_stripe_dirtying5() then returned w/ STRIPE_HANDLE flag cleared for the current stripe.
7. Handle_stripe5() will then call ops_run_io() to register I/O completion function to be raid5_end_read_request() and submit the read I/O requests for all the bio in rdev->req of each disk. Finally handle_stripe5() calls return_io() and returns.
8. Release_stripe() is called to clear the PREREAD_ACTIVE request. In the meantime, Raid5_end_read_request() will set R5_UPTODATE flag and STRIPE_HANDLE flag, and call release_stripe() function.
9. Again, with STRIPE_HANDLE flag, the handle_stripe5() function will be called. It calls into handle_stripe_dirtying5(), which in turn directly calls schedule_reconstruction() since all the disk buffers are uptodate.
10. Schedule_reconstruction() will mark STRIPE_OP_BIODRAIN and STRIPE_OP_RECONSTRUCT flag and R5_Wantdraian flag and set sh->reconstruct_state=reconstruct_state_drain_run for reconstruction write; or it will mark STRIPE_OP_PREXOR and STRIP_OP_BIODRAIN and STRIPE_OP_RECONSTRUCT and R5_Wantdrain flags for read-modify-write. It will also lock appropriate buffers.
11. Raid5_run_ops() is called. For read-modiry-writes, it calls ops_run_prexor() to calculate the xor results for old data and old parity block. Then ops_run_biodrain() is called (for both rcw and rmw) to copy data from bio to per-disk-cache. Finally ops_run_reconstruct5() is called, which calculates the parity block contents.
12. Ops_run_io() is called to register I/O completion function to be raid5_end_write_request() and submit I/O request for all the bio in rdev->req of each disk. Finally handle_stripe5() calls return_io() and returns.
13. Upon I/O completion, raid5_end_write_request() will clear R5_LOCKED flag and set STRIPE_HANDLE flag.
14. Again handle_stripe() is called, this time it does nothing but clear the STRIPE_HANDLE flag.
15. Control returns to make_request, which return the user-submitted bio.
linux software raid5 code reading notes (1)
Process of a typical read
1. When the bio corresponding to the read request is passed to make_request(), the sector number is first remapped into disk number and index within disk by raid5_compute_sector(), then get_active_stripe() is called to get the stripe this sector locates. Finally this bio is added to this stripe by add_stripe_bio().
2. Set STIPE_HANDLE bit of the current stripe
3. Calls into release_stripe() which will call mdev->thread (i.e, raid5d) to handle this stripe.
4. Raid5d calls into handle_stripe(), which calls handle_stripe5() for raid5.
5. Handle_stripe5() would call handle_stripe_fill5(), which will in turn call fetch_block5(). Fetch_block5() will set the R5_LOCKED and R5_WantRead flags, while handle_stripe_fill5() will set the STRIPE_HANDLE flag (which was previously cleared by handle_stripe5()).
6. Handle_stripe5() will then call ops_run_io() to register I/O completion function to be raid5_end_read_request() and submit I/O requests for all the bio in rdev->req of each disk. Finally handle_stripe5() calls return_io() and returns.
7. Raid5d then calls release_stripe(). Note: the I/O completion function raid5_end_read_request() and release_stripe() run in the same time???
8. Raid5_end_read_request() will set R5_UPTODATE flag and STRIPE_HANDLE flag, and call release_stripe() function.
9. Release_stripe() will again call handle_stripe() function. This time according to all the flags, handle_stripe() will call raiad_run_ops(), which will in turn call ops_run_biofill() to copy the data previous read to user-submitted bio asscociated buffer. Upon completion of this async coping, ops_complete_biofill() is called, which set STRIPE_HANDLE flag again.
10. This time handle_stripe() is called but it does nothing but clear STRIPE_HANDLE flag
11. Control returns to make_request, which calls bio_endio to return user-submitted bio.
12. Finally, calls into release_stripe() function which releases current stripe and if necessary, wake up raid5d to deal with other stipes.
1. When the bio corresponding to the read request is passed to make_request(), the sector number is first remapped into disk number and index within disk by raid5_compute_sector(), then get_active_stripe() is called to get the stripe this sector locates. Finally this bio is added to this stripe by add_stripe_bio().
2. Set STIPE_HANDLE bit of the current stripe
3. Calls into release_stripe() which will call mdev->thread (i.e, raid5d) to handle this stripe.
4. Raid5d calls into handle_stripe(), which calls handle_stripe5() for raid5.
5. Handle_stripe5() would call handle_stripe_fill5(), which will in turn call fetch_block5(). Fetch_block5() will set the R5_LOCKED and R5_WantRead flags, while handle_stripe_fill5() will set the STRIPE_HANDLE flag (which was previously cleared by handle_stripe5()).
6. Handle_stripe5() will then call ops_run_io() to register I/O completion function to be raid5_end_read_request() and submit I/O requests for all the bio in rdev->req of each disk. Finally handle_stripe5() calls return_io() and returns.
7. Raid5d then calls release_stripe(). Note: the I/O completion function raid5_end_read_request() and release_stripe() run in the same time???
8. Raid5_end_read_request() will set R5_UPTODATE flag and STRIPE_HANDLE flag, and call release_stripe() function.
9. Release_stripe() will again call handle_stripe() function. This time according to all the flags, handle_stripe() will call raiad_run_ops(), which will in turn call ops_run_biofill() to copy the data previous read to user-submitted bio asscociated buffer. Upon completion of this async coping, ops_complete_biofill() is called, which set STRIPE_HANDLE flag again.
10. This time handle_stripe() is called but it does nothing but clear STRIPE_HANDLE flag
11. Control returns to make_request, which calls bio_endio to return user-submitted bio.
12. Finally, calls into release_stripe() function which releases current stripe and if necessary, wake up raid5d to deal with other stipes.
2009年4月24日星期五
certified check & bank money order /bank draft（zz)
certified check & bank money order /bank draft(2008-11-08 23:32:51)
| 标签：杂谈 |
”字样 需要向银行购买，购买后一定金额
A．Certified check
需要向银行购买，购买后一定金额的保付支票后，存款账户上与支票等额的金额就会被冻结，收款人用支票到银行承兑时这部分金额才会被扣除。
B.Bank Money order (O/M)&bank bill/bank draft (B/D)都为 银行汇票
在购买后，存款帐户上与汇票等额的金额会被立即扣除。
这两大类票据对收款人来说都是保证支付的兑现的票据，bank draft有可能会被收取手续费。
的保付支票后，存款账户上与支票等额的金额对付款人来说，certified check手续费比bank draft
2009年3月9日星期一
Linux用iptables共享上网
1.在farm上的设置
打开ip转发：echo "1" >/proc/sys/net/ipv4/ip_forward
打开NAT：iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
2.在node上的设置
修改路由表：route del default (192.168.0.0/24的不要去动它）
route add default gw hepfarm02
修改dns文件：把/etc/resolv.conf改成如下内容：
search phy.pku.edu.cn
nameserver 162.105.129.26
nameserver 162.105.129.27
node连接未名测试通过
打开ip转发：echo "1" >/proc/sys/net/ipv4/ip_forward
打开NAT：iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
2.在node上的设置
修改路由表：route del default (192.168.0.0/24的不要去动它）
route add default gw hepfarm02
修改dns文件：把/etc/resolv.conf改成如下内容：
search phy.pku.edu.cn
nameserver 162.105.129.26
nameserver 162.105.129.27
node连接未名测试通过
订阅：
博文 (Atom)