[
https://issues.apache.org/jira/browse/SVN-4819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Shahaf (äñ§€¥£¢) updated SVN-4819:
-----------------------------------------
Description:
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*.
was:
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*.
> 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)
