Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1276776 > unrolled thread
| Started by | Mark Fasheh <mfasheh@suse.de> |
|---|---|
| First post | 2015-11-24 22:50 +0100 |
| Last post | 2015-11-25 05:40 +0100 |
| Articles | 6 — 4 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH v2 2/4] ocfs2: sysfile interfaces for online file check Mark Fasheh <mfasheh@suse.de> - 2015-11-24 22:50 +0100
Re: [Ocfs2-devel] [PATCH v2 2/4] ocfs2: sysfile interfaces for online file check Srinivas Eeda <srinivas.eeda@oracle.com> - 2015-11-24 23:00 +0100
Re: [PATCH v2 2/4] ocfs2: sysfile interfaces for online file check "Gang He" <ghe@suse.com> - 2015-11-25 04:30 +0100
Re: [PATCH v2 2/4] ocfs2: sysfile interfaces for online file check Junxiao Bi <junxiao.bi@oracle.com> - 2015-11-25 05:50 +0100
Re: [PATCH v2 2/4] ocfs2: sysfile interfaces for online file check "Gang He" <ghe@suse.com> - 2015-11-25 06:20 +0100
Re: [PATCH v2 2/4] ocfs2: sysfile interfaces for online file check Junxiao Bi <junxiao.bi@oracle.com> - 2015-11-25 05:40 +0100
| From | Mark Fasheh <mfasheh@suse.de> |
|---|---|
| Date | 2015-11-24 22:50 +0100 |
| Subject | Re: [PATCH v2 2/4] ocfs2: sysfile interfaces for online file check |
| Message-ID | <qytDj-5dS-1@gated-at.bofh.it> |
On Tue, Nov 03, 2015 at 04:20:27PM +0800, Junxiao Bi wrote: > Hi Gang, > > On 11/03/2015 03:54 PM, Gang He wrote: > > Hi Junxiao, > > > > Thank for your reviewing. > > Current design, we use a sysfile as a interface to check/fix a file (via pass a ino number). > > But, this operation is manually triggered by user, instead of automatically fix in the kernel. > > Why? > > 1) we should let users make this decision, since some users do not want to fix when encountering a file system corruption, maybe they want to keep the file system unchanged for a further investigation. > If user don't want this, they should not use error=continue option, let > fs go after a corruption is very dangerous. Maybe we need another errors=XXX flag (maybe errors=fix)? You both make good points, here's what I gather from the conversation: - Some customers would be sad if they have to manually fix corruptions. This takes effort on their part, and if the FS can handle it automatically, it should. - There are valid concerns that automatically fixing things is a change in behavior that might not be welcome, or worse might lead to unforseeable circumstances. - I will add that fixing things automatically implies checking them automatically which could introduce some performance impact depending on how much checking we're doing. So if the user wants errors to be fixed automatically, they could mount with errros=fix, and everyone else would have no change in behavior unless they wanted to make use of the new feature. > > 2) frankly speaking, this feature will probably bring a second corruption if there is some error in the code, I do not suggest to use automatically fix by default in the first version. > I think if this feature could bring more corruption, then this should be > fixed first. Btw, I am pretty sure that Gang is referring to the feature being new and thus more likely to have problems. There is nothing I see in here that is file system corrupting. --Mark -- Mark Fasheh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | Srinivas Eeda <srinivas.eeda@oracle.com> |
|---|---|
| Date | 2015-11-24 23:00 +0100 |
| Subject | Re: [Ocfs2-devel] [PATCH v2 2/4] ocfs2: sysfile interfaces for online file check |
| Message-ID | <qytN1-5hB-19@gated-at.bofh.it> |
| In reply to | #1276776 |
On 11/24/2015 01:46 PM, Mark Fasheh wrote: > On Tue, Nov 03, 2015 at 04:20:27PM +0800, Junxiao Bi wrote: >> Hi Gang, >> >> On 11/03/2015 03:54 PM, Gang He wrote: >>> Hi Junxiao, >>> >>> Thank for your reviewing. >>> Current design, we use a sysfile as a interface to check/fix a file (via pass a ino number). >>> But, this operation is manually triggered by user, instead of automatically fix in the kernel. >>> Why? >>> 1) we should let users make this decision, since some users do not want to fix when encountering a file system corruption, maybe they want to keep the file system unchanged for a further investigation. >> If user don't want this, they should not use error=continue option, let >> fs go after a corruption is very dangerous. > Maybe we need another errors=XXX flag (maybe errors=fix)? Great idea Mark! I think adding errors=fix would be a good way to address both concerns :) It gives some control if anyone is uncomfortable of things getting checked/fixed automatically. > > You both make good points, here's what I gather from the conversation: > > - Some customers would be sad if they have to manually fix corruptions. > This takes effort on their part, and if the FS can handle it > automatically, it should. > > - There are valid concerns that automatically fixing things is a change in > behavior that might not be welcome, or worse might lead to unforseeable > circumstances. > > - I will add that fixing things automatically implies checking them > automatically which could introduce some performance impact depending on > how much checking we're doing. > > So if the user wants errors to be fixed automatically, they could mount with > errros=fix, and everyone else would have no change in behavior unless they > wanted to make use of the new feature. > > >>> 2) frankly speaking, this feature will probably bring a second corruption if there is some error in the code, I do not suggest to use automatically fix by default in the first version. >> I think if this feature could bring more corruption, then this should be >> fixed first. > Btw, I am pretty sure that Gang is referring to the feature being new and > thus more likely to have problems. There is nothing I see in here that is > file system corrupting. > --Mark > > > -- > Mark Fasheh > > _______________________________________________ > Ocfs2-devel mailing list > Ocfs2-devel@oss.oracle.com > https://oss.oracle.com/mailman/listinfo/ocfs2-devel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "Gang He" <ghe@suse.com> |
|---|---|
| Date | 2015-11-25 04:30 +0100 |
| Subject | Re: [PATCH v2 2/4] ocfs2: sysfile interfaces for online file check |
| Message-ID | <qyyWl-v3-9@gated-at.bofh.it> |
| In reply to | #1276776 |
Hi Mark and Junxiao, >>> > On Tue, Nov 03, 2015 at 04:20:27PM +0800, Junxiao Bi wrote: >> Hi Gang, >> >> On 11/03/2015 03:54 PM, Gang He wrote: >> > Hi Junxiao, >> > >> > Thank for your reviewing. >> > Current design, we use a sysfile as a interface to check/fix a file (via > pass a ino number). >> > But, this operation is manually triggered by user, instead of automatically > fix in the kernel. >> > Why? >> > 1) we should let users make this decision, since some users do not want to > fix when encountering a file system corruption, maybe they want to keep the > file system unchanged for a further investigation. >> If user don't want this, they should not use error=continue option, let >> fs go after a corruption is very dangerous. > > Maybe we need another errors=XXX flag (maybe errors=fix)? > > You both make good points, here's what I gather from the conversation: > > - Some customers would be sad if they have to manually fix corruptions. > This takes effort on their part, and if the FS can handle it > automatically, it should. > > - There are valid concerns that automatically fixing things is a change in > behavior that might not be welcome, or worse might lead to unforseeable > circumstances. > > - I will add that fixing things automatically implies checking them > automatically which could introduce some performance impact depending on > how much checking we're doing. > > So if the user wants errors to be fixed automatically, they could mount with > errros=fix, and everyone else would have no change in behavior unless they > wanted to make use of the new feature. That is what I want to say, add a mount option to let users to decide. Here, I want to split "error=fix" mount option task out from online file check feature, I think this part should be a independent feature. We can implement this feature after online file check is done, I want to split the feature into some more detailed features, implement them one by one. Do you agree this point? > > >> > 2) frankly speaking, this feature will probably bring a second corruption > if there is some error in the code, I do not suggest to use automatically fix > by default in the first version. >> I think if this feature could bring more corruption, then this should be >> fixed first. > > Btw, I am pretty sure that Gang is referring to the feature being new and > thus more likely to have problems. There is nothing I see in here that is > file system corrupting. > --Mark > > > -- > Mark Fasheh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Junxiao Bi <junxiao.bi@oracle.com> |
|---|---|
| Date | 2015-11-25 05:50 +0100 |
| Message-ID | <qyAbL-1dF-3@gated-at.bofh.it> |
| In reply to | #1276996 |
Hi Gang, On 11/25/2015 11:29 AM, Gang He wrote: > Hi Mark and Junxiao, > > >>>> >> On Tue, Nov 03, 2015 at 04:20:27PM +0800, Junxiao Bi wrote: >>> Hi Gang, >>> >>> On 11/03/2015 03:54 PM, Gang He wrote: >>>> Hi Junxiao, >>>> >>>> Thank for your reviewing. >>>> Current design, we use a sysfile as a interface to check/fix a file (via >> pass a ino number). >>>> But, this operation is manually triggered by user, instead of automatically >> fix in the kernel. >>>> Why? >>>> 1) we should let users make this decision, since some users do not want to >> fix when encountering a file system corruption, maybe they want to keep the >> file system unchanged for a further investigation. >>> If user don't want this, they should not use error=continue option, let >>> fs go after a corruption is very dangerous. >> >> Maybe we need another errors=XXX flag (maybe errors=fix)? >> >> You both make good points, here's what I gather from the conversation: >> >> - Some customers would be sad if they have to manually fix corruptions. >> This takes effort on their part, and if the FS can handle it >> automatically, it should. >> >> - There are valid concerns that automatically fixing things is a change in >> behavior that might not be welcome, or worse might lead to unforseeable >> circumstances. >> >> - I will add that fixing things automatically implies checking them >> automatically which could introduce some performance impact depending on >> how much checking we're doing. >> >> So if the user wants errors to be fixed automatically, they could mount with >> errros=fix, and everyone else would have no change in behavior unless they >> wanted to make use of the new feature. > That is what I want to say, add a mount option to let users to decide. Here, I want to split "error=fix" > mount option task out from online file check feature, I think this part should be a independent feature. > We can implement this feature after online file check is done, I want to split the feature into some more > detailed features, implement them one by one. Do you agree this point? With error=fix, when a possible corruption is found, online fsck will start to check and fix things. So this doesn't looks like a independent feature. Thanks, Junxiao. > >> >> >>>> 2) frankly speaking, this feature will probably bring a second corruption >> if there is some error in the code, I do not suggest to use automatically fix >> by default in the first version. >>> I think if this feature could bring more corruption, then this should be >>> fixed first. >> >> Btw, I am pretty sure that Gang is referring to the feature being new and >> thus more likely to have problems. There is nothing I see in here that is >> file system corrupting. >> --Mark >> >> >> -- >> Mark Fasheh > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | "Gang He" <ghe@suse.com> |
|---|---|
| Date | 2015-11-25 06:20 +0100 |
| Subject | Re: [PATCH v2 2/4] ocfs2: sysfile interfaces for online file check |
| Message-ID | <qyAEO-1Eh-5@gated-at.bofh.it> |
| In reply to | #1277013 |
Hi Junxiao, >>> > Hi Gang, > > On 11/25/2015 11:29 AM, Gang He wrote: >> Hi Mark and Junxiao, >> >> >>>>> >>> On Tue, Nov 03, 2015 at 04:20:27PM +0800, Junxiao Bi wrote: >>>> Hi Gang, >>>> >>>> On 11/03/2015 03:54 PM, Gang He wrote: >>>>> Hi Junxiao, >>>>> >>>>> Thank for your reviewing. >>>>> Current design, we use a sysfile as a interface to check/fix a file (via >>> pass a ino number). >>>>> But, this operation is manually triggered by user, instead of automatically >>> fix in the kernel. >>>>> Why? >>>>> 1) we should let users make this decision, since some users do not want to >>> fix when encountering a file system corruption, maybe they want to keep the >>> file system unchanged for a further investigation. >>>> If user don't want this, they should not use error=continue option, let >>>> fs go after a corruption is very dangerous. >>> >>> Maybe we need another errors=XXX flag (maybe errors=fix)? >>> >>> You both make good points, here's what I gather from the conversation: >>> >>> - Some customers would be sad if they have to manually fix corruptions. >>> This takes effort on their part, and if the FS can handle it >>> automatically, it should. >>> >>> - There are valid concerns that automatically fixing things is a change in >>> behavior that might not be welcome, or worse might lead to unforseeable >>> circumstances. >>> >>> - I will add that fixing things automatically implies checking them >>> automatically which could introduce some performance impact depending on >>> how much checking we're doing. >>> >>> So if the user wants errors to be fixed automatically, they could mount with >>> errros=fix, and everyone else would have no change in behavior unless they >>> wanted to make use of the new feature. >> That is what I want to say, add a mount option to let users to decide. Here, > I want to split "error=fix" >> mount option task out from online file check feature, I think this part > should be a independent feature. >> We can implement this feature after online file check is done, I want to > split the feature into some more >> detailed features, implement them one by one. Do you agree this point? > With error=fix, when a possible corruption is found, online fsck will > start to check and fix things. So this doesn't looks like a independent > feature. My means is, we can implement online file check by manually triage feature first, then Add a mount option "error=fix" feature, the second feature can be implemented after the first part is done. I want to split them into more detailed items, maybe it is more helpful to be reviewed, but the whole feature ideas are very OK, just need to do one by one. > > Thanks, > Junxiao. > >> >>> >>> >>>>> 2) frankly speaking, this feature will probably bring a second corruption >>> if there is some error in the code, I do not suggest to use automatically > fix >>> by default in the first version. >>>> I think if this feature could bring more corruption, then this should be >>>> fixed first. >>> >>> Btw, I am pretty sure that Gang is referring to the feature being new and >>> thus more likely to have problems. There is nothing I see in here that is >>> file system corrupting. >>> --Mark >>> >>> >>> -- >>> Mark Fasheh >> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Junxiao Bi <junxiao.bi@oracle.com> |
|---|---|
| Date | 2015-11-25 05:40 +0100 |
| Message-ID | <qyA25-1a1-1@gated-at.bofh.it> |
| In reply to | #1276776 |
On 11/25/2015 05:46 AM, Mark Fasheh wrote: > On Tue, Nov 03, 2015 at 04:20:27PM +0800, Junxiao Bi wrote: >> Hi Gang, >> >> On 11/03/2015 03:54 PM, Gang He wrote: >>> Hi Junxiao, >>> >>> Thank for your reviewing. >>> Current design, we use a sysfile as a interface to check/fix a file (via pass a ino number). >>> But, this operation is manually triggered by user, instead of automatically fix in the kernel. >>> Why? >>> 1) we should let users make this decision, since some users do not want to fix when encountering a file system corruption, maybe they want to keep the file system unchanged for a further investigation. >> If user don't want this, they should not use error=continue option, let >> fs go after a corruption is very dangerous. > > Maybe we need another errors=XXX flag (maybe errors=fix)? Sound great. This is a good option since user may have not enough knowledge whether to fix the found issue. Thanks, Junxiao. > > You both make good points, here's what I gather from the conversation: > > - Some customers would be sad if they have to manually fix corruptions. > This takes effort on their part, and if the FS can handle it > automatically, it should. > > - There are valid concerns that automatically fixing things is a change in > behavior that might not be welcome, or worse might lead to unforseeable > circumstances. > > - I will add that fixing things automatically implies checking them > automatically which could introduce some performance impact depending on > how much checking we're doing. > > So if the user wants errors to be fixed automatically, they could mount with > errros=fix, and everyone else would have no change in behavior unless they > wanted to make use of the new feature. > > >>> 2) frankly speaking, this feature will probably bring a second corruption if there is some error in the code, I do not suggest to use automatically fix by default in the first version. >> I think if this feature could bring more corruption, then this should be >> fixed first. > > Btw, I am pretty sure that Gang is referring to the feature being new and > thus more likely to have problems. There is nothing I see in here that is > file system corrupting. > --Mark > > > -- > Mark Fasheh > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web