> What do you recommend?
In general. There may be people/organizations, which will not compromise
on the reduced functionality in favor of the stability, this is understandable.
I would propose to create a separate (unofficial experimental) branch, which
would track changes like HADOOP-4379. The branch may later either die when the
main stream is fixed or be merged with the trunk if the changes proved to be
stable.
>1. the file length (as returned by getFileStatus) is incorrect
May be the following work around will be useful.
If you read from a file you always try to read more data than the length
reported
by the name-node. How much more? The size of one block would be enough, or
even to the next (ceiling) block boundary.
>2. When an application comes up after a crash, it seems to hang for about 60
Don't have enough context on that, sorry.
Thanks,
--Konstantin
Doug Judd wrote:
Sounds good. I would much rather wait and have fsync() done correctly in
0.20 than get some sort of hacked version in 0.19. I'll create a couple of
issues and mark them for 0.20 Thanks.
- Doug
On Mon, Feb 2, 2009 at 1:51 PM, Owen O'Malley <omal...@apache.org> wrote:
On Feb 2, 2009, at 12:51 PM, Doug Judd wrote:
What do you recommend? Is there anyway we could get these two issues
fixed
for 0.19.1, or should I file issues for them and get them on the schedule
for 0.19.2?
Given the outstanding problems and general level of uncertainty, I'd favor
releasing a 0.19.1 with the equivalent of the 0.18.3 disable on fsync and
append. Let's get them fixed in 0.20 first and then we can debate whether
the rewards of pushing them back into an 0.19.2 would make sense. I'm pretty
uncomfortable at the moment with how the entire functional complex seems to
cause a continuous stream of problems.
-- Owen
