Talk:New ext4 features
(→New Features for discussion:) |
(→New Features for discussion:) |
||
| Line 2: | Line 2: | ||
== New Features for discussion: == | == New Features for discussion: == | ||
| − | + | Not sure if this is the place, but for your discussion here is my proposal for a feature: | |
SAN Bacup aware FS | SAN Bacup aware FS | ||
| Line 9: | Line 9: | ||
If the FS were multiple access aware then it could freeze the data and record to journal only any changes untill the backup is done. | If the FS were multiple access aware then it could freeze the data and record to journal only any changes untill the backup is done. | ||
I see this happening as follows: | I see this happening as follows: | ||
| − | + | ||
| − | + | #. A part of the FS structure is reserved for another host to write a predefined patern. | |
| − | + | #. If the patern is written to that area then: | |
| − | + | ##. The file system will guarantee that after a set number of miliseconds all new writes will be to journal only. | |
| − | + | ##. The FS will update another reserved structure to reflect the journaling status. | |
| + | #. A different patern written to the same structure will ask for the FS to return to normal and flush the journal to normal disk locations. | ||
Thus a remote backup host could; ask for the FS to start journal only operation, find out it has done so, back up the data with an understanding of the file system, and inform the FS top revert to normal operation. | Thus a remote backup host could; ask for the FS to start journal only operation, find out it has done so, back up the data with an understanding of the file system, and inform the FS top revert to normal operation. | ||
| Line 19: | Line 20: | ||
It may be required that the FS still needs the notifications to be provided by a deamon runing on the host rather than via direct hard disk access, but if the FS is aware and can "advertise" it is in multi access mode, then backup by systems that know the FS in use is quite simple and prevents the host being backed up getting involved in the process much. | It may be required that the FS still needs the notifications to be provided by a deamon runing on the host rather than via direct hard disk access, but if the FS is aware and can "advertise" it is in multi access mode, then backup by systems that know the FS in use is quite simple and prevents the host being backed up getting involved in the process much. | ||
| − | Chris. | + | Chris. |
Revision as of 17:04, 29 January 2007
New Features for discussion:
Not sure if this is the place, but for your discussion here is my proposal for a feature: SAN Bacup aware FS
My thinking goes like thus; When in a SAN environment a backup server still has to ask the host with data to be backed up to send it the data. If the FS were multiple access aware then it could freeze the data and record to journal only any changes untill the backup is done. I see this happening as follows:
- . A part of the FS structure is reserved for another host to write a predefined patern.
- . If the patern is written to that area then:
- . The file system will guarantee that after a set number of miliseconds all new writes will be to journal only.
- . The FS will update another reserved structure to reflect the journaling status.
- . A different patern written to the same structure will ask for the FS to return to normal and flush the journal to normal disk locations.
Thus a remote backup host could; ask for the FS to start journal only operation, find out it has done so, back up the data with an understanding of the file system, and inform the FS top revert to normal operation.
It may be required that the FS still needs the notifications to be provided by a deamon runing on the host rather than via direct hard disk access, but if the FS is aware and can "advertise" it is in multi access mode, then backup by systems that know the FS in use is quite simple and prevents the host being backed up getting involved in the process much.
Chris.
