Обсуждение: BUG #16854: initdb fails on ReFS and FAT32 file systems
The following bug has been logged on the website: Bug reference: 16854 Logged by: Katsuaki Fukushima Email address: katsuaki.fukushima@gmail.com PostgreSQL version: 13.1 Operating system: Windows 10 Enterprise and Windows Server 2019 Description: In Microsoft Windows, initdb fails for ReFS and FAT32 file systems. PostgreSQL 12.x worked fine. The WAL allocated in the temporary is renamed to the canonical name with the durable_rename_excl function in src/backend/storage/file/fd.c. This function hardlinks to the canonical name and unlinks the temporary. Since ReFS does not support hard linking, the CreateHardLinkA function in src/port/link.c will fail and the OS will return error code 50. I replaced CreateHardLinka(dst, src, NULL) with MoveFileA(src, dst), and it works for now. I haven't investigated the effect on others.
On 2021/02/05 13:55, PG Bug reporting form wrote:
> The following bug has been logged on the website:
>
> Bug reference: 16854
> Logged by: Katsuaki Fukushima
> Email address: katsuaki.fukushima@gmail.com
> PostgreSQL version: 13.1
> Operating system: Windows 10 Enterprise and Windows Server 2019
> Description:
>
> In Microsoft Windows, initdb fails for ReFS and FAT32 file systems.
> PostgreSQL 12.x worked fine.
> The WAL allocated in the temporary is renamed to the canonical name with the
> durable_rename_excl function in src/backend/storage/file/fd.c.
> This function hardlinks to the canonical name and unlinks the temporary.
> Since ReFS does not support hard linking, the CreateHardLinkA function in
> src/port/link.c will fail and the OS will return error code 50.
> I replaced CreateHardLinka(dst, src, NULL) with MoveFileA(src, dst), and it
> works for now.
> I haven't investigated the effect on others.
This issue seems to be related to commit aaa3aeddee. That commit log says
Previously, hard links were not used on Windows and Cygwin, but they
support them just fine in currently supported OS versions, so we can
use them there as well.
Since all supported platforms now support hard links, we can remove
the alternative code paths.
I'm not sure if ReFS is the supported platform or not. But if it is,
the assumption that the above commit log says is not correct. If so,
ISTM that we need to rethink the changes that commit introduced.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
Fujii Masao <masao.fujii@oss.nttdata.com> writes: > On 2021/02/05 13:55, PG Bug reporting form wrote: >> In Microsoft Windows, initdb fails for ReFS and FAT32 file systems. >> PostgreSQL 12.x worked fine. > I'm not sure if ReFS is the supported platform or not. I certainly don't have a problem with kicking FAT32 to the curb. But according to https://en.wikipedia.org/wiki/ReFS ReFS is Microsoft's latest and greatest attempt at implementing a modern file system. I'd quantify the greatness pretty poorly if they left out hard links (I wonder what other essentials they didn't bother with) but maybe we have to support it. On the third hand, Wikipedia says a bit further down The ability to create ReFS volumes was removed in Windows 10's 2017 Fall Creators Update for all editions except Enterprise and Pro for Workstations.[4] which sounds a whole lot like "we've already given up on this". If they're not pushing ReFS anymore then I think we can ignore it. regards, tom lane
On Fri, Feb 5, 2021, at 12:26 PM, Tom Lane wrote:
ReFS is Microsoft's latest and greatest attempt at implementing a modernfile system. I'd quantify the greatness pretty poorly if they left outhard links (I wonder what other essentials they didn't bother with)but maybe we have to support it.
It claims that the latest ReFS version (3.5) supports hard links [1].
On the third hand, Wikipedia says a bit further downThe ability to create ReFS volumes was removed in Windows 10's 2017Fall Creators Update for all editions except Enterprise and Pro forWorkstations.[4]which sounds a whole lot like "we've already given up on this".If they're not pushing ReFS anymore then I think we can ignore it.
It is not clear why they removed the ability to create ReFS filesystems in some
Windows 10 versions. Strategic decision? Even we fixed support for ReFS, they
would be a mess to explain that a previous created ReFS filesystem doesn't
support hard links and the OP should create a new one (unless MS provides a way
to figure out that filesystem doesn't support hard links because it was created
in a previous version).
"Euler Taveira" <euler@eulerto.com> writes:
> On Fri, Feb 5, 2021, at 12:26 PM, Tom Lane wrote:
>> ReFS is Microsoft's latest and greatest attempt at implementing a modern
>> file system. I'd quantify the greatness pretty poorly if they left out
>> hard links (I wonder what other essentials they didn't bother with)
>> but maybe we have to support it.
> It claims that the latest ReFS version (3.5) supports hard links [1].
Hmm, what [1] actually says about that is
Version ReFS 3.5 formatted by Windows 10 Enterprise Insider Preview
build 19536. Added hardlink support if fresh formatted volume. Can't
use hardlink if upgraded from previous version
so it's not exactly mainstream yet.
But given that, I'm content to say "you can use ReFS if you have
a version that supports hard links". We don't need to support
work-in-progress filesystems.
regards, tom lane
On Fri, Feb 05, 2021 at 12:01:51PM -0500, Tom Lane wrote: > But given that, I'm content to say "you can use ReFS if you have > a version that supports hard links". We don't need to support > work-in-progress filesystems. Yeah, agreed. I think that it could be interesting to get a buildfarm animal in place that supports such a configuration if users care about that? If not, we are going to have a hard time tracking down issues in the WIN32 port. -- Michael
Вложения
On Fri, Feb 05, 2021 at 11:26:51PM +0900, Fujii Masao wrote: > I'm not sure if ReFS is the supported platform or not. But if it is, > the assumption that the above commit log says is not correct. If so, > ISTM that we need to rethink the changes that commit introduced. A side effect of 909b449, basically a revert of aaa3aed, means that this issue gets fixed. If you are interested in supporting this configuration, I highly recommend that you create a buildfarm animal so as we can know in live what gets broken once a patch is committed rather than 1 year later. Please see here: https://buildfarm.postgresql.org/cgi-bin/show_status.pl -- Michael