On Mon, Dec 1, 2014 at 11:46 AM, Chris Hostetter
<[email protected]> wrote:
>
> : windowsfs uses map<inode,integer> to determine if it can delete a
> : file, but this is troublesome on windows. One problem is that we cant
> : 100% compare files for equality without doing i/o. And doing this
> : itself can piss "the real windows" off. So I just disable windowsfs on
> : actual windows for now, i don't really have a way to test it and i
> : dont think it buys us anything right now to add lots of special code.
>
> I've got a massive backlog of lucene/solr related email, and haven't
> really been able to follow all the commits, so forgive me if this is a
> stupid question but...
>
> as i understand it, the test framework has a bunch of new stuff now for
> mocking the filesystem (cool!) and this is the context for the "windowsfs"
> refrence here (correct?) ... so my question is this:
>
> when saying "disable windowsfs on actual windows" does that mean:
>
> 1: (mock) windowsfs is removed from the pool of random mockfs's that are
> candidates for testing when we detect the OS is "windows"
> ...or does that mean that...
Its easiest to explain i think by pasting the code. for 10% of runs we
don't wrap the filesystem at all. This is to ensure our "mock
filesystems" dont hide real bugs.
Otherwise, we add some minimal checks: we disable actual fsync calls
(its unnecessary), fail on leaked file handles, limit the number of
open files to 2048 (currently).
Then we occasionally act like windows, if we are on a non-windows machine.
// sometimes just use a bare filesystem
if (random.nextInt(10) > 0) {
fs = new DisableFsyncFS(fs).getFileSystem(null);
fs = new LeakFS(fs).getFileSystem(null);
fs = new HandleLimitFS(fs, MAX_OPEN_FILES).getFileSystem(null);
// windows is currently slow
if (random.nextInt(10) == 0) {
// don't try to emulate windows on windows: they don't get along
if (!Constants.WINDOWS) {
fs = new WindowsFS(fs).getFileSystem(null);
}
}
}
>
> The reason i ask: both approaches seem ot have serious downsides, and i'm
> trying to understand which devil we're choosing?
>
> the downside for #2 is that a test on linux which cliams it's using
> "(mock) windowsfs" might pass/fail diff then the same test with the same
> seed on an actual windows machine where the fs is really diff --- but that
> seems no worse then what we've had in the past before we made any attempt
> to mock out hte filesystem.
This is not something I am currently trying to address with tests. In
general, tests might fail on windows and pass on linux and so on. In
order to prevent that, we would have to do a whole lot more, including
"mocking linux" on windows. But thats just a non-goal here. These
mockfilesystems do not make it any better or any worse.
>
> the downside of #1 however seems to have a lot more serious impact on
> people who are actualy running windows, and really want to test "how does
> lucene/solr perform on windows" ... becuase they will *never* see their
> tests run on a windows filesystem (either mock or real)
>
If you are running on windows, then your actual filesystem is already
acting like windows. We don't need to add any code to accomplish
"windows behavior" :)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
