[
https://issues.apache.org/jira/browse/SVN-4819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16886970#comment-16886970
]
Johan Corveleyn commented on SVN-4819:
--------------------------------------
Daniel, did you see the red warning when creating your issue "Please ensure you
have discussed on the mailing list first BEFORE creating this ticket."? Now, I
can see that this is probably a genuine issue, but still I would suggest that
you bring this problem to our mailng list
(http://subversion.apache.org/mailing-lists.html#users-ml), to draw some more
attention to it.
Thanks.
> svnadmin fails to create empty repository on CSV storage (Windows Cluster
> Shared Volume)
> ----------------------------------------------------------------------------------------
>
> Key: SVN-4819
> URL: https://issues.apache.org/jira/browse/SVN-4819
> Project: Subversion
> Issue Type: Bug
> Components: svnadmin
> Affects Versions: 1.12.x
> Environment: Windows Server 2019 Standard
> Windows Failover Cluster
> Cluster Shared Volume on top of NTFS
> Reporter: Daniel Watzinger
> Priority: Blocker
> Attachments: 0, Procmon.csv
>
>
> svnadmin reproducibly fails to initialize an empty repository on a cluster
> shared volume in a Windows Failover Cluster environment on Windows Server
> 2019. The initial call seems to be successful.
> {code:java}
> svnadmin create foobar{code}
> A subsequent
> {code:java}
> svnadmin verify foobar{code}
> fails with
> {code:java}
> * Verifying metadata at revision 0 ...
> * Error verifying repository metadata.
> svnadmin: E160004: P2L offset 6b must be larger than L2P offset 6b in r0
> footer
> {code}
> Further investigation revealed that the L2P index never gets written to the
> revision file. I have attached the relevant file of revision 0.
> Index data seems to be appended to the revision file in
> *subversion/libsvn_fs_fs/transaction.c* by a call to
> _svn_fs_fs__add_index_data:_
> {code:java}
> ...
> /* Append the actual index data to the pack file. */
> l2p_offset = 0;
> SVN_ERR(svn_io_file_seek(file, APR_END, &l2p_offset, pool));
> SVN_ERR(svn_fs_fs__l2p_index_append(&l2p_checksum, fs, file, l2p_proto_index,
> revision, pool, pool));
>
> p2l_offset = 0;
> SVN_ERR(svn_io_file_seek(file, APR_END, &p2l_offset, pool));
> SVN_ERR(svn_fs_fs__p2l_index_append(&p2l_checksum, fs, file, p2l_proto_index,
> revision, pool, pool));
> ...{code}
> _svn_io_file_seek_ queries file metadata to acquire the required offset to
> write the next chunk of data. However, both calls yield an identical offset
> equal to the initial length of the revision file. Thus, the L2P index is
> overwritten by writing the P2L index data. I was able to confirm this by
> monitoring _svnadmin_ using Procmon (see attached Procmon.csv) on both local
> and cluster shared volumes. I strongly suspect that file metadata is not
> flushed to the disk fast enough before the second call to _svn_io_file_seek._
> As far as i recall (in the case of Windows), filesystem metadata is always
> cached. To ensure storage of metadata to disk, the file must either be
> flushed or be opened with *FILE_FLAG_WRITE_THROUGH*.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)