[
https://issues.apache.org/jira/browse/HDFS-11402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Manoj Govindassamy updated HDFS-11402:
--------------------------------------
Attachment: HDFS-11402.03.patch
Thanks for the review [~yzhangal]. Attached v03 patch with below review
comments addresses. Have added a new unit test for Snapshot Diff Report to
verify snapshot diffs for the snapshots which have open files captured. Kindly
take a look at the new patch revision.
bq. 1. We can put the parameters leaseManager and freezeOpenFiles together at
the API, since they are used together for an optional feature.
Done.
bq. 2. share common code in the two INodesInPath$fromINode methods
Done.
bq. 3. change method name isAncestor to isDescendent in INodesInPath
Done.
bq. 4. INODE_FILTER_WORKER_COUNT is only used in a single method, it's better
not to define it as public, and maybe we can just move it to the single method.
This count is used by unit tests as well. Have changed the scope of the
variable to package private instead of public.
bq. change getINodeWithLeases(final INodeDirectory restrictFilesFromDir)
to getINodesWithLease(final INodeDirectory ancestorDir)
and javadoc the behavior when ancestorDir is null or not-null
Done.
bq. optionally, possibly just use the above COUNT as a cap, and have a way to
dynamically decide how big the thread pool is, especially when the number of
files open for write is small. This can be consider in the future when needed.
Will take this for future.
bq. add a private method (like getINodesInLease to wrap
Done.
bq. 5. In hdfs-default.xml, add a note to describe that the file length
captured in snapshot for a file is what's recorded in NameNode, it may be
shorter than what the client has written. In order to capture the length the
client has written, the client need to call hflush/hsync on the file.
Done.
6. Suggest to add a test about snapshot diff.
Added a new unit test for Snapshot Diff Report
> HDFS Snapshots should capture point-in-time copies of OPEN files
> ----------------------------------------------------------------
>
> Key: HDFS-11402
> URL: https://issues.apache.org/jira/browse/HDFS-11402
> Project: Hadoop HDFS
> Issue Type: Improvement
> Components: hdfs
> Affects Versions: 2.6.0
> Reporter: Manoj Govindassamy
> Assignee: Manoj Govindassamy
> Attachments: HDFS-11402.01.patch, HDFS-11402.02.patch,
> HDFS-11402.03.patch
>
>
> *Problem:*
> 1. When there are files being written and when HDFS Snapshots are taken in
> parallel, Snapshots do capture all these files, but these being written files
> in Snapshots do not have the point-in-time file length captured. That is,
> these open files are not frozen in HDFS Snapshots. These open files
> grow/shrink in length, just like the original file, even after the snapshot
> time.
> 2. At the time of File close or any other meta data modification operation on
> these files, HDFS reconciles the file length and records the modification in
> the last taken Snapshot. All the previously taken Snapshots continue to have
> those open Files with no modification recorded. So, all those previous
> snapshots end up using the final modification record in the last snapshot.
> Thus after the file close, file lengths in all those snapshots will end up
> same.
> Assume File1 is opened for write and a total of 1MB written to it. While the
> writes are happening, snapshots are taken in parallel.
> {noformat}
> |---Time---T1-----------T2-------------T3----------------T4------>
> |-----------------------Snap1----------Snap2-------------Snap3--->
> |---File1.open---write---------write-----------close------------->
> {noformat}
> Then at time,
> T2:
> Snap1.File1.length = 0
> T3:
> Snap1.File1.length = 0
> Snap2.File1.length = 0
> <File1 write completed and closed>
> T4:
> Snap1.File1.length = 1MB
> Snap2.File1.length = 1MB
> Snap3.File1.length = 1MB
> *Proposal*
> 1. At the time of taking Snapshot, {{SnapshotManager#createSnapshot}} can
> optionally request {{DirectorySnapshottableFeature#addSnapshot}} to freeze
> open files.
> 2. {{DirectorySnapshottableFeature#addSnapshot}} can consult with
> {{LeaseManager}} and get a list INodesInPath for all open files under the
> snapshot dir.
> 3. {{DirectorySnapshottableFeature#addSnapshot}} after the Snapshot creation,
> Diff creation and updating modification time, can invoke
> {{INodeFile#recordModification}} for each of the open files. This way, the
> Snapshot just taken will have a {{FileDiff}} with {{fileSize}} captured for
> each of the open files.
> 4. Above model follows the current Snapshot and Diff protocols and doesn't
> introduce any any disk formats. So, I don't think we will be needing any new
> FSImage Loader/Saver changes for Snapshots.
> 5. One of the design goals of HDFS Snapshot was ability to take any number of
> snapshots in O(1) time. LeaseManager though has all the open files with
> leases in-memory map, an iteration is still needed to prune the needed open
> files and then run recordModification on each of them. So, it will not be a
> strict O(1) with the above proposal. But, its going be a marginal increase
> only as the new order will be of O(open_files_under_snap_dir). In order to
> avoid HDFS Snapshots change in behavior for open files and avoid change in
> time complexity, this improvement can be made under a new config
> {{"dfs.namenode.snapshot.freeze.openfiles"}} which by default can be
> {{false}}.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
