Re: RFC: Revert move default dialect from CIFS to to SMB3
On Fri, 2017-09-01 at 20:56 -0700, Linus Torvalds wrote: > On Fri, Sep 1, 2017 at 7:16 PM, Steve French <smfre...@gmail.com> wrote: > > > > The default was SMB1 (CIFS) and was recently changed to SMB3. > > The dialect still can be overridden by specifying "vers=1.0" or "vers=2.1" > > etc. on mount. > > > > We just put together a patch to better explain the default changes > > (with additional warning messages) as suggested. > > > > SMB3 is significantly better than SMB2.1 (supporting encrypted shares > > and sessions for example, and requiring support for "secure negotiate") > > and some servers require SMB3 minimum as a result, > > The default shouldn't be about "best and most secure", but "most > convenient, while still not actively *IN*secure" > > So "some servers require 3.0" may be true, but if it's also the case > that "most servers still don't do 3.0 at all", then it's a "some" vs > "most". > > Which is the most common one? That should be the default. > > I realize that eventually we'll have auto-negotiation, but that's > clearly not for 4.13. So in the meantime the only issue is what the > right default should be without auto-negotiation. > > So it should be about what the failure rate is. If trying for smb3 has > a high failure rate because people simply don't have that yet, then > making that the default was clearly the wrong choice. > > Because being "better" is immaterial if it doesn't work. My quick research shows: SMB 2.1 but not SMB3 is on: Windows 7 Windows 8 Windows 2008 Windows 2012 Samba 3.6 and earlier (SMB1 only by default) SMB3 is on: Windows 8.1 Windows 2012 R2 Windows 10 Windows 2016 Samba 4.0 and above (released 2012) I'm not sure exactly which Mac versions. Some breakage will be old (and quite recent) NAS and routers that use SMB1 and often very old Samba, but most of those only do SMB1. In terms of 'actively *IN*secure', it really depends what you mean by that. That is, like all big changes, the movement against SMB1 has had multiple motivations: - a desire no longer to expose really old code in Windows (recently exploited) - a desire to retire an old and complex protocol - SMB3 having proper secure negotiation (I'll leave it to Steve to explain the difference between SMB2 and 3 in that respect, I'm not so current on the details). I hope this help, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
Re: RFC: Revert move default dialect from CIFS to to SMB3
On Fri, 2017-09-01 at 20:56 -0700, Linus Torvalds wrote: > On Fri, Sep 1, 2017 at 7:16 PM, Steve French wrote: > > > > The default was SMB1 (CIFS) and was recently changed to SMB3. > > The dialect still can be overridden by specifying "vers=1.0" or "vers=2.1" > > etc. on mount. > > > > We just put together a patch to better explain the default changes > > (with additional warning messages) as suggested. > > > > SMB3 is significantly better than SMB2.1 (supporting encrypted shares > > and sessions for example, and requiring support for "secure negotiate") > > and some servers require SMB3 minimum as a result, > > The default shouldn't be about "best and most secure", but "most > convenient, while still not actively *IN*secure" > > So "some servers require 3.0" may be true, but if it's also the case > that "most servers still don't do 3.0 at all", then it's a "some" vs > "most". > > Which is the most common one? That should be the default. > > I realize that eventually we'll have auto-negotiation, but that's > clearly not for 4.13. So in the meantime the only issue is what the > right default should be without auto-negotiation. > > So it should be about what the failure rate is. If trying for smb3 has > a high failure rate because people simply don't have that yet, then > making that the default was clearly the wrong choice. > > Because being "better" is immaterial if it doesn't work. My quick research shows: SMB 2.1 but not SMB3 is on: Windows 7 Windows 8 Windows 2008 Windows 2012 Samba 3.6 and earlier (SMB1 only by default) SMB3 is on: Windows 8.1 Windows 2012 R2 Windows 10 Windows 2016 Samba 4.0 and above (released 2012) I'm not sure exactly which Mac versions. Some breakage will be old (and quite recent) NAS and routers that use SMB1 and often very old Samba, but most of those only do SMB1. In terms of 'actively *IN*secure', it really depends what you mean by that. That is, like all big changes, the movement against SMB1 has had multiple motivations: - a desire no longer to expose really old code in Windows (recently exploited) - a desire to retire an old and complex protocol - SMB3 having proper secure negotiation (I'll leave it to Steve to explain the difference between SMB2 and 3 in that respect, I'm not so current on the details). I hope this help, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Catalyst IT http://catalyst.net.nz/services/samba
Re: Read support for fat_fallocate()? (was [v2] fat: editions to support fat_fallocate())
On Mon, 2013-02-18 at 20:36 +0900, OGAWA Hirofumi wrote: > Andrew Bartlett writes: > > Or, if we cannot make any changes to the on-disk format, what about > > keeping such a database in memory, allocating some of the existing free > > list to files that have had fallocate() called on them? (Naturally, > > this makes it non-persistent, and instead more of a 'hint', but could at > > least solve our mutual performance issues). > > [...] > > Hm. My concerns are compatibility and reliability. Although We can > change on-disk format if need, but I don't think it can be compatible > and reliable. If so, who wants to use it? I feel there is no reason to > use FAT if there is no compatible. > > Well, anyway, possible solution would be, we can pre-allocate physical > blocks via fallocate(2) or something, but discard pre-allocated blocks > at ->release() (or before unmount at least). This way would have > compatibility (no on-disk change over unmount) and possible breakage > would be same with normal extend write patterns on kernel crash > (i.e. Windows or fsck will truncate after i_size). That would certainly give me what the Samba NAS with USB FAT disk use case needs. Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Read support for fat_fallocate()? (was [v2] fat: editions to support fat_fallocate())
On Mon, 2013-02-18 at 20:36 +0900, OGAWA Hirofumi wrote: Andrew Bartlett abart...@samba.org writes: Or, if we cannot make any changes to the on-disk format, what about keeping such a database in memory, allocating some of the existing free list to files that have had fallocate() called on them? (Naturally, this makes it non-persistent, and instead more of a 'hint', but could at least solve our mutual performance issues). [...] Hm. My concerns are compatibility and reliability. Although We can change on-disk format if need, but I don't think it can be compatible and reliable. If so, who wants to use it? I feel there is no reason to use FAT if there is no compatible. Well, anyway, possible solution would be, we can pre-allocate physical blocks via fallocate(2) or something, but discard pre-allocated blocks at -release() (or before unmount at least). This way would have compatibility (no on-disk change over unmount) and possible breakage would be same with normal extend write patterns on kernel crash (i.e. Windows or fsck will truncate after i_size). That would certainly give me what the Samba NAS with USB FAT disk use case needs. Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Read support for fat_fallocate()? (was [v2] fat: editions to support fat_fallocate())
On Thu, 2013-02-14 at 18:52 +0900, Namjae Jeon wrote: > [snip] > >> > > >> > Thanks, > >> Hi Andrew. > >> > >> First, Thanks for your interest ! > >> A mismatch between inode size and reserved blocks can be either due to > >> pre-allocation (after our changes) or due to corruption (sudden unplug > >> of media etc). > >> We don’t think it is right to include only read only support (i.e. > >> without fallocate support) for such files because if such files are > >> encountered it only means that the file is corrupted, as there is no > >> current method to check if the issue is due to pre-allocation. > >> If it is to be included in the kernel, then the whole patch has to go > >> in. > > > > I don't see why that is the case. > If we consider that there is no FALLOCATE support, then the condition > of file size and blocks not matching can be only possible in case of > corruption, right? Sure. I was just suggesting we transparently recover from that, by using the blocks. Think of it more as an online fsck not about fallocate. Anyway, if you don't think it's reasonable to use those blocks, or to 'just fix it', then we just have to continue to do as we currently do. That is on first sign of FS corruption just stop doing writes, and await an FSCK. > >> But then again, since the FAT specifications do not accommodate > >> for pre-allocation, then it is up to OGAWA to decide if this is > >> acceptable. > >> In any case, the patch will definitely break backward compatibility > >> (on an older fat driver without fallocate support) and also in case > >> for the two variants for the same kernel versions and only one has > >> FALLOCATE enabled, in such cases also, the behavior will assume > >> corruption in one case. > > > > I agree that the sudden unplug is a concern, but why not make the > > filesystem more robust against that inevitable occurrence? If the > > blocks appear to be allocated to the file, why not use them? > We also agree that there should be pre-allocation feature on FAT, and > we had shared the scenarios where this could be required for a TV/ > recorder. > But there are certain drawbacks which were raised by OGAWA with > respect to compatibility and we also tend to agree on them. > There could possibly be an issue where we are unable to distinguish > between pre-allocation and corruption. Perhaps we could set a status > bit on the file to indicate whether the file has pre-allocated blocks. > This will make it clear whether the allocation is genuine through the > FAT Fallocate request or is a result of corruption. Depending on the > status of the flag - the decision can be made regard to reading > blocks. > But, the main issue in this will be storing this bit in on-disk > directory entry for that file. From the feature and usability point of > view, we should have fallocate on FAT too. > > But it needs initial ACK from OGAWA to continue to work on this so > that we can figure out the proper solution to move forward. OK. Given the need to find other approaches, I wanted to suggest some ideas - some of which you may have already considered: What about having a shadow FAT in a file, say called 'allocated space', that would contain inode -> cluster list pairs, and where that file would itself contain the free space the 'belongs' to other files? As new clusters become needed in a file, they would simply be removed from the 'allocated space' file, and assigned to the file they really belong to. That way, another OS just sees a large file, nothing more. Or, if we cannot make any changes to the on-disk format, what about keeping such a database in memory, allocating some of the existing free list to files that have had fallocate() called on them? (Naturally, this makes it non-persistent, and instead more of a 'hint', but could at least solve our mutual performance issues). Or, could we leave allocated but unused clusters in the free cluster list, but maintain a file with a hint that a particular file should use a particular free cluster next, if available? That list of 'allocated free' clusters could be honoured by fallocate-aware OSs to reduce df and increase du, but be ignored by other OSs, ensuring you could not run out of space expanding a file in another OS. If a cluster was observed no longer to be in the real free list, it would be ignored in the 'allocated free' list, to avoid corruption. In short, I see the restriction on not breaking existing implementations as a difficult, but certainty not impossible problem. Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Read support for fat_fallocate()? (was [v2] fat: editions to support fat_fallocate())
On Thu, 2013-02-14 at 18:52 +0900, Namjae Jeon wrote: [snip] Thanks, Hi Andrew. First, Thanks for your interest ! A mismatch between inode size and reserved blocks can be either due to pre-allocation (after our changes) or due to corruption (sudden unplug of media etc). We don’t think it is right to include only read only support (i.e. without fallocate support) for such files because if such files are encountered it only means that the file is corrupted, as there is no current method to check if the issue is due to pre-allocation. If it is to be included in the kernel, then the whole patch has to go in. I don't see why that is the case. If we consider that there is no FALLOCATE support, then the condition of file size and blocks not matching can be only possible in case of corruption, right? Sure. I was just suggesting we transparently recover from that, by using the blocks. Think of it more as an online fsck not about fallocate. Anyway, if you don't think it's reasonable to use those blocks, or to 'just fix it', then we just have to continue to do as we currently do. That is on first sign of FS corruption just stop doing writes, and await an FSCK. But then again, since the FAT specifications do not accommodate for pre-allocation, then it is up to OGAWA to decide if this is acceptable. In any case, the patch will definitely break backward compatibility (on an older fat driver without fallocate support) and also in case for the two variants for the same kernel versions and only one has FALLOCATE enabled, in such cases also, the behavior will assume corruption in one case. I agree that the sudden unplug is a concern, but why not make the filesystem more robust against that inevitable occurrence? If the blocks appear to be allocated to the file, why not use them? We also agree that there should be pre-allocation feature on FAT, and we had shared the scenarios where this could be required for a TV/ recorder. But there are certain drawbacks which were raised by OGAWA with respect to compatibility and we also tend to agree on them. There could possibly be an issue where we are unable to distinguish between pre-allocation and corruption. Perhaps we could set a status bit on the file to indicate whether the file has pre-allocated blocks. This will make it clear whether the allocation is genuine through the FAT Fallocate request or is a result of corruption. Depending on the status of the flag - the decision can be made regard to reading blocks. But, the main issue in this will be storing this bit in on-disk directory entry for that file. From the feature and usability point of view, we should have fallocate on FAT too. But it needs initial ACK from OGAWA to continue to work on this so that we can figure out the proper solution to move forward. OK. Given the need to find other approaches, I wanted to suggest some ideas - some of which you may have already considered: What about having a shadow FAT in a file, say called 'allocated space', that would contain inode - cluster list pairs, and where that file would itself contain the free space the 'belongs' to other files? As new clusters become needed in a file, they would simply be removed from the 'allocated space' file, and assigned to the file they really belong to. That way, another OS just sees a large file, nothing more. Or, if we cannot make any changes to the on-disk format, what about keeping such a database in memory, allocating some of the existing free list to files that have had fallocate() called on them? (Naturally, this makes it non-persistent, and instead more of a 'hint', but could at least solve our mutual performance issues). Or, could we leave allocated but unused clusters in the free cluster list, but maintain a file with a hint that a particular file should use a particular free cluster next, if available? That list of 'allocated free' clusters could be honoured by fallocate-aware OSs to reduce df and increase du, but be ignored by other OSs, ensuring you could not run out of space expanding a file in another OS. If a cluster was observed no longer to be in the real free list, it would be ignored in the 'allocated free' list, to avoid corruption. In short, I see the restriction on not breaking existing implementations as a difficult, but certainty not impossible problem. Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Read support for fat_fallocate()? (was [v2] fat: editions to support fat_fallocate())
On Thu, 2013-02-14 at 15:44 +0900, Namjae Jeon wrote: > 2013/2/14, Andrew Bartlett : > > (apologies for the duplicate mail, I typo-ed the maintainers address) > > > > G'day, > > > > I've been looking into the patch "[v2] fat: editions to support > > fat_fallocate()" and I wonder if there is a way we can split this issue > > in two, so that we get at least some of the patch into the kernel. > > > > https://lkml.org/lkml/2012/10/13/75 > > https://patchwork.kernel.org/patch/1589161/ > > > > What I'm wanting to discuss (and perhaps implement, with you if > > possible) is splitting this patch into writing to existing pre-allocated > > files, and creating a new pre-allocation. > > > > If Windows does, as you claim, simply read preallocations as zero, and > > writes to them normally and without error, then Linux should do the > > same. Here of course I'm assuming that Windows is not preallocating, > > but instead simply trying to recover gracefully and safely from a simple > > 'file system corruption', where the sectors are allocated but not used. > > > > The bulk of this patch is implementing this transparent recovery, and it > > seem relatively harmless to include this into the kernel. > > > > Then vendors doing TV streaming, or in my case copies of large files > > onto Samba-mounted USB FAT devices, can add only the smaller patch to > > implement fallocate, at their own risk and fully knowing that it will be > > regarded as corrupt on Linux. > > > > If accepted read support will, over a period of years, trickle down to > > other Linux users, broadening the base that can still read these > > 'corrupt' drives, no matter the cause. > > > > I hope you agree that this is a practical way forward, and I look > > forward to working with you on this. > > > > Thanks, > Hi Andrew. > > First, Thanks for your interest ! > A mismatch between inode size and reserved blocks can be either due to > pre-allocation (after our changes) or due to corruption (sudden unplug > of media etc). > We don’t think it is right to include only read only support (i.e. > without fallocate support) for such files because if such files are > encountered it only means that the file is corrupted, as there is no > current method to check if the issue is due to pre-allocation. > If it is to be included in the kernel, then the whole patch has to go > in. I don't see why that is the case. > But then again, since the FAT specifications do not accommodate > for pre-allocation, then it is up to OGAWA to decide if this is > acceptable. > In any case, the patch will definitely break backward compatibility > (on an older fat driver without fallocate support) and also in case > for the two variants for the same kernel versions and only one has > FALLOCATE enabled, in such cases also, the behavior will assume > corruption in one case. I agree that the sudden unplug is a concern, but why not make the filesystem more robust against that inevitable occurrence? If the blocks appear to be allocated to the file, why not use them? That is, while it is hard to predict the many different ways a filesystem can be corrupted, what would go wrong if we did use these clusters? Do you fear that they might also be allocated to someone else? That would, if I understand correctly just mean that that more broken, not quite valid USB thumb drives and other FAT filesystems work equally well on Windows and Linux, without administrative privileges. (Given that running fsck requires root, and isn't trivially available to normal users in Linux, and I presume is similarly privileged in windows). What I'm doing is suggesting re-purposing your patch, from preallocation to robustness. In this light, do you think this worth pushing forward? We can later address if there is any safe way to preallocate files on FAT as a different question, hoping that this means it will 'just work' on a broader range of other Linux hosts, just as it is claimed to 'just work' on Windows. Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Read support for fat_fallocate()? (was [v2] fat: editions to support fat_fallocate())
(apologies for the duplicate mail, I typo-ed the maintainers address) G'day, I've been looking into the patch "[v2] fat: editions to support fat_fallocate()" and I wonder if there is a way we can split this issue in two, so that we get at least some of the patch into the kernel. https://lkml.org/lkml/2012/10/13/75 https://patchwork.kernel.org/patch/1589161/ What I'm wanting to discuss (and perhaps implement, with you if possible) is splitting this patch into writing to existing pre-allocated files, and creating a new pre-allocation. If Windows does, as you claim, simply read preallocations as zero, and writes to them normally and without error, then Linux should do the same. Here of course I'm assuming that Windows is not preallocating, but instead simply trying to recover gracefully and safely from a simple 'file system corruption', where the sectors are allocated but not used. The bulk of this patch is implementing this transparent recovery, and it seem relatively harmless to include this into the kernel. Then vendors doing TV streaming, or in my case copies of large files onto Samba-mounted USB FAT devices, can add only the smaller patch to implement fallocate, at their own risk and fully knowing that it will be regarded as corrupt on Linux. If accepted read support will, over a period of years, trickle down to other Linux users, broadening the base that can still read these 'corrupt' drives, no matter the cause. I hope you agree that this is a practical way forward, and I look forward to working with you on this. Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Read support for fat_fallocate()? (was [v2] fat: editions to support fat_fallocate())
G'day, I've been looking into the patch "[v2] fat: editions to support fat_fallocate()" and I wonder if there is a way we can split this issue in two, so that we get at least some of the patch into the kernel. https://lkml.org/lkml/2012/10/13/75 https://patchwork.kernel.org/patch/1589161/ What I'm wanting to discuss (and perhaps implement, with you if possible) is splitting this patch into writing to existing pre-allocated files, and creating a new pre-allocation. If Windows does, as you claim, simply read preallocations as zero, and writes to them normally and without error, then Linux should do the same. Here of course I'm assuming that Windows is not preallocating, but instead simply trying to recover gracefully and safely from a simple 'file system corruption', where the sectors are allocated but not used. The bulk of this patch is implementing this transparent recovery, and it seem relatively harmless to include this into the kernel. Then vendors doing TV streaming, or in my case copies of large files onto Samba-mounted USB FAT devices, can add only the smaller patch to implement fallocate, at their own risk and fully knowing that it will be regarded as corrupt on Linux. If accepted read support will, over a period of years, trickle down to other Linux users, broadening the base that can still read these 'corrupt' drives, no matter the cause. I hope you agree that this is a practical way forward, and I look forward to working with you on this. Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Read support for fat_fallocate()? (was [v2] fat: editions to support fat_fallocate())
G'day, I've been looking into the patch [v2] fat: editions to support fat_fallocate() and I wonder if there is a way we can split this issue in two, so that we get at least some of the patch into the kernel. https://lkml.org/lkml/2012/10/13/75 https://patchwork.kernel.org/patch/1589161/ What I'm wanting to discuss (and perhaps implement, with you if possible) is splitting this patch into writing to existing pre-allocated files, and creating a new pre-allocation. If Windows does, as you claim, simply read preallocations as zero, and writes to them normally and without error, then Linux should do the same. Here of course I'm assuming that Windows is not preallocating, but instead simply trying to recover gracefully and safely from a simple 'file system corruption', where the sectors are allocated but not used. The bulk of this patch is implementing this transparent recovery, and it seem relatively harmless to include this into the kernel. Then vendors doing TV streaming, or in my case copies of large files onto Samba-mounted USB FAT devices, can add only the smaller patch to implement fallocate, at their own risk and fully knowing that it will be regarded as corrupt on Linux. If accepted read support will, over a period of years, trickle down to other Linux users, broadening the base that can still read these 'corrupt' drives, no matter the cause. I hope you agree that this is a practical way forward, and I look forward to working with you on this. Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Read support for fat_fallocate()? (was [v2] fat: editions to support fat_fallocate())
(apologies for the duplicate mail, I typo-ed the maintainers address) G'day, I've been looking into the patch [v2] fat: editions to support fat_fallocate() and I wonder if there is a way we can split this issue in two, so that we get at least some of the patch into the kernel. https://lkml.org/lkml/2012/10/13/75 https://patchwork.kernel.org/patch/1589161/ What I'm wanting to discuss (and perhaps implement, with you if possible) is splitting this patch into writing to existing pre-allocated files, and creating a new pre-allocation. If Windows does, as you claim, simply read preallocations as zero, and writes to them normally and without error, then Linux should do the same. Here of course I'm assuming that Windows is not preallocating, but instead simply trying to recover gracefully and safely from a simple 'file system corruption', where the sectors are allocated but not used. The bulk of this patch is implementing this transparent recovery, and it seem relatively harmless to include this into the kernel. Then vendors doing TV streaming, or in my case copies of large files onto Samba-mounted USB FAT devices, can add only the smaller patch to implement fallocate, at their own risk and fully knowing that it will be regarded as corrupt on Linux. If accepted read support will, over a period of years, trickle down to other Linux users, broadening the base that can still read these 'corrupt' drives, no matter the cause. I hope you agree that this is a practical way forward, and I look forward to working with you on this. Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Read support for fat_fallocate()? (was [v2] fat: editions to support fat_fallocate())
On Thu, 2013-02-14 at 15:44 +0900, Namjae Jeon wrote: 2013/2/14, Andrew Bartlett abart...@samba.org: (apologies for the duplicate mail, I typo-ed the maintainers address) G'day, I've been looking into the patch [v2] fat: editions to support fat_fallocate() and I wonder if there is a way we can split this issue in two, so that we get at least some of the patch into the kernel. https://lkml.org/lkml/2012/10/13/75 https://patchwork.kernel.org/patch/1589161/ What I'm wanting to discuss (and perhaps implement, with you if possible) is splitting this patch into writing to existing pre-allocated files, and creating a new pre-allocation. If Windows does, as you claim, simply read preallocations as zero, and writes to them normally and without error, then Linux should do the same. Here of course I'm assuming that Windows is not preallocating, but instead simply trying to recover gracefully and safely from a simple 'file system corruption', where the sectors are allocated but not used. The bulk of this patch is implementing this transparent recovery, and it seem relatively harmless to include this into the kernel. Then vendors doing TV streaming, or in my case copies of large files onto Samba-mounted USB FAT devices, can add only the smaller patch to implement fallocate, at their own risk and fully knowing that it will be regarded as corrupt on Linux. If accepted read support will, over a period of years, trickle down to other Linux users, broadening the base that can still read these 'corrupt' drives, no matter the cause. I hope you agree that this is a practical way forward, and I look forward to working with you on this. Thanks, Hi Andrew. First, Thanks for your interest ! A mismatch between inode size and reserved blocks can be either due to pre-allocation (after our changes) or due to corruption (sudden unplug of media etc). We don’t think it is right to include only read only support (i.e. without fallocate support) for such files because if such files are encountered it only means that the file is corrupted, as there is no current method to check if the issue is due to pre-allocation. If it is to be included in the kernel, then the whole patch has to go in. I don't see why that is the case. But then again, since the FAT specifications do not accommodate for pre-allocation, then it is up to OGAWA to decide if this is acceptable. In any case, the patch will definitely break backward compatibility (on an older fat driver without fallocate support) and also in case for the two variants for the same kernel versions and only one has FALLOCATE enabled, in such cases also, the behavior will assume corruption in one case. I agree that the sudden unplug is a concern, but why not make the filesystem more robust against that inevitable occurrence? If the blocks appear to be allocated to the file, why not use them? That is, while it is hard to predict the many different ways a filesystem can be corrupted, what would go wrong if we did use these clusters? Do you fear that they might also be allocated to someone else? That would, if I understand correctly just mean that that more broken, not quite valid USB thumb drives and other FAT filesystems work equally well on Windows and Linux, without administrative privileges. (Given that running fsck requires root, and isn't trivially available to normal users in Linux, and I presume is similarly privileged in windows). What I'm doing is suggesting re-purposing your patch, from preallocation to robustness. In this light, do you think this worth pushing forward? We can later address if there is any safe way to preallocate files on FAT as a different question, hoping that this means it will 'just work' on a broader range of other Linux hosts, just as it is claimed to 'just work' on Windows. Thanks, Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [123/2many] MAINTAINERS - COMMON INTERNET FILE SYSTEM (CIFS)
On Sun, 2007-08-12 at 23:25 -0700, [EMAIL PROTECTED] wrote: > Add file pattern to MAINTAINER entry > > Signed-off-by: Joe Perches <[EMAIL PROTECTED]> > > diff --git a/MAINTAINERS b/MAINTAINERS > index 1c014f1..5144e4e 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -1201,6 +1201,7 @@ L: [EMAIL PROTECTED] > W: http://us1.samba.org/samba/Linux_CIFS_client.html > T: git kernel.org:/pub/scm/linux/kernel/git/sfrench/cifs-2.6.git > S: Supported > +F: fs/cifs/ No comment on the F:, but the L: entry here is interesting. Is samba-technical really the right list for cifs-vfs patches? Aside from being CC'ed on such patches, I've never seen discussion of them on the Samba mailing lists. Steve: Shouldn't that be linux-cifs-client? Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com signature.asc Description: This is a digitally signed message part
Re: [PATCH] [123/2many] MAINTAINERS - COMMON INTERNET FILE SYSTEM (CIFS)
On Sun, 2007-08-12 at 23:25 -0700, [EMAIL PROTECTED] wrote: Add file pattern to MAINTAINER entry Signed-off-by: Joe Perches [EMAIL PROTECTED] diff --git a/MAINTAINERS b/MAINTAINERS index 1c014f1..5144e4e 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1201,6 +1201,7 @@ L: [EMAIL PROTECTED] W: http://us1.samba.org/samba/Linux_CIFS_client.html T: git kernel.org:/pub/scm/linux/kernel/git/sfrench/cifs-2.6.git S: Supported +F: fs/cifs/ No comment on the F:, but the L: entry here is interesting. Is samba-technical really the right list for cifs-vfs patches? Aside from being CC'ed on such patches, I've never seen discussion of them on the Samba mailing lists. Steve: Shouldn't that be linux-cifs-client? Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. http://redhat.com signature.asc Description: This is a digitally signed message part
