lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera (JIRA)" <>
Subject [jira] [Commented] (LUCENE-3230) Make FSDirectory.fsync() public and static
Date Fri, 24 Jun 2011 04:38:47 GMT


Shai Erera commented on LUCENE-3230:

I opened 2 RAF instances over the same file and called getFD() on each. I've received 2 instances
of FD, each had a different 'handle' value. So I agree it's not clear whether syncing one
FD affects the other.

I also found some posts on the web claiming that FS.sync() doesn't really work on all OS,
and that some hardware manufacturers enable "hardware write caching", so even if the OS obeys
the sync() call, the HW may not. I guess there's not much we can do about the HW case.
* (bad fsync on Mac OS X)

So perhaps we shouldn't make it a public API after all. If someone can sync() on the same
OutputStream he used to flush/close, it's better than how we do it today. I hate to introduce
public API w/ big warnings.

As for our case (Lucene usage of sync()), it'd be good if we can sync() in the IndexOutput
that wrote the data. So maybe we should add sync() to IO? Not sure how it will play out in
Directory, which today syncs file names, and not IndexOutput instances.

Shall I close this issue then? Or rename it to handle the IO.sync() issue?

> Make FSDirectory.fsync() public and static
> ------------------------------------------
>                 Key: LUCENE-3230
>                 URL:
>             Project: Lucene - Java
>          Issue Type: New Feature
>          Components: core/store
>            Reporter: Shai Erera
>            Assignee: Shai Erera
>            Priority: Minor
>             Fix For: 3.3, 4.0
> I find FSDirectory.fsync() (today protected and instance method) very useful as a utility
to sync() files. I'd like create a FSDirectory.sync() utility which contains the exact same
impl of FSDir.fsync(), and have the latter call it. We can have it part of IOUtils too, as
it's a completely standalone utility.
> I would get rid of FSDir.fsync() if it wasn't protected (as if encouraging people to
override it). I doubt anyone really overrides it (our core Directories don't).
> Also, while reviewing the code, I noticed that if IOE occurs, the code sleeps for 5 msec.
If an InterruptedException occurs then, it immediately throws ThreadIE, completely ignoring
the fact that it slept due to IOE. Shouldn't we at least pass IOE.getMessage() on ThreadIE?
> The patch is trivial, so I'd like to get some feedback before I post it.

This message is automatically generated by JIRA.
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message