You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Zhu Han (JIRA)" <ji...@apache.org> on 2011/09/23 16:40:26 UTC
[jira] [Created] (CASSANDRA-3250) fsync the directory after new
sstable or commit log segment are created
fsync the directory after new sstable or commit log segment are created
-----------------------------------------------------------------------
Key: CASSANDRA-3250
URL: https://issues.apache.org/jira/browse/CASSANDRA-3250
Project: Cassandra
Issue Type: Bug
Reporter: Zhu Han
The mannual of fsync said:
bq. Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk. For that an explicit fsync() on a file descriptor for the directory is also needed.
At least on ext4, syncing the directory is a must to have step, as described by [1]. Otherwise, the new sstables or commit logs could be missed after crash even if itself is synced.
Unfortunately, JVM does not provide an approach to sync the directory...
[1] http://www.linuxfoundation.org/news-media/blogs/browse/2009/03/don%E2%80%99t-fear-fsync
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3250) fsync the directory after new
sstable or commit log segment are created
Posted by "Jonathan Ellis (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13171784#comment-13171784 ]
Jonathan Ellis commented on CASSANDRA-3250:
-------------------------------------------
v2 looks a lot simpler, I like it.
Is there a reason to limit this to Linux-only? If open + fsync + close exist, it should work. (And if they don't, we already have the link error to tell us that.)
> fsync the directory after new sstable or commit log segment are created
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-3250
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3250
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Zhu Han
> Assignee: Pavel Yaskevich
> Priority: Minor
> Fix For: 1.0.7
>
> Attachments: CASSANDRA-3250-v2.patch, CASSANDRA-3250.patch
>
>
> The mannual of fsync said:
> bq. Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk. For that an explicit fsync() on a file descriptor for the directory is also needed.
> At least on ext4, syncing the directory is a must to have step, as described by [1]. Otherwise, the new sstables or commit logs could be missed after crash even if itself is synced.
> Unfortunately, JVM does not provide an approach to sync the directory...
> [1] http://www.linuxfoundation.org/news-media/blogs/browse/2009/03/don%E2%80%99t-fear-fsync
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3250) fsync the directory after new
sstable or commit log segment are created
Posted by "Pavel Yaskevich (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pavel Yaskevich updated CASSANDRA-3250:
---------------------------------------
Attachment: CASSANDRA-3250.patch
> fsync the directory after new sstable or commit log segment are created
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-3250
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3250
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Zhu Han
> Assignee: Pavel Yaskevich
> Priority: Minor
> Fix For: 1.0.6
>
> Attachments: CASSANDRA-3250.patch
>
>
> The mannual of fsync said:
> bq. Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk. For that an explicit fsync() on a file descriptor for the directory is also needed.
> At least on ext4, syncing the directory is a must to have step, as described by [1]. Otherwise, the new sstables or commit logs could be missed after crash even if itself is synced.
> Unfortunately, JVM does not provide an approach to sync the directory...
> [1] http://www.linuxfoundation.org/news-media/blogs/browse/2009/03/don%E2%80%99t-fear-fsync
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3250) fsync the directory after new
sstable or commit log segment are created
Posted by "Pavel Yaskevich (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pavel Yaskevich updated CASSANDRA-3250:
---------------------------------------
Attachment: CASSANDRA-3250-v3.patch
Ok, v3 O_DIRECTORY changed to O_RDONLY and checks for linux are removed from CLibrary.
O_DIRECTORY just causes open to fail if given path is not a directory, so it seems we can live without it :)
> fsync the directory after new sstable or commit log segment are created
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-3250
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3250
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Zhu Han
> Assignee: Pavel Yaskevich
> Priority: Minor
> Fix For: 1.0.7
>
> Attachments: CASSANDRA-3250-v2.patch, CASSANDRA-3250-v3.patch, CASSANDRA-3250.patch
>
>
> The mannual of fsync said:
> bq. Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk. For that an explicit fsync() on a file descriptor for the directory is also needed.
> At least on ext4, syncing the directory is a must to have step, as described by [1]. Otherwise, the new sstables or commit logs could be missed after crash even if itself is synced.
> Unfortunately, JVM does not provide an approach to sync the directory...
> [1] http://www.linuxfoundation.org/news-media/blogs/browse/2009/03/don%E2%80%99t-fear-fsync
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3250) fsync the directory after new
sstable or commit log segment are created
Posted by "Jonathan Ellis (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13171888#comment-13171888 ]
Jonathan Ellis commented on CASSANDRA-3250:
-------------------------------------------
Is O_DIRECTORY necessary for the sync to work? Or is that just a "make sure this path is actually a directory" flag? If the latter, then we can leave it out, since we know the path is a directory by construction.
> fsync the directory after new sstable or commit log segment are created
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-3250
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3250
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Zhu Han
> Assignee: Pavel Yaskevich
> Priority: Minor
> Fix For: 1.0.7
>
> Attachments: CASSANDRA-3250-v2.patch, CASSANDRA-3250.patch
>
>
> The mannual of fsync said:
> bq. Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk. For that an explicit fsync() on a file descriptor for the directory is also needed.
> At least on ext4, syncing the directory is a must to have step, as described by [1]. Otherwise, the new sstables or commit logs could be missed after crash even if itself is synced.
> Unfortunately, JVM does not provide an approach to sync the directory...
> [1] http://www.linuxfoundation.org/news-media/blogs/browse/2009/03/don%E2%80%99t-fear-fsync
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3250) fsync the directory after new
sstable or commit log segment are created
Posted by "Pavel Yaskevich (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pavel Yaskevich updated CASSANDRA-3250:
---------------------------------------
Attachment: CASSANDRA-3250-v2.patch
re-attached v2 which does only one directory sync per file (after first file sync).
> fsync the directory after new sstable or commit log segment are created
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-3250
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3250
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Zhu Han
> Assignee: Pavel Yaskevich
> Priority: Minor
> Fix For: 1.0.7
>
> Attachments: CASSANDRA-3250-v2.patch, CASSANDRA-3250.patch
>
>
> The mannual of fsync said:
> bq. Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk. For that an explicit fsync() on a file descriptor for the directory is also needed.
> At least on ext4, syncing the directory is a must to have step, as described by [1]. Otherwise, the new sstables or commit logs could be missed after crash even if itself is synced.
> Unfortunately, JVM does not provide an approach to sync the directory...
> [1] http://www.linuxfoundation.org/news-media/blogs/browse/2009/03/don%E2%80%99t-fear-fsync
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3250) fsync the directory after new
sstable or commit log segment are created
Posted by "Jonathan Ellis (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-3250:
--------------------------------------
Reviewer: jbellis
Component/s: Core
Priority: Minor (was: Major)
Fix Version/s: 1.0.1
Assignee: Pavel Yaskevich
> fsync the directory after new sstable or commit log segment are created
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-3250
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3250
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Zhu Han
> Assignee: Pavel Yaskevich
> Priority: Minor
> Fix For: 1.0.1
>
>
> The mannual of fsync said:
> bq. Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk. For that an explicit fsync() on a file descriptor for the directory is also needed.
> At least on ext4, syncing the directory is a must to have step, as described by [1]. Otherwise, the new sstables or commit logs could be missed after crash even if itself is synced.
> Unfortunately, JVM does not provide an approach to sync the directory...
> [1] http://www.linuxfoundation.org/news-media/blogs/browse/2009/03/don%E2%80%99t-fear-fsync
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3250) fsync the directory after new
sstable or commit log segment are created
Posted by "Pavel Yaskevich (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13171857#comment-13171857 ]
Pavel Yaskevich commented on CASSANDRA-3250:
--------------------------------------------
The reason is O_DIRECTORY is a Linux-specific flag.
> fsync the directory after new sstable or commit log segment are created
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-3250
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3250
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Zhu Han
> Assignee: Pavel Yaskevich
> Priority: Minor
> Fix For: 1.0.7
>
> Attachments: CASSANDRA-3250-v2.patch, CASSANDRA-3250.patch
>
>
> The mannual of fsync said:
> bq. Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk. For that an explicit fsync() on a file descriptor for the directory is also needed.
> At least on ext4, syncing the directory is a must to have step, as described by [1]. Otherwise, the new sstables or commit logs could be missed after crash even if itself is synced.
> Unfortunately, JVM does not provide an approach to sync the directory...
> [1] http://www.linuxfoundation.org/news-media/blogs/browse/2009/03/don%E2%80%99t-fear-fsync
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3250) fsync the directory after new
sstable or commit log segment are created
Posted by "Zhu Han (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13114471#comment-13114471 ]
Zhu Han commented on CASSANDRA-3250:
------------------------------------
On XFS, this is not a problem per the developer's response[1].
[1] http://www.spinics.net/lists/xfs/msg07229.html
> fsync the directory after new sstable or commit log segment are created
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-3250
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3250
> Project: Cassandra
> Issue Type: Bug
> Reporter: Zhu Han
>
> The mannual of fsync said:
> bq. Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk. For that an explicit fsync() on a file descriptor for the directory is also needed.
> At least on ext4, syncing the directory is a must to have step, as described by [1]. Otherwise, the new sstables or commit logs could be missed after crash even if itself is synced.
> Unfortunately, JVM does not provide an approach to sync the directory...
> [1] http://www.linuxfoundation.org/news-media/blogs/browse/2009/03/don%E2%80%99t-fear-fsync
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (CASSANDRA-3250) fsync the directory after new
sstable or commit log segment are created
Posted by "Jonathan Ellis (Reopened) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis reopened CASSANDRA-3250:
---------------------------------------
... actually, can you back this out of 1.0 and put it in 1.1 instead? It *should* be fine but let's not take chances with regressions.
> fsync the directory after new sstable or commit log segment are created
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-3250
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3250
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Zhu Han
> Assignee: Pavel Yaskevich
> Priority: Minor
> Fix For: 1.0.7
>
> Attachments: CASSANDRA-3250-v2.patch, CASSANDRA-3250-v3.patch, CASSANDRA-3250.patch
>
>
> The mannual of fsync said:
> bq. Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk. For that an explicit fsync() on a file descriptor for the directory is also needed.
> At least on ext4, syncing the directory is a must to have step, as described by [1]. Otherwise, the new sstables or commit logs could be missed after crash even if itself is synced.
> Unfortunately, JVM does not provide an approach to sync the directory...
> [1] http://www.linuxfoundation.org/news-media/blogs/browse/2009/03/don%E2%80%99t-fear-fsync
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3250) fsync the directory after new
sstable or commit log segment are created
Posted by "Pavel Yaskevich (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pavel Yaskevich updated CASSANDRA-3250:
---------------------------------------
Fix Version/s: (was: 1.0.7)
1.1
> fsync the directory after new sstable or commit log segment are created
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-3250
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3250
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Zhu Han
> Assignee: Pavel Yaskevich
> Priority: Minor
> Fix For: 1.1
>
> Attachments: CASSANDRA-3250-v2.patch, CASSANDRA-3250-v3.patch, CASSANDRA-3250.patch
>
>
> The mannual of fsync said:
> bq. Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk. For that an explicit fsync() on a file descriptor for the directory is also needed.
> At least on ext4, syncing the directory is a must to have step, as described by [1]. Otherwise, the new sstables or commit logs could be missed after crash even if itself is synced.
> Unfortunately, JVM does not provide an approach to sync the directory...
> [1] http://www.linuxfoundation.org/news-media/blogs/browse/2009/03/don%E2%80%99t-fear-fsync
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3250) fsync the directory after new
sstable or commit log segment are created
Posted by "Pavel Yaskevich (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pavel Yaskevich updated CASSANDRA-3250:
---------------------------------------
Attachment: (was: CASSANDRA-3250-v2.patch)
> fsync the directory after new sstable or commit log segment are created
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-3250
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3250
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Zhu Han
> Assignee: Pavel Yaskevich
> Priority: Minor
> Fix For: 1.0.7
>
> Attachments: CASSANDRA-3250-v2.patch, CASSANDRA-3250.patch
>
>
> The mannual of fsync said:
> bq. Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk. For that an explicit fsync() on a file descriptor for the directory is also needed.
> At least on ext4, syncing the directory is a must to have step, as described by [1]. Otherwise, the new sstables or commit logs could be missed after crash even if itself is synced.
> Unfortunately, JVM does not provide an approach to sync the directory...
> [1] http://www.linuxfoundation.org/news-media/blogs/browse/2009/03/don%E2%80%99t-fear-fsync
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-3250) fsync the directory after new
sstable or commit log segment are created
Posted by "Pavel Yaskevich (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pavel Yaskevich updated CASSANDRA-3250:
---------------------------------------
Attachment: CASSANDRA-3250-v2.patch
No problem with that, here is the version where SequentialWriter syncs only directory for file it writes.
> fsync the directory after new sstable or commit log segment are created
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-3250
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3250
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Zhu Han
> Assignee: Pavel Yaskevich
> Priority: Minor
> Fix For: 1.0.7
>
> Attachments: CASSANDRA-3250-v2.patch, CASSANDRA-3250.patch
>
>
> The mannual of fsync said:
> bq. Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk. For that an explicit fsync() on a file descriptor for the directory is also needed.
> At least on ext4, syncing the directory is a must to have step, as described by [1]. Otherwise, the new sstables or commit logs could be missed after crash even if itself is synced.
> Unfortunately, JVM does not provide an approach to sync the directory...
> [1] http://www.linuxfoundation.org/news-media/blogs/browse/2009/03/don%E2%80%99t-fear-fsync
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-3250) fsync the directory after new
sstable or commit log segment are created
Posted by "Pavel Yaskevich (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Pavel Yaskevich resolved CASSANDRA-3250.
----------------------------------------
Resolution: Fixed
Changed to 1.1 only.
> fsync the directory after new sstable or commit log segment are created
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-3250
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3250
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Zhu Han
> Assignee: Pavel Yaskevich
> Priority: Minor
> Fix For: 1.1
>
> Attachments: CASSANDRA-3250-v2.patch, CASSANDRA-3250-v3.patch, CASSANDRA-3250.patch
>
>
> The mannual of fsync said:
> bq. Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk. For that an explicit fsync() on a file descriptor for the directory is also needed.
> At least on ext4, syncing the directory is a must to have step, as described by [1]. Otherwise, the new sstables or commit logs could be missed after crash even if itself is synced.
> Unfortunately, JVM does not provide an approach to sync the directory...
> [1] http://www.linuxfoundation.org/news-media/blogs/browse/2009/03/don%E2%80%99t-fear-fsync
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3250) fsync the directory after new
sstable or commit log segment are created
Posted by "Zhu Han (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113488#comment-13113488 ]
Zhu Han commented on CASSANDRA-3250:
------------------------------------
There is a relative discussion on PostgreSQL.
http://postgresql.1045698.n5.nabble.com/fsync-reliability-td4330289.html
> fsync the directory after new sstable or commit log segment are created
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-3250
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3250
> Project: Cassandra
> Issue Type: Bug
> Reporter: Zhu Han
>
> The mannual of fsync said:
> bq. Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk. For that an explicit fsync() on a file descriptor for the directory is also needed.
> At least on ext4, syncing the directory is a must to have step, as described by [1]. Otherwise, the new sstables or commit logs could be missed after crash even if itself is synced.
> Unfortunately, JVM does not provide an approach to sync the directory...
> [1] http://www.linuxfoundation.org/news-media/blogs/browse/2009/03/don%E2%80%99t-fear-fsync
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3250) fsync the directory after new
sstable or commit log segment are created
Posted by "Jonathan Ellis (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13172029#comment-13172029 ]
Jonathan Ellis commented on CASSANDRA-3250:
-------------------------------------------
+1
> fsync the directory after new sstable or commit log segment are created
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-3250
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3250
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Zhu Han
> Assignee: Pavel Yaskevich
> Priority: Minor
> Fix For: 1.0.7
>
> Attachments: CASSANDRA-3250-v2.patch, CASSANDRA-3250-v3.patch, CASSANDRA-3250.patch
>
>
> The mannual of fsync said:
> bq. Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk. For that an explicit fsync() on a file descriptor for the directory is also needed.
> At least on ext4, syncing the directory is a must to have step, as described by [1]. Otherwise, the new sstables or commit logs could be missed after crash even if itself is synced.
> Unfortunately, JVM does not provide an approach to sync the directory...
> [1] http://www.linuxfoundation.org/news-media/blogs/browse/2009/03/don%E2%80%99t-fear-fsync
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3250) fsync the directory after new
sstable or commit log segment are created
Posted by "Pavel Yaskevich (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170553#comment-13170553 ]
Pavel Yaskevich commented on CASSANDRA-3250:
--------------------------------------------
bq. shouldn't the directory cache be per-Writer, not static?
It's useful to make it static instead of instantiation per-Writer because we need every writer to be able to see already open directories.
bq. why would the FD be null? if it shouldn't be, let's use an assert there
Directory FD could be null when it's the first time we see directory e.g. first time for commitlog, different data directories, also I made it that way because of CASSANDRA-2749.
> fsync the directory after new sstable or commit log segment are created
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-3250
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3250
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Zhu Han
> Assignee: Pavel Yaskevich
> Priority: Minor
> Fix For: 1.0.7
>
> Attachments: CASSANDRA-3250.patch
>
>
> The mannual of fsync said:
> bq. Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk. For that an explicit fsync() on a file descriptor for the directory is also needed.
> At least on ext4, syncing the directory is a must to have step, as described by [1]. Otherwise, the new sstables or commit logs could be missed after crash even if itself is synced.
> Unfortunately, JVM does not provide an approach to sync the directory...
> [1] http://www.linuxfoundation.org/news-media/blogs/browse/2009/03/don%E2%80%99t-fear-fsync
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3250) fsync the directory after new
sstable or commit log segment are created
Posted by "Jonathan Ellis (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13171465#comment-13171465 ]
Jonathan Ellis commented on CASSANDRA-3250:
-------------------------------------------
bq. we need every writer to be able to see already open directories
While it doesn't really matter with the current directory-per-keyspace, syncing every directory open globally when any sstable is written could be problematic with CASSANDRA-2749 (especially with leveled compaction, which does lots of small sstable writes). What's the problem with just having writers sync directories for files they're writing?
> fsync the directory after new sstable or commit log segment are created
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-3250
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3250
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Zhu Han
> Assignee: Pavel Yaskevich
> Priority: Minor
> Fix For: 1.0.7
>
> Attachments: CASSANDRA-3250.patch
>
>
> The mannual of fsync said:
> bq. Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk. For that an explicit fsync() on a file descriptor for the directory is also needed.
> At least on ext4, syncing the directory is a must to have step, as described by [1]. Otherwise, the new sstables or commit logs could be missed after crash even if itself is synced.
> Unfortunately, JVM does not provide an approach to sync the directory...
> [1] http://www.linuxfoundation.org/news-media/blogs/browse/2009/03/don%E2%80%99t-fear-fsync
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-3250) fsync the directory after new
sstable or commit log segment are created
Posted by "Jonathan Ellis (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13170543#comment-13170543 ]
Jonathan Ellis commented on CASSANDRA-3250:
-------------------------------------------
- shouldn't the directory cache be per-Writer, not static?
- why would the FD be null? if it shouldn't be, let's use an assert there
> fsync the directory after new sstable or commit log segment are created
> -----------------------------------------------------------------------
>
> Key: CASSANDRA-3250
> URL: https://issues.apache.org/jira/browse/CASSANDRA-3250
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Zhu Han
> Assignee: Pavel Yaskevich
> Priority: Minor
> Fix For: 1.0.7
>
> Attachments: CASSANDRA-3250.patch
>
>
> The mannual of fsync said:
> bq. Calling fsync() does not necessarily ensure that the entry in the directory containing the file has also reached disk. For that an explicit fsync() on a file descriptor for the directory is also needed.
> At least on ext4, syncing the directory is a must to have step, as described by [1]. Otherwise, the new sstables or commit logs could be missed after crash even if itself is synced.
> Unfortunately, JVM does not provide an approach to sync the directory...
> [1] http://www.linuxfoundation.org/news-media/blogs/browse/2009/03/don%E2%80%99t-fear-fsync
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira