Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #123196 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2017-11-21 11:50 -0800 |
| Last post | 2017-11-22 16:36 +0000 |
| Articles | 20 on this page of 82 — 15 participants |
Back to article view | Back to comp.lang.c
[sot] file times / file metadata fir <profesor.fir@gmail.com> - 2017-11-21 11:50 -0800
Re: [sot] file times / file metadata "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-11-21 21:05 +0100
Re: [sot] file times / file metadata Ian Collins <ian-news@hotmail.com> - 2017-11-22 09:15 +1300
Re: [sot] file times / file metadata fir <profesor.fir@gmail.com> - 2017-11-21 12:23 -0800
Re: [sot] file times / file metadata fir <profesor.fir@gmail.com> - 2017-11-21 12:42 -0800
Re: [sot] file times / file metadata fir <profesor.fir@gmail.com> - 2017-11-21 13:01 -0800
Re: [sot] file times / file metadata "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-11-21 22:04 +0100
Re: [sot] file times / file metadata fir <profesor.fir@gmail.com> - 2017-11-21 13:17 -0800
Re: [sot] file times / file metadata fir <profesor.fir@gmail.com> - 2017-11-21 13:22 -0800
Re: [sot] file times / file metadata "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-11-21 23:23 +0100
Re: [sot] file times / file metadata Ian Collins <ian-news@hotmail.com> - 2017-11-22 11:34 +1300
Re: [sot] file times / file metadata Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2017-11-21 17:34 -0500
Re: [sot] file times / file metadata fir <profesor.fir@gmail.com> - 2017-11-21 16:16 -0800
Re: [sot] file times / file metadata "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-11-22 01:44 +0100
Re: [sot] file times / file metadata Ian Collins <ian-news@hotmail.com> - 2017-11-22 14:10 +1300
Re: [sot] file times / file metadata gordonb.eiy78@burditt.org (Gordon Burditt) - 2017-11-28 01:55 -0600
Re: [sot] file times / file metadata David Brown <david.brown@hesbynett.no> - 2017-11-22 11:07 +0100
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-11-22 09:13 -0500
Re: [sot] file times / file metadata David Brown <david.brown@hesbynett.no> - 2017-11-22 15:50 +0100
Re: [sot] file times / file metadata jameskuyper@verizon.net - 2017-11-22 07:08 -0800
Re: [sot] file times / file metadata David Brown <david.brown@hesbynett.no> - 2017-11-22 16:22 +0100
Re: [sot] file times / file metadata bartc <bc@freeuk.com> - 2017-11-22 15:37 +0000
Re: [sot] file times / file metadata bartc <bc@freeuk.com> - 2017-11-22 15:43 +0000
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-11-22 15:01 -0500
Re: [sot] file times / file metadata Ian Collins <ian-news@hotmail.com> - 2017-11-23 17:52 +1300
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-11-23 14:12 -0500
Re: [sot] file times / file metadata Ian Collins <ian-news@hotmail.com> - 2017-11-24 08:28 +1300
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-11-24 08:52 -0500
Re: [sot] file times / file metadata David Brown <david.brown@hesbynett.no> - 2017-11-23 09:39 +0100
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-11-23 14:17 -0500
Re: [sot] file times / file metadata cross@spitfire.i.gajendra.net (Dan Cross) - 2017-11-28 16:44 +0000
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-11-28 14:23 -0500
Re: [sot] file times / file metadata cross@spitfire.i.gajendra.net (Dan Cross) - 2017-11-28 19:35 +0000
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-11-30 15:54 -0500
Re: [sot] file times / file metadata cross@spitfire.i.gajendra.net (Dan Cross) - 2017-11-30 21:43 +0000
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-12-04 11:42 -0500
Re: [sot] file times / file metadata cross@spitfire.i.gajendra.net (Dan Cross) - 2017-12-04 19:35 +0000
Re: [sot] file times / file metadata Keith Thompson <kst-u@mib.org> - 2017-12-04 11:53 -0800
Re: [sot] file times / file metadata cross@spitfire.i.gajendra.net (Dan Cross) - 2017-12-04 20:11 +0000
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-12-04 15:03 -0500
Re: [sot] file times / file metadata scott@slp53.sl.home (Scott Lurndal) - 2017-11-28 19:42 +0000
Re: [sot] file times / file metadata cross@spitfire.i.gajendra.net (Dan Cross) - 2017-11-28 20:13 +0000
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-11-30 15:57 -0500
Re: [sot] file times / file metadata scott@slp53.sl.home (Scott Lurndal) - 2017-11-30 21:17 +0000
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-12-04 11:56 -0500
Re: [sot] file times / file metadata scott@slp53.sl.home (Scott Lurndal) - 2017-12-04 18:36 +0000
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-12-04 15:07 -0500
Re: [sot] file times / file metadata scott@slp53.sl.home (Scott Lurndal) - 2017-12-04 22:27 +0000
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-12-04 17:57 -0500
Re: [sot] file times / file metadata David Brown <david.brown@hesbynett.no> - 2017-12-05 08:50 +0100
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-12-05 08:49 -0500
Re: [sot] file times / file metadata David Brown <david.brown@hesbynett.no> - 2017-12-05 15:17 +0100
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-12-05 16:32 -0500
Re: [sot] file times / file metadata scott@slp53.sl.home (Scott Lurndal) - 2017-12-05 15:29 +0000
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-12-05 16:37 -0500
Re: [sot] file times / file metadata scott@slp53.sl.home (Scott Lurndal) - 2017-12-06 01:26 +0000
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-12-06 12:38 -0500
Re: [sot] file times / file metadata scott@slp53.sl.home (Scott Lurndal) - 2017-12-06 01:27 +0000
Re: [sot] file times / file metadata jameskuyper@verizon.net - 2017-11-28 09:35 -0800
Re: [sot] file times / file metadata Ian Collins <ian-news@hotmail.com> - 2017-11-29 08:24 +1300
Re: [sot] file times / file metadata Ian Collins <ian-news@hotmail.com> - 2017-11-29 08:27 +1300
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-11-28 14:29 -0500
Re: [sot] file times / file metadata David Brown <david.brown@hesbynett.no> - 2017-11-29 09:51 +0100
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-11-30 15:59 -0500
Re: [sot] file times / file metadata David Brown <david.brown@hesbynett.no> - 2017-11-29 10:00 +0100
Re: [sot] file times / file metadata "James R. Kuyper" <jameskuyper@verizon.net> - 2017-11-29 09:11 -0500
Re: [sot] file times / file metadata David Brown <david.brown@hesbynett.no> - 2017-11-29 15:28 +0100
Re: [sot] file times / file metadata "James R. Kuyper" <jameskuyper@verizon.net> - 2017-11-29 11:32 -0500
Re: [sot] file times / file metadata James Kuyper <jameskuyper@verizon.net> - 2017-11-23 15:05 -0500
Re: [sot] file times / file metadata David Brown <david.brown@hesbynett.no> - 2017-11-24 10:20 +0100
Re: [sot] file times / file metadata Jerry Stuckle <jstucklex@attglobal.net> - 2017-11-24 09:05 -0500
Re: [sot] file times / file metadata Robert Wessel <robertwessel2@yahoo.com> - 2017-11-24 22:50 -0600
Re: [sot] file times / file metadata cross@spitfire.i.gajendra.net (Dan Cross) - 2017-11-28 16:59 +0000
Re: [sot] file times / file metadata Ian Collins <ian-news@hotmail.com> - 2017-11-29 08:26 +1300
Re: [sot] file times / file metadata David Brown <david.brown@hesbynett.no> - 2017-11-29 10:10 +0100
Re: [sot] file times / file metadata cross@spitfire.i.gajendra.net (Dan Cross) - 2017-11-29 21:01 +0000
Re: [sot] file times / file metadata David Brown <david.brown@hesbynett.no> - 2017-11-29 23:13 +0100
Re: [sot] file times / file metadata cross@spitfire.i.gajendra.net (Dan Cross) - 2017-11-30 17:26 +0000
Re: [sot] file times / file metadata fir <profesor.fir@gmail.com> - 2017-11-22 08:00 -0800
Re: [sot] file times / file metadata "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-11-22 17:11 +0100
Re: [sot] file times / file metadata "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-11-22 16:51 +0100
Re: [sot] file times / file metadata scott@slp53.sl.home (Scott Lurndal) - 2017-11-22 16:36 +0000
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-11-29 08:27 +1300 |
| Message-ID | <f85rlkFgmrlU4@mid.individual.net> |
| In reply to | #123580 |
On 11/29/2017 08:24 AM, Ian Collins wrote: > On 11/29/2017 06:35 AM, jameskuyper@verizon.net wrote: >> >> I don't know anything about this feature other than what Dave has told us >> about it and what I found at >> <https://btrfs.wiki.kernel.org/index.php/Incremental_Backup>. From Dave's >> responses to my questions, until such time as CoW is triggered, it would >> be more accurate to compare this feature to a hard link, rather than a >> symbolic link. When a file has one or more hard links, all of those links >> are equally good ways to access the file, and the file itself does not get >> deleted until the original and ALL of the links have been deleted (at >> least, that's the case on the Unix-like systems I'm more familiar with). >> From what Dave says, this feature works that same way. > > That is not how a ZFS snapshot works. A file is in a snapshot is a > distinct read only copy of the original. File F in a snapshot snap is > accessed as .zfs/snapshot/snap/F. F can be deleted at any time. The > only way to delete the copy is to destroy the snapshot. Thus hard links > are not at all like hard links. Too early in the morning... "Thus snapshots are not at all like hard links." -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-11-28 14:29 -0500 |
| Message-ID | <ovkdeo$est$1@jstuckle.eternal-september.org> |
| In reply to | #123578 |
On 11/28/2017 12:35 PM, jameskuyper@verizon.net wrote: > On Thursday, November 23, 2017 at 2:17:11 PM UTC-5, Jerry Stuckle wrote: >> On 11/23/2017 3:39 AM, David Brown wrote: >>> On 22/11/17 21:01, Jerry Stuckle wrote: >>>> On 11/22/2017 10:08 AM, jameskuyper@verizon.net wrote: >>>>> On Wednesday, November 22, 2017 at 9:50:23 AM UTC-5, David Brown wrote: > ... >>>>>> Google "btrfs snapshots", "zfs snapshots" or "lvm snapshots". All of >>>>>> these make logical copies of files without actually reading or writing >>>>>> any data. >>>>> >>>>> <https://btrfs.wiki.kernel.org/index.php/Incremental_Backup> describes >>>>> them as "COW" snapshots. I assume that "COW" stands for "copy on >>>>> write" - which means the snapshot is only some kind of alias for the >>>>> original file. Actual file copying only takes place when either the >>>>> original or one of the aliases gets written to - and that copying does >>>>> in fact involve reading the original file before writing the copy. > ... >> Yes, both the *nix cp and Windows copy commands make duplicates of the >> file. You can delete the original and the copy will remain. > > Note: the same is true of ln command in Unix-like systems: if you make a > hard link to a file and delete the original, the link remains. The actual > physical file does not get deleted until all links to it have been > removed. But I am in agreement with you that this is not a true copy, > because changes to the original will also appear in all of the linked > files, and vice-versa. > >>> With a COW copy on btrfs, zfs, lvm, or other filessystem/block devices >>> with such features, you can /delete/ the original and the copy is still >>> there. That is, at heart, what most people think of as "making a copy". >>> >> >> What is not making a copy of a file. That is making a duplicate on >> write. Or creating a symbolic link, in which case destroying the >> original destroys the link. > > Note: I am in the unusual position of agreeing with you that this is NOT a > true copy, so please do not respond in a fashion that assumes I'm disagreeing with you on that point. I am not discussing that issue in this > message. In this message I am only addressing the analogy you're making > with symbolic links. > > I don't know anything about this feature other than what Dave has told us > about it and what I found at > <https://btrfs.wiki.kernel.org/index.php/Incremental_Backup>. From Dave's > responses to my questions, until such time as CoW is triggered, it would > be more accurate to compare this feature to a hard link, rather than a > symbolic link. When a file has one or more hard links, all of those links > are equally good ways to access the file, and the file itself does not get > deleted until the original and ALL of the links have been deleted (at > least, that's the case on the Unix-like systems I'm more familiar with). > From what Dave says, this feature works that same way. > > Do you have any alternative source of information that justifies comparing > this to a symbolic link, when Dave has agreed with my suggestion that it > resembles a hard link? If so, what is that alternative source, and what > precisely does it say about this issue? > A quick search shows this link on stackoverflow. I think it describes things pretty well: https://stackoverflow.com/questions/628938/what-is-copy-on-write -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-11-29 09:51 +0100 |
| Message-ID | <ovlsfd$isg$1@dont-email.me> |
| In reply to | #123583 |
On 28/11/17 20:29, Jerry Stuckle wrote: > On 11/28/2017 12:35 PM, jameskuyper@verizon.net wrote: >> On Thursday, November 23, 2017 at 2:17:11 PM UTC-5, Jerry Stuckle wrote: >>> On 11/23/2017 3:39 AM, David Brown wrote: >>>> On 22/11/17 21:01, Jerry Stuckle wrote: >>>>> On 11/22/2017 10:08 AM, jameskuyper@verizon.net wrote: >>>>>> On Wednesday, November 22, 2017 at 9:50:23 AM UTC-5, David Brown >>>>>> wrote: >> ... >>>>>>> Google "btrfs snapshots", "zfs snapshots" or "lvm snapshots". >>>>>>> All of >>>>>>> these make logical copies of files without actually reading or >>>>>>> writing >>>>>>> any data. >>>>>> >>>>>> <https://btrfs.wiki.kernel.org/index.php/Incremental_Backup> >>>>>> describes >>>>>> them as "COW" snapshots. I assume that "COW" stands for "copy on >>>>>> write" - which means the snapshot is only some kind of alias for the >>>>>> original file. Actual file copying only takes place when either the >>>>>> original or one of the aliases gets written to - and that copying >>>>>> does >>>>>> in fact involve reading the original file before writing the copy. >> ... >>> Yes, both the *nix cp and Windows copy commands make duplicates of the >>> file. You can delete the original and the copy will remain. >> >> Note: the same is true of ln command in Unix-like systems: if you make a >> hard link to a file and delete the original, the link remains. The actual >> physical file does not get deleted until all links to it have been >> removed. But I am in agreement with you that this is not a true copy, >> because changes to the original will also appear in all of the linked >> files, and vice-versa. >> >>>> With a COW copy on btrfs, zfs, lvm, or other filessystem/block devices >>>> with such features, you can /delete/ the original and the copy is still >>>> there. That is, at heart, what most people think of as "making a >>>> copy". >>>> >>> >>> What is not making a copy of a file. That is making a duplicate on >>> write. Or creating a symbolic link, in which case destroying the >>> original destroys the link. >> >> Note: I am in the unusual position of agreeing with you that this is >> NOT a >> true copy, so please do not respond in a fashion that assumes I'm >> disagreeing with you on that point. I am not discussing that issue in >> this >> message. In this message I am only addressing the analogy you're making >> with symbolic links. >> >> I don't know anything about this feature other than what Dave has told us >> about it and what I found at >> <https://btrfs.wiki.kernel.org/index.php/Incremental_Backup>. From Dave's >> responses to my questions, until such time as CoW is triggered, it would >> be more accurate to compare this feature to a hard link, rather than a >> symbolic link. When a file has one or more hard links, all of those links >> are equally good ways to access the file, and the file itself does not >> get >> deleted until the original and ALL of the links have been deleted (at >> least, that's the case on the Unix-like systems I'm more familiar with). >> From what Dave says, this feature works that same way. >> >> Do you have any alternative source of information that justifies >> comparing >> this to a symbolic link, when Dave has agreed with my suggestion that it >> resembles a hard link? If so, what is that alternative source, and what >> precisely does it say about this issue? >> > > A quick search shows this link on stackoverflow. I think it describes > things pretty well: > > https://stackoverflow.com/questions/628938/what-is-copy-on-write > The answer from that link is a direct quotation from Wikipedia, which would have made a lot more sense here: <https://en.wikipedia.org/wiki/Copy-on-write> But that would mean Jerry would have to admit that Wikipedia could get something right, and he can't bring himself to say that. (The Wikipedia page gives quite a good explanation here.)
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-11-30 15:59 -0500 |
| Message-ID | <ovprei$rlk$2@jstuckle.eternal-september.org> |
| In reply to | #123594 |
On 11/29/2017 3:51 AM, David Brown wrote: > On 28/11/17 20:29, Jerry Stuckle wrote: >> On 11/28/2017 12:35 PM, jameskuyper@verizon.net wrote: >>> On Thursday, November 23, 2017 at 2:17:11 PM UTC-5, Jerry Stuckle wrote: >>>> On 11/23/2017 3:39 AM, David Brown wrote: >>>>> On 22/11/17 21:01, Jerry Stuckle wrote: >>>>>> On 11/22/2017 10:08 AM, jameskuyper@verizon.net wrote: >>>>>>> On Wednesday, November 22, 2017 at 9:50:23 AM UTC-5, David Brown >>>>>>> wrote: >>> ... >>>>>>>> Google "btrfs snapshots", "zfs snapshots" or "lvm snapshots". >>>>>>>> All of >>>>>>>> these make logical copies of files without actually reading or >>>>>>>> writing >>>>>>>> any data. >>>>>>> >>>>>>> <https://btrfs.wiki.kernel.org/index.php/Incremental_Backup> >>>>>>> describes >>>>>>> them as "COW" snapshots. I assume that "COW" stands for "copy on >>>>>>> write" - which means the snapshot is only some kind of alias for the >>>>>>> original file. Actual file copying only takes place when either the >>>>>>> original or one of the aliases gets written to - and that copying >>>>>>> does >>>>>>> in fact involve reading the original file before writing the copy. >>> ... >>>> Yes, both the *nix cp and Windows copy commands make duplicates of the >>>> file. You can delete the original and the copy will remain. >>> >>> Note: the same is true of ln command in Unix-like systems: if you make a >>> hard link to a file and delete the original, the link remains. The actual >>> physical file does not get deleted until all links to it have been >>> removed. But I am in agreement with you that this is not a true copy, >>> because changes to the original will also appear in all of the linked >>> files, and vice-versa. >>> >>>>> With a COW copy on btrfs, zfs, lvm, or other filessystem/block devices >>>>> with such features, you can /delete/ the original and the copy is still >>>>> there. That is, at heart, what most people think of as "making a >>>>> copy". >>>>> >>>> >>>> What is not making a copy of a file. That is making a duplicate on >>>> write. Or creating a symbolic link, in which case destroying the >>>> original destroys the link. >>> >>> Note: I am in the unusual position of agreeing with you that this is >>> NOT a >>> true copy, so please do not respond in a fashion that assumes I'm >>> disagreeing with you on that point. I am not discussing that issue in >>> this >>> message. In this message I am only addressing the analogy you're making >>> with symbolic links. >>> >>> I don't know anything about this feature other than what Dave has told us >>> about it and what I found at >>> <https://btrfs.wiki.kernel.org/index.php/Incremental_Backup>. From Dave's >>> responses to my questions, until such time as CoW is triggered, it would >>> be more accurate to compare this feature to a hard link, rather than a >>> symbolic link. When a file has one or more hard links, all of those links >>> are equally good ways to access the file, and the file itself does not >>> get >>> deleted until the original and ALL of the links have been deleted (at >>> least, that's the case on the Unix-like systems I'm more familiar with). >>> From what Dave says, this feature works that same way. >>> >>> Do you have any alternative source of information that justifies >>> comparing >>> this to a symbolic link, when Dave has agreed with my suggestion that it >>> resembles a hard link? If so, what is that alternative source, and what >>> precisely does it say about this issue? >>> >> >> A quick search shows this link on stackoverflow. I think it describes >> things pretty well: >> >> https://stackoverflow.com/questions/628938/what-is-copy-on-write >> > > The answer from that link is a direct quotation from Wikipedia, which > would have made a lot more sense here: > > <https://en.wikipedia.org/wiki/Copy-on-write> > > But that would mean Jerry would have to admit that Wikipedia could get > something right, and he can't bring himself to say that. > > (The Wikipedia page gives quite a good explanation here.) > > I've never said Wikipedia doesn't ever get things right. In fact, I admit sometimes they do get it right. That's where they differ from you, David. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-11-29 10:00 +0100 |
| Message-ID | <ovlsun$l95$1@dont-email.me> |
| In reply to | #123578 |
On 28/11/17 18:35, jameskuyper@verizon.net wrote: > On Thursday, November 23, 2017 at 2:17:11 PM UTC-5, Jerry Stuckle wrote: >> On 11/23/2017 3:39 AM, David Brown wrote: >>> On 22/11/17 21:01, Jerry Stuckle wrote: >>>> On 11/22/2017 10:08 AM, jameskuyper@verizon.net wrote: >>>>> On Wednesday, November 22, 2017 at 9:50:23 AM UTC-5, David Brown wrote: > ... >>>>>> Google "btrfs snapshots", "zfs snapshots" or "lvm snapshots". All of >>>>>> these make logical copies of files without actually reading or writing >>>>>> any data. >>>>> >>>>> <https://btrfs.wiki.kernel.org/index.php/Incremental_Backup> describes >>>>> them as "COW" snapshots. I assume that "COW" stands for "copy on >>>>> write" - which means the snapshot is only some kind of alias for the >>>>> original file. Actual file copying only takes place when either the >>>>> original or one of the aliases gets written to - and that copying does >>>>> in fact involve reading the original file before writing the copy. > ... >> Yes, both the *nix cp and Windows copy commands make duplicates of the >> file. You can delete the original and the copy will remain. > > Note: the same is true of ln command in Unix-like systems: if you make a > hard link to a file and delete the original, the link remains. The actual > physical file does not get deleted until all links to it have been > removed. But I am in agreement with you that this is not a true copy, > because changes to the original will also appear in all of the linked > files, and vice-versa. > >>> With a COW copy on btrfs, zfs, lvm, or other filessystem/block devices >>> with such features, you can /delete/ the original and the copy is still >>> there. That is, at heart, what most people think of as "making a copy". >>> >> >> What is not making a copy of a file. That is making a duplicate on >> write. Or creating a symbolic link, in which case destroying the >> original destroys the link. > > Note: I am in the unusual position of agreeing with you that this is NOT a > true copy, so please do not respond in a fashion that assumes I'm disagreeing with you on that point. I am not discussing that issue in this > message. In this message I am only addressing the analogy you're making > with symbolic links. > > I don't know anything about this feature other than what Dave has told us > about it and what I found at > <https://btrfs.wiki.kernel.org/index.php/Incremental_Backup>. From Dave's > responses to my questions, until such time as CoW is triggered, it would > be more accurate to compare this feature to a hard link, rather than a > symbolic link. When a file has one or more hard links, all of those links > are equally good ways to access the file, and the file itself does not get > deleted until the original and ALL of the links have been deleted (at > least, that's the case on the Unix-like systems I'm more familiar with). > From what Dave says, this feature works that same way. > Am I the "Dave" in question? I am almost invariably known as "David". Yes, CoW is closer to hard links than to soft links - each CoW link to the same data is equally valid and there is a reference count. You can't get dangling CoW links, just as you can't get dangling hard links, but you /can/ get dangling soft links. But the key difference is that with hard links, if you use one link to change a file, it changes for all the links - while with CoW, if you use one CoW reference to change the file, you get a new "real" copy and only that version changes - the other CoW references all point to the same original data. (As was mentioned, or at least implied, by other posters - you don't necessarily need to copy the entire file. Sometimes just the bits that change are copied - and on a re-write, perhaps nothing is copied.) If you are familiar with the way Unix-like OS's handle fork using page tables, then you will understand CoW. When a process forks, the read-write memory pages of the original process are made read-only. If one of the processes - the original or the new one, which starts out almost identical (except for the return value of "fork()") - tries to write to one of those pages, it will cause a fault. The OS then copies the pages, marks each as writeable and puts one of the copies in each process's memory spaces. The write can then continue. "Copy on write" - the name says it all. > Do you have any alternative source of information that justifies comparing > this to a symbolic link, when Dave has agreed with my suggestion that it > resembles a hard link? If so, what is that alternative source, and what > precisely does it say about this issue? >
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-11-29 09:11 -0500 |
| Message-ID | <8fb40c49-c4b5-7fbb-11b8-c12d4f57ca09@verizon.net> |
| In reply to | #123595 |
On 11/29/2017 04:00 AM, David Brown wrote: > On 28/11/17 18:35, jameskuyper@verizon.net wrote: ... >> I don't know anything about this feature other than what Dave has told us >> about it and what I found at >> <https://btrfs.wiki.kernel.org/index.php/Incremental_Backup>. From Dave's >> responses to my questions, until such time as CoW is triggered, it would >> be more accurate to compare this feature to a hard link, rather than a >> symbolic link. When a file has one or more hard links, all of those links >> are equally good ways to access the file, and the file itself does not get >> deleted until the original and ALL of the links have been deleted (at >> least, that's the case on the Unix-like systems I'm more familiar with). >> From what Dave says, this feature works that same way. >> > > Am I the "Dave" in question? I am almost invariably known as "David". Yes. Most Davids I've known answer equally happily to Dave, I didn't even think about it when I shortened your name in this case. I'll try to remember in the future. > Yes, CoW is closer to hard links than to soft links - each CoW link to > the same data is equally valid and there is a reference count. You > can't get dangling CoW links, just as you can't get dangling hard links, > but you /can/ get dangling soft links. But the key difference is that > with hard links, if you use one link to change a file, it changes for > all the links - while with CoW, if you use one CoW reference to change > the file, you get a new "real" copy and only that version changes - the > other CoW references all point to the same original data. I only referred to this feature as working like a Unix hard link, up until the first time that CoW is triggered. That phrase is still visible above in the paragraph you quoted and responded to. After that it works somewhat differently from anything else I've ever heard of.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-11-29 15:28 +0100 |
| Message-ID | <ovmg6u$pvh$1@dont-email.me> |
| In reply to | #123601 |
On 29/11/17 15:11, James R. Kuyper wrote: > On 11/29/2017 04:00 AM, David Brown wrote: >> On 28/11/17 18:35, jameskuyper@verizon.net wrote: > ... >>> I don't know anything about this feature other than what Dave has >>> told us >>> about it and what I found at >>> <https://btrfs.wiki.kernel.org/index.php/Incremental_Backup>. From >>> Dave's >>> responses to my questions, until such time as CoW is triggered, it would >>> be more accurate to compare this feature to a hard link, rather than a >>> symbolic link. When a file has one or more hard links, all of those >>> links >>> are equally good ways to access the file, and the file itself does >>> not get >>> deleted until the original and ALL of the links have been deleted (at >>> least, that's the case on the Unix-like systems I'm more familiar with). >>> From what Dave says, this feature works that same way. >>> >> >> Am I the "Dave" in question? I am almost invariably known as "David". > > Yes. Most Davids I've known answer equally happily to Dave, I didn't > even think about it when I shortened your name in this case. I'll try to > remember in the future. Well, it is closer than referring to you as "Ben" :-) I don't really object - I was merely a little confused because almost no one calls me "Dave". > >> Yes, CoW is closer to hard links than to soft links - each CoW link to >> the same data is equally valid and there is a reference count. You >> can't get dangling CoW links, just as you can't get dangling hard links, >> but you /can/ get dangling soft links. But the key difference is that >> with hard links, if you use one link to change a file, it changes for >> all the links - while with CoW, if you use one CoW reference to change >> the file, you get a new "real" copy and only that version changes - the >> other CoW references all point to the same original data. > > I only referred to this feature as working like a Unix hard link, up > until the first time that CoW is triggered. Yes, and that is entirely correct. > That phrase is still visible > above in the paragraph you quoted and responded to. After that it works > somewhat differently from anything else I've ever heard of. Well, you've heard of "fork()" ? But you may simply not have known how it works. I find that kind of thing interesting, but most people don't. Other examples of CoW that you may have come across are Linux LVM (logical volume management) and snapshots for virtual machines (kvm, VirtualBox, VMWare all support snapshots). It is also a possible way to implement reference counted strings or other data structures - it can add a bit of overhead, but makes things more efficient if you do a lot of copying.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-11-29 11:32 -0500 |
| Message-ID | <7c7c2707-b985-8d21-6e4a-816089a24393@verizon.net> |
| In reply to | #123602 |
On 11/29/2017 09:28 AM, David Brown wrote: > On 29/11/17 15:11, James R. Kuyper wrote: >> On 11/29/2017 04:00 AM, David Brown wrote: >>> On 28/11/17 18:35, jameskuyper@verizon.net wrote: >> ... >>>> I don't know anything about this feature other than what Dave has >>>> told us >>>> about it and what I found at >>>> <https://btrfs.wiki.kernel.org/index.php/Incremental_Backup>. From >>>> Dave's >>>> responses to my questions, until such time as CoW is triggered, it would >>>> be more accurate to compare this feature to a hard link, rather than a >>>> symbolic link. When a file has one or more hard links, all of those >>>> links >>>> are equally good ways to access the file, and the file itself does >>>> not get >>>> deleted until the original and ALL of the links have been deleted (at >>>> least, that's the case on the Unix-like systems I'm more familiar with). >>>> From what Dave says, this feature works that same way. ... >>> Yes, CoW is closer to hard links than to soft links - each CoW link to >>> the same data is equally valid and there is a reference count. You >>> can't get dangling CoW links, just as you can't get dangling hard links, >>> but you /can/ get dangling soft links. But the key difference is that >>> with hard links, if you use one link to change a file, it changes for >>> all the links - while with CoW, if you use one CoW reference to change >>> the file, you get a new "real" copy and only that version changes - the >>> other CoW references all point to the same original data. >> >> I only referred to this feature as working like a Unix hard link, up >> until the first time that CoW is triggered. > > Yes, and that is entirely correct. > >> That phrase is still visible >> above in the paragraph you quoted and responded to. After that it works >> somewhat differently from anything else I've ever heard of. > > Well, you've heard of "fork()" ? But you may simply not have known how > it works. I find that kind of thing interesting, but most people don't. I've heard of fork(), and even know some details about how it works, though I don't think I've ever actually used it. I'm aware that it does CoW, but I would not have thought to compare that fact to this feature.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-11-23 15:05 -0500 |
| Message-ID | <ov79m6$bmh$1@dont-email.me> |
| In reply to | #123358 |
On 11/23/2017 03:39 AM, David Brown wrote: > On 22/11/17 21:01, Jerry Stuckle wrote: >> On 11/22/2017 10:08 AM, jameskuyper@verizon.net wrote: >>> On Wednesday, November 22, 2017 at 9:50:23 AM UTC-5, David Brown wrote: >>>> On 22/11/17 15:13, Jerry Stuckle wrote: >>>>> On 11/22/2017 5:07 AM, David Brown wrote: >>>>>> On 21/11/17 22:04, Pascal J. Bourguignon wrote: >>>>>>> fir <profesor.fir@gmail.com> writes: >>>>>>> >>>>>>>> note yet i made some test that was >>>>>>>> copyying file in total comender and the result is a bit discussable >>>>>>>> >>>>>>>> >>>>>>>> - when i copied file the old one file changed acces time to current >>>>>>>> (though i was not opening it only copying) >>>>>>> >>>>>>> Think about it! >>>>>>> >>>>>>> How would YOU copy the file if not by opening it and reading it? >>>>>>> >>>>>>> (There is an answer, and once you find it, you'll understand >>>>>>> why it's >>>>>>> not provided, and why you have to open the file and read it to >>>>>>> copy it). >>>>>>> >>>>>> >>>>>> I can think of ways to copy a file without reading it. In fact, I >>>>>> regularly make copies of my entire filesystems without reading them. >>>>>> >>>>>> >>>>> >>>>> I would love to see how you copy a file or filesystem without >>>>> reading it. >>>>> >>>> >>>> Google "btrfs snapshots", "zfs snapshots" or "lvm snapshots". All of >>>> these make logical copies of files without actually reading or writing >>>> any data. >>> >>> <https://btrfs.wiki.kernel.org/index.php/Incremental_Backup> describes >>> them as "COW" snapshots. I assume that "COW" stands for "copy on >>> write" - which means the snapshot is only some kind of alias for the >>> original file. Actual file copying only takes place when either the >>> original or one of the aliases gets written to - and that copying does >>> in fact involve reading the original file before writing the copy. >>> >> >> You've got it. If you make a copy of something, the copy should still >> exist when the original is destroyed - i.e. the disk is reformatted or >> whatever. David's "copy" does not do that. > > Nor does the "cp" command in *nix, or "copy" command in Windows. Format > the disk containing the original and the copy of the file, and both are > gone. > > If you "copy" the file to another disk, then your office burns down, > both the original and copy are gone. > > See? Others can play stupid games too. > > With a COW copy on btrfs, zfs, lvm, or other filessystem/block devices > with such features, you can /delete/ the original and the copy is still > there. That is, at heart, what most people think of as "making a copy". I make no claim to know what "most people" think - but when I think of making a copy, I mean (among other things) that it's possible for the copy to get damaged, while the original remains intact (or vice versa). In fact, having a backup in case the original gets damaged is often the main reason for making the copy. It's always also possible for a sufficiently wide-spread distaster to damage both at the same time; but it's the possibility of damaging them independently that makes them true copies. If I understand this feature correctly, until the "Copy On Write" feature is triggered, the copy is similar to a Unix hard link to the original. I won't deny that COW makes this feature meaningfully different from a Unix hard link. However, the copy doesn't become a true copy in the sense I described above until COW has been triggered. Unix hard links can only occur between files on the same disk volume. Do these snapshots have the same restriction? If so, Jerry's example of a disk format doesn't make the distinction clear, because it would remove both the original and the copy. A better example would be a cosmic ray (or any other disturbance) that causes the stored data to be either modified or unreadable. With a true copy (such as the ones created by using the Unix cp command), such an event happening to the copy would have no affect on the original, and vice versa. With a Unix hard link, such an event would change both the original and the copy. If I understand this snapshot feature correctly, then prior to the first time COW is triggered, such an event would cause identical changes in both the original and the copy.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-11-24 10:20 +0100 |
| Message-ID | <ov8o8j$cvk$1@dont-email.me> |
| In reply to | #123399 |
On 23/11/17 21:05, James Kuyper wrote: > On 11/23/2017 03:39 AM, David Brown wrote: >> On 22/11/17 21:01, Jerry Stuckle wrote: >>> On 11/22/2017 10:08 AM, jameskuyper@verizon.net wrote: >>>> On Wednesday, November 22, 2017 at 9:50:23 AM UTC-5, David Brown wrote: >>>>> On 22/11/17 15:13, Jerry Stuckle wrote: >>>>>> On 11/22/2017 5:07 AM, David Brown wrote: >>>>>>> On 21/11/17 22:04, Pascal J. Bourguignon wrote: >>>>>>>> fir <profesor.fir@gmail.com> writes: >>>>>>>> >>>>>>>>> note yet i made some test that was >>>>>>>>> copyying file in total comender and the result is a bit discussable >>>>>>>>> >>>>>>>>> >>>>>>>>> - when i copied file the old one file changed acces time to current >>>>>>>>> (though i was not opening it only copying) >>>>>>>> >>>>>>>> Think about it! >>>>>>>> >>>>>>>> How would YOU copy the file if not by opening it and reading it? >>>>>>>> >>>>>>>> (There is an answer, and once you find it, you'll understand >>>>>>>> why it's >>>>>>>> not provided, and why you have to open the file and read it to >>>>>>>> copy it). >>>>>>>> >>>>>>> >>>>>>> I can think of ways to copy a file without reading it. In fact, I >>>>>>> regularly make copies of my entire filesystems without reading them. >>>>>>> >>>>>>> >>>>>> >>>>>> I would love to see how you copy a file or filesystem without >>>>>> reading it. >>>>>> >>>>> >>>>> Google "btrfs snapshots", "zfs snapshots" or "lvm snapshots". All of >>>>> these make logical copies of files without actually reading or writing >>>>> any data. >>>> >>>> <https://btrfs.wiki.kernel.org/index.php/Incremental_Backup> describes >>>> them as "COW" snapshots. I assume that "COW" stands for "copy on >>>> write" - which means the snapshot is only some kind of alias for the >>>> original file. Actual file copying only takes place when either the >>>> original or one of the aliases gets written to - and that copying does >>>> in fact involve reading the original file before writing the copy. >>>> >>> >>> You've got it. If you make a copy of something, the copy should still >>> exist when the original is destroyed - i.e. the disk is reformatted or >>> whatever. David's "copy" does not do that. >> >> Nor does the "cp" command in *nix, or "copy" command in Windows. Format >> the disk containing the original and the copy of the file, and both are >> gone. >> >> If you "copy" the file to another disk, then your office burns down, >> both the original and copy are gone. >> >> See? Others can play stupid games too. >> >> With a COW copy on btrfs, zfs, lvm, or other filessystem/block devices >> with such features, you can /delete/ the original and the copy is still >> there. That is, at heart, what most people think of as "making a copy". > > I make no claim to know what "most people" think - but when I think of > making a copy, I mean (among other things) that it's possible for the > copy to get damaged, while the original remains intact (or vice versa). > In fact, having a backup in case the original gets damaged is often the > main reason for making the copy. It's always also possible for a > sufficiently wide-spread distaster to damage both at the same time; but > it's the possibility of damaging them independently that makes them true > copies. (This is getting off-topic, so perhaps we don't want to carry on too long. And the thread has unfortunately attracted Jerry Stuckle, so noise is increased by him leaping in to tell people how wrong they are to say the sky is blue, and that this is not the way IBM does things.) I'd say the word "copy" here can have different meanings. To me, a "logical copy" is where it looks like you have a duplicate of the original, and the duplicate is unaffected by any changes or deletions on the original. But that assumes that everything is working correctly - the disk, the computer, the OS, the filesystem, etc. A "backup copy" is where you have more separation for the duplicate, and have at least some protection against problems like disk failures, software bugs, or - the most common cause of data loss - human error. I don't think there is any hard definitions - and different types of copy protect against different problems. A zfs/btrfs COW snapshot is the ideal choice to handle user error because it has virtually no cost for making as many copies as you want, and the restores are simple. But it is useless in the face of disk failure. When I say "copy a file" without any other qualifications, I would normally mean a logical copy. Whether that makes a second copy of the data sectors on the same disk (as you get with ext4, NTFS, etc.), or just a pointer and reference counter (as you get on zfs/btrfs on the same filesystem), it looks and acts the same. > > If I understand this feature correctly, until the "Copy On Write" > feature is triggered, the copy is similar to a Unix hard link to the > original. Yes. > I won't deny that COW makes this feature meaningfully > different from a Unix hard link. Indeed it does. With a *nix hard link, if you change one file then /both/ "copies" change. As long as you interact with the disk through the filesystem, the two copies are independent. If you use low-level disk editing to directly change the disk sectors, it is a different matter. > However, the copy doesn't become a true > copy in the sense I described above until COW has been triggered. > Correct. (Noting that many faults that can affect one physical copy of a file on a disk also have a fair chance of affecting other physical copies on the same disk.) > Unix hard links can only occur between files on the same disk volume. Do > these snapshots have the same restriction? Yes. (zfs and btrfs both support raid in the filesystem, and you can always use layers of raid, block device replication, iSCSI over networks, etc., to get multiple physical duplications of the data on more than one disk. But in such cases, you would have multiple physical duplications of the original file - and when you make a COW copy, you get an additional reference to that same set of duplications.) > If so, Jerry's example of a disk format doesn't make the distinction > clear, because it would remove both the original and the copy. Jerry's example adds confusion and shows his ignorance and misunderstandings in an attempt to "prove" someone else wrong? Who would have thought it? The only reason I reply to Jerry's posts is to try to limit the spread of confusion he sows. > A better > example would be a cosmic ray (or any other disturbance) that causes the > stored data to be either modified or unreadable. With a true copy (such > as the ones created by using the Unix cp command), such an event > happening to the copy would have no affect on the original, and vice > versa. Well, sort of. An unreadable disk sector (from whatever cause) in the middle of a file's data will render that file unreadable. And if there is a non-COW copy of the file, that copy will be unaffected. But unreadable sector errors can affect more critical structures - such as the directory that holds the references to both the copies, or a sector holding the inode tables affecting both files. A local copy is not a good way to protect against disk problems or SEU's - you want external backups or RAID for that. (I don't want to sound too much like an advert for btrfs/zfs, but these filesystems do a better job of duplicating critical data than ext4, and also checksum them better, so SEU's are less likely to be critical problems.) (On Linux with btrfs and a modern version of "cp", then "cp" does COW copies when it is on the same filesystem. I don't know if that also applies on Solaris/BSD with zfs, but I would expect so.) > With a Unix hard link, such an event would change both the > original and the copy. Yes. > If I understand this snapshot feature correctly, > then prior to the first time COW is triggered, such an event would cause > identical changes in both the original and the copy. > Yes, it could do so if the SEU hits the data section. These days I always make a point of using RAID in my machines (except laptops, but I consider the data on them to be throw-away). I use either btrfs with its built-in raid1 (physically duplicating all metadata and file data on both disks) or ext4 with Linux md raid1 (also doing physical duplication, but at a lower level.) btrfs raid1 is more efficient because it does not have to duplicate unused space as md raid does. With btrfs COW snapshots and raid1 duplication, I get the best of both worlds - at the cost of having two disks. (Backups to other machines and other locations are also good insurance, no matter how you arrange your filesystems and disks.) I think that is probably enough off-topic discussion on disks and filesystems. It looks like you have understood things mostly, and I hope I have filled in any gaps. If you have other questions, feel free to email me - I can talk about this stuff for many more pages :-)
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2017-11-24 09:05 -0500 |
| Message-ID | <ov98uf$vid$1@jstuckle.eternal-september.org> |
| In reply to | #123424 |
On 11/24/2017 4:20 AM, David Brown wrote: > On 23/11/17 21:05, James Kuyper wrote: >> On 11/23/2017 03:39 AM, David Brown wrote: >>> On 22/11/17 21:01, Jerry Stuckle wrote: >>>> On 11/22/2017 10:08 AM, jameskuyper@verizon.net wrote: >>>>> On Wednesday, November 22, 2017 at 9:50:23 AM UTC-5, David Brown wrote: >>>>>> On 22/11/17 15:13, Jerry Stuckle wrote: >>>>>>> On 11/22/2017 5:07 AM, David Brown wrote: >>>>>>>> On 21/11/17 22:04, Pascal J. Bourguignon wrote: >>>>>>>>> fir <profesor.fir@gmail.com> writes: >>>>>>>>> >>>>>>>>>> note yet i made some test that was >>>>>>>>>> copyying file in total comender and the result is a bit discussable >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> - when i copied file the old one file changed acces time to current >>>>>>>>>> (though i was not opening it only copying) >>>>>>>>> >>>>>>>>> Think about it! >>>>>>>>> >>>>>>>>> How would YOU copy the file if not by opening it and reading it? >>>>>>>>> >>>>>>>>> (There is an answer, and once you find it, you'll understand >>>>>>>>> why it's >>>>>>>>> not provided, and why you have to open the file and read it to >>>>>>>>> copy it). >>>>>>>>> >>>>>>>> >>>>>>>> I can think of ways to copy a file without reading it. In fact, I >>>>>>>> regularly make copies of my entire filesystems without reading them. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> I would love to see how you copy a file or filesystem without >>>>>>> reading it. >>>>>>> >>>>>> >>>>>> Google "btrfs snapshots", "zfs snapshots" or "lvm snapshots". All of >>>>>> these make logical copies of files without actually reading or writing >>>>>> any data. >>>>> >>>>> <https://btrfs.wiki.kernel.org/index.php/Incremental_Backup> describes >>>>> them as "COW" snapshots. I assume that "COW" stands for "copy on >>>>> write" - which means the snapshot is only some kind of alias for the >>>>> original file. Actual file copying only takes place when either the >>>>> original or one of the aliases gets written to - and that copying does >>>>> in fact involve reading the original file before writing the copy. >>>>> >>>> >>>> You've got it. If you make a copy of something, the copy should still >>>> exist when the original is destroyed - i.e. the disk is reformatted or >>>> whatever. David's "copy" does not do that. >>> >>> Nor does the "cp" command in *nix, or "copy" command in Windows. Format >>> the disk containing the original and the copy of the file, and both are >>> gone. >>> >>> If you "copy" the file to another disk, then your office burns down, >>> both the original and copy are gone. >>> >>> See? Others can play stupid games too. >>> >>> With a COW copy on btrfs, zfs, lvm, or other filessystem/block devices >>> with such features, you can /delete/ the original and the copy is still >>> there. That is, at heart, what most people think of as "making a copy". >> >> I make no claim to know what "most people" think - but when I think of >> making a copy, I mean (among other things) that it's possible for the >> copy to get damaged, while the original remains intact (or vice versa). >> In fact, having a backup in case the original gets damaged is often the >> main reason for making the copy. It's always also possible for a >> sufficiently wide-spread distaster to damage both at the same time; but >> it's the possibility of damaging them independently that makes them true >> copies. > > (This is getting off-topic, so perhaps we don't want to carry on too > long. And the thread has unfortunately attracted Jerry Stuckle, so > noise is increased by him leaping in to tell people how wrong they are > to say the sky is blue, and that this is not the way IBM does things.) > No, it was your stoopid statement that I'm calling you on. But rather than admit you're wrong, you're furiously backpedaling to try to prove you aren't. It's not working. > I'd say the word "copy" here can have different meanings. To me, a > "logical copy" is where it looks like you have a duplicate of the > original, and the duplicate is unaffected by any changes or deletions on > the original. But that assumes that everything is working correctly - > the disk, the computer, the OS, the filesystem, etc. A "backup copy" is > where you have more separation for the duplicate, and have at least some > protection against problems like disk failures, software bugs, or - the > most common cause of data loss - human error. > You can define "copy" all you want. But you're defining it for a audience of one. That is not what real programmers - or users, for that matter - identify as a copy. It is what James says it is. > I don't think there is any hard definitions - and different types of > copy protect against different problems. A zfs/btrfs COW snapshot is > the ideal choice to handle user error because it has virtually no cost > for making as many copies as you want, and the restores are simple. But > it is useless in the face of disk failure. > Not in the "dictionary of David Brown". But there is to the rest of the world. > When I say "copy a file" without any other qualifications, I would > normally mean a logical copy. Whether that makes a second copy of the > data sectors on the same disk (as you get with ext4, NTFS, etc.), or > just a pointer and reference counter (as you get on zfs/btrfs on the > same filesystem), it looks and acts the same. > You're in a vast minority here. Anyone with half of a brain knows a copy is a physical copy - whether it is a file or a sheet of paper. A pointer or reference counter is similar to a logical link; it is not a copy. >> >> If I understand this feature correctly, until the "Copy On Write" >> feature is triggered, the copy is similar to a Unix hard link to the >> original. > > Yes. > So it is not a copy. >> I won't deny that COW makes this feature meaningfully >> different from a Unix hard link. > > Indeed it does. With a *nix hard link, if you change one file then > /both/ "copies" change. As long as you interact with the disk through > the filesystem, the two copies are independent. If you use low-level > disk editing to directly change the disk sectors, it is a different matter. > And what happens if you format the original disk? COW just means it is writing a new file when the original changes. It does not make a copy of the original file. >> However, the copy doesn't become a true >> copy in the sense I described above until COW has been triggered. >> > > Correct. (Noting that many faults that can affect one physical copy of > a file on a disk also have a fair chance of affecting other physical > copies on the same disk.) > Gee so you finally admit it is not a real copy. >> Unix hard links can only occur between files on the same disk volume. Do >> these snapshots have the same restriction? > > Yes. (zfs and btrfs both support raid in the filesystem, and you can > always use layers of raid, block device replication, iSCSI over > networks, etc., to get multiple physical duplications of the data on > more than one disk. But in such cases, you would have multiple physical > duplications of the original file - and when you make a COW copy, you > get an additional reference to that same set of duplications.) > >> If so, Jerry's example of a disk format doesn't make the distinction >> clear, because it would remove both the original and the copy. > > Jerry's example adds confusion and shows his ignorance and > misunderstandings in an attempt to "prove" someone else wrong? Who > would have thought it? The only reason I reply to Jerry's posts is to > try to limit the spread of confusion he sows. > Nope. It's calling you on your stoopid statements. And by replying you are only showing everyone else how stoopid you really are. >> A better >> example would be a cosmic ray (or any other disturbance) that causes the >> stored data to be either modified or unreadable. With a true copy (such >> as the ones created by using the Unix cp command), such an event >> happening to the copy would have no affect on the original, and vice >> versa. > > Well, sort of. An unreadable disk sector (from whatever cause) in the > middle of a file's data will render that file unreadable. And if there > is a non-COW copy of the file, that copy will be unaffected. But > unreadable sector errors can affect more critical structures - such as > the directory that holds the references to both the copies, or a sector > holding the inode tables affecting both files. A local copy is not a > good way to protect against disk problems or SEU's - you want external > backups or RAID for that. (I don't want to sound too much like an > advert for btrfs/zfs, but these filesystems do a better job of > duplicating critical data than ext4, and also checksum them better, so > SEU's are less likely to be critical problems.) > So what if the bad sector affects more critical structures? That's completely irrelevant to the point that you're not talking about a real copy. But once again you are furiously backpedaling to try to prove you're right. But all you're doing is showing even more of your stoopidity. > (On Linux with btrfs and a modern version of "cp", then "cp" does COW > copies when it is on the same filesystem. I don't know if that also > applies on Solaris/BSD with zfs, but I would expect so.) > Which means it is not a real copy. > >> With a Unix hard link, such an event would change both the >> original and the copy. > > Yes. > >> If I understand this snapshot feature correctly, >> then prior to the first time COW is triggered, such an event would cause >> identical changes in both the original and the copy. >> > > Yes, it could do so if the SEU hits the data section. > > These days I always make a point of using RAID in my machines (except > laptops, but I consider the data on them to be throw-away). I use > either btrfs with its built-in raid1 (physically duplicating all > metadata and file data on both disks) or ext4 with Linux md raid1 (also > doing physical duplication, but at a lower level.) btrfs raid1 is more > efficient because it does not have to duplicate unused space as md raid > does. With btrfs COW snapshots and raid1 duplication, I get the best of > both worlds - at the cost of having two disks. > > (Backups to other machines and other locations are also good insurance, > no matter how you arrange your filesystems and disks.) > > > I think that is probably enough off-topic discussion on disks and > filesystems. It looks like you have understood things mostly, and I > hope I have filled in any gaps. If you have other questions, feel free > to email me - I can talk about this stuff for many more pages :-) > > This whole discussion came about because of your stoopid statement about being able to make a copy of a file without reading the file. And you've been furiously backpedaling ever since. If you had just admitted you were wrong the whole thing would have been avoided. But I know you never admit you are wrong. Even something as egregious (sorry for the long word - you'll have to look it up) as this. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-11-24 22:50 -0600 |
| Message-ID | <89th1dtq7mr2gcqhur64bilsgiuoqv4f5c@4ax.com> |
| In reply to | #123399 |
On Thu, 23 Nov 2017 15:05:20 -0500, James Kuyper <jameskuyper@verizon.net> wrote: >On 11/23/2017 03:39 AM, David Brown wrote: >> On 22/11/17 21:01, Jerry Stuckle wrote: >>> On 11/22/2017 10:08 AM, jameskuyper@verizon.net wrote: >>>> On Wednesday, November 22, 2017 at 9:50:23 AM UTC-5, David Brown wrote: >>>>> On 22/11/17 15:13, Jerry Stuckle wrote: >>>>>> On 11/22/2017 5:07 AM, David Brown wrote: >>>>>>> On 21/11/17 22:04, Pascal J. Bourguignon wrote: >>>>>>>> fir <profesor.fir@gmail.com> writes: >>>>>>>> >>>>>>>>> note yet i made some test that was >>>>>>>>> copyying file in total comender and the result is a bit discussable >>>>>>>>> >>>>>>>>> >>>>>>>>> - when i copied file the old one file changed acces time to current >>>>>>>>> (though i was not opening it only copying) >>>>>>>> >>>>>>>> Think about it! >>>>>>>> >>>>>>>> How would YOU copy the file if not by opening it and reading it? >>>>>>>> >>>>>>>> (There is an answer, and once you find it, you'll understand >>>>>>>> why it's >>>>>>>> not provided, and why you have to open the file and read it to >>>>>>>> copy it). >>>>>>>> >>>>>>> >>>>>>> I can think of ways to copy a file without reading it. In fact, I >>>>>>> regularly make copies of my entire filesystems without reading them. >>>>>>> >>>>>>> >>>>>> >>>>>> I would love to see how you copy a file or filesystem without >>>>>> reading it. >>>>>> >>>>> >>>>> Google "btrfs snapshots", "zfs snapshots" or "lvm snapshots". All of >>>>> these make logical copies of files without actually reading or writing >>>>> any data. >>>> >>>> <https://btrfs.wiki.kernel.org/index.php/Incremental_Backup> describes >>>> them as "COW" snapshots. I assume that "COW" stands for "copy on >>>> write" - which means the snapshot is only some kind of alias for the >>>> original file. Actual file copying only takes place when either the >>>> original or one of the aliases gets written to - and that copying does >>>> in fact involve reading the original file before writing the copy. >>>> >>> >>> You've got it. If you make a copy of something, the copy should still >>> exist when the original is destroyed - i.e. the disk is reformatted or >>> whatever. David's "copy" does not do that. >> >> Nor does the "cp" command in *nix, or "copy" command in Windows. Format >> the disk containing the original and the copy of the file, and both are >> gone. >> >> If you "copy" the file to another disk, then your office burns down, >> both the original and copy are gone. >> >> See? Others can play stupid games too. >> >> With a COW copy on btrfs, zfs, lvm, or other filessystem/block devices >> with such features, you can /delete/ the original and the copy is still >> there. That is, at heart, what most people think of as "making a copy". > >I make no claim to know what "most people" think - but when I think of >making a copy, I mean (among other things) that it's possible for the >copy to get damaged, while the original remains intact (or vice versa). >In fact, having a backup in case the original gets damaged is often the >main reason for making the copy. It's always also possible for a >sufficiently wide-spread distaster to damage both at the same time; but >it's the possibility of damaging them independently that makes them true >copies. > >If I understand this feature correctly, until the "Copy On Write" >feature is triggered, the copy is similar to a Unix hard link to the >original. I won't deny that COW makes this feature meaningfully >different from a Unix hard link. However, the copy doesn't become a true >copy in the sense I described above until COW has been triggered. > >Unix hard links can only occur between files on the same disk volume. Do >these snapshots have the same restriction? >If so, Jerry's example of a disk format doesn't make the distinction >clear, because it would remove both the original and the copy. A better >example would be a cosmic ray (or any other disturbance) that causes the >stored data to be either modified or unreadable. With a true copy (such >as the ones created by using the Unix cp command), such an event >happening to the copy would have no affect on the original, and vice >versa. With a Unix hard link, such an event would change both the >original and the copy. If I understand this snapshot feature correctly, >then prior to the first time COW is triggered, such an event would cause >identical changes in both the original and the copy. I have more experience with storage arrays that provide function like "flashcopies" of volumes. These essentially duplicate the volume, but the two volumes point to the same physical blocks, so the operation is very fast. As writes continue to (both) volumes, the shared blocks are COW'd. One use it to make snapshot backups, another is to make a physical volume backup at a point in time (make a flash copy, then back up the copy to tape, then usually delete the copy at some time). FWIW, these are universally regarded as copies. And logical volumes in any case have a rather nebulous connection to any particular physical storage device anyway.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2017-11-28 16:59 +0000 |
| Message-ID | <ovk4la$7di$1@reader2.panix.com> |
| In reply to | #123358 |
In article <ov61fa$dgk$1@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: >With a COW copy on btrfs, zfs, lvm, or other filessystem/block devices >with such features, you can /delete/ the original and the copy is still >there. That is, at heart, what most people think of as "making a copy". I suppose this means that a filesystem that uses block-level deduplication on content-addressed storage is incapable of holding a copy of a file, since the data blocks are stored in exactly one place. (Note for those who don't recognize it: that was sarcasm.) This came up when Plan 9 moved the filesystem to the Venti storage server. Venti uses content-addressible storage: blocks are hashed using a cryptographically-secure hashing algorithm, and a mapping from hash to block is kept in an index volume. When writing to the store, an attempt is made to look up the block's hash in the index; if an entry already exists, one assumes the block data is already present and returns success. Otherwise, a block is allocated, the data are written to the newly-allocated block, and the (hash, block address) pair is added to the index. The fear was block-corruption on the storage device would lead to data loss due to lack of redundancy. The response was to recognize that the beauty of the scheme lay in the hashing mechanism forming a mapping between the filesystem and some sort of durable media; that could be a mirror or other RAID-style configuration, real-time cross-site replication, etc. That is, redunancy was provided below the content-addressable storage layer, allowing a site to provide distributed durability guarantees to minimize the probability of loss in the event of component failure. Note that this latter can be one way a "file" can be "copied" without being "read": when the data are originally written, a copy is sent to some remote service for archival storage. There is no read operation since it would be unnecessary: the data is already available to the archiver as a byproduct of the write operation. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-11-29 08:26 +1300 |
| Message-ID | <f85rj6FgmrlU3@mid.individual.net> |
| In reply to | #123575 |
On 11/29/2017 05:59 AM, Dan Cross wrote: > In article <ov61fa$dgk$1@dont-email.me>, > David Brown <david.brown@hesbynett.no> wrote: >> With a COW copy on btrfs, zfs, lvm, or other filessystem/block devices >> with such features, you can /delete/ the original and the copy is still >> there. That is, at heart, what most people think of as "making a copy". > > I suppose this means that a filesystem that uses block-level > deduplication on content-addressed storage is incapable of > holding a copy of a file, since the data blocks are stored in > exactly one place. (Note for those who don't recognize it: that > was sarcasm.) :) -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-11-29 10:10 +0100 |
| Message-ID | <ovlthi$ptt$1@dont-email.me> |
| In reply to | #123575 |
On 28/11/17 17:59, Dan Cross wrote: > In article <ov61fa$dgk$1@dont-email.me>, > David Brown <david.brown@hesbynett.no> wrote: >> With a COW copy on btrfs, zfs, lvm, or other filessystem/block devices >> with such features, you can /delete/ the original and the copy is still >> there. That is, at heart, what most people think of as "making a copy". > > I suppose this means that a filesystem that uses block-level > deduplication on content-addressed storage is incapable of > holding a copy of a file, since the data blocks are stored in > exactly one place. (Note for those who don't recognize it: that > was sarcasm.) I think many people have a concept that a "copy" must in some way be /physically/ independent of the original. In reality, copies are often just logical copies - they act as though they are independent in storage somewhere, but they might not be. They might be CoW copies, or stored on something with deduplication. Even if they are supposedly independent copies on different disk sectors, they might be on the same physical disk or the same file system, and therefore not independent. And you can go the other way - a file may appear to be a single logical file, but have multiple physical copies (such as on a RAID system). To me, a "copy" is a logical operation. It means that when everything is working as it should - no disk failures, server room fires, filesystem corruption, human error - you have two logically independent versions of the file or object. If you want something that protects your data against one or more type of failure, it is a "backup". > > This came up when Plan 9 moved the filesystem to the Venti > storage server. Venti uses content-addressible storage: blocks > are hashed using a cryptographically-secure hashing algorithm, > and a mapping from hash to block is kept in an index volume. > When writing to the store, an attempt is made to look up the > block's hash in the index; if an entry already exists, one > assumes the block data is already present and returns success. > Otherwise, a block is allocated, the data are written to the > newly-allocated block, and the (hash, block address) pair is > added to the index. That is probably quite a space-efficient way to store things, perhaps at some cost in speed. > > The fear was block-corruption on the storage device would lead > to data loss due to lack of redundancy. The response was to > recognize that the beauty of the scheme lay in the hashing > mechanism forming a mapping between the filesystem and some sort > of durable media; that could be a mirror or other RAID-style > configuration, real-time cross-site replication, etc. That is, > redunancy was provided below the content-addressable storage > layer, allowing a site to provide distributed durability > guarantees to minimize the probability of loss in the event of > component failure. Exactly. > > Note that this latter can be one way a "file" can be "copied" > without being "read": when the data are originally written, a > copy is sent to some remote service for archival storage. There > is no read operation since it would be unnecessary: the data is > already available to the archiver as a byproduct of the write > operation. > > - Dan C. >
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2017-11-29 21:01 +0000 |
| Message-ID | <ovn77c$41o$1@reader2.panix.com> |
| In reply to | #123597 |
In article <ovlthi$ptt$1@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: >I think many people have a concept that a "copy" must in some way be >/physically/ independent of the original. In reality, copies are often >just logical copies - they act as though they are independent in storage >somewhere, but they might not be. They might be CoW copies, or stored >on something with deduplication. Even if they are supposedly >independent copies on different disk sectors, they might be on the same >physical disk or the same file system, and therefore not independent. >And you can go the other way - a file may appear to be a single logical >file, but have multiple physical copies (such as on a RAID system). Yes, that's the intuition. I suspect that Stuckle thinks of a "copy" as something one puts on a 5.25" floppy disk and then trades to the kid down the street for an old copy of Sports Illustrated. >To me, a "copy" is a logical operation. It means that when everything >is working as it should - no disk failures, server room fires, >filesystem corruption, human error - you have two logically independent >versions of the file or object. If you want something that protects >your data against one or more type of failure, it is a "backup". Yes; I agree. >> This came up when Plan 9 moved the filesystem to the Venti >> storage server. Venti uses content-addressible storage: blocks >> are hashed using a cryptographically-secure hashing algorithm, >> and a mapping from hash to block is kept in an index volume. >> When writing to the store, an attempt is made to look up the >> block's hash in the index; if an entry already exists, one >> assumes the block data is already present and returns success. >> Otherwise, a block is allocated, the data are written to the >> newly-allocated block, and the (hash, block address) pair is >> added to the index. > >That is probably quite a space-efficient way to store things, perhaps at >some cost in speed. Indeed. However, the file server was a dedicated machine on the network, and it was found that it could still saturate the network interface. Furthermore, there was a write-cache placed in front of Venti to amortize the cost of transient storage. >> [snip] - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-11-29 23:13 +0100 |
| Message-ID | <ovnbf7$ecf$1@dont-email.me> |
| In reply to | #123625 |
On 29/11/17 22:01, Dan Cross wrote: > In article <ovlthi$ptt$1@dont-email.me>, > David Brown <david.brown@hesbynett.no> wrote: >> I think many people have a concept that a "copy" must in some way be >> /physically/ independent of the original. In reality, copies are often >> just logical copies - they act as though they are independent in storage >> somewhere, but they might not be. They might be CoW copies, or stored >> on something with deduplication. Even if they are supposedly >> independent copies on different disk sectors, they might be on the same >> physical disk or the same file system, and therefore not independent. >> And you can go the other way - a file may appear to be a single logical >> file, but have multiple physical copies (such as on a RAID system). > > Yes, that's the intuition. I suspect that Stuckle thinks of a "copy" > as something one puts on a 5.25" floppy disk and then trades to the > kid down the street for an old copy of Sports Illustrated. > >> To me, a "copy" is a logical operation. It means that when everything >> is working as it should - no disk failures, server room fires, >> filesystem corruption, human error - you have two logically independent >> versions of the file or object. If you want something that protects >> your data against one or more type of failure, it is a "backup". > > Yes; I agree. > >>> This came up when Plan 9 moved the filesystem to the Venti >>> storage server. Venti uses content-addressible storage: blocks >>> are hashed using a cryptographically-secure hashing algorithm, >>> and a mapping from hash to block is kept in an index volume. >>> When writing to the store, an attempt is made to look up the >>> block's hash in the index; if an entry already exists, one >>> assumes the block data is already present and returns success. >>> Otherwise, a block is allocated, the data are written to the >>> newly-allocated block, and the (hash, block address) pair is >>> added to the index. >> >> That is probably quite a space-efficient way to store things, perhaps at >> some cost in speed. > > Indeed. However, the file server was a dedicated machine on the > network, and it was found that it could still saturate the network > interface. Furthermore, there was a write-cache placed in front of > Venti to amortize the cost of transient storage. > If the storage is spinning rust, then with relatively modern processors and enough ram, it is worth making considerable effort to reduce the disk transfers. Transparent compression (such as btrfs and zfs support) means more cpu work, but can make reads and writes significantly faster due to smaller disk transfers. I expect the same will apply to this dedup'ed server if there is a lot of similarity in the files. But it will depend on the relative speeds of the components in the server.
[toc] | [prev] | [next] | [standalone]
| From | cross@spitfire.i.gajendra.net (Dan Cross) |
|---|---|
| Date | 2017-11-30 17:26 +0000 |
| Message-ID | <ovpevv$aud$1@reader2.panix.com> |
| In reply to | #123626 |
In article <ovnbf7$ecf$1@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: >On 29/11/17 22:01, Dan Cross wrote: >> Indeed. However, the file server was a dedicated machine on the >> network, and it was found that it could still saturate the network >> interface. Furthermore, there was a write-cache placed in front of >> Venti to amortize the cost of transient storage. > >If the storage is spinning rust, then with relatively modern processors >and enough ram, it is worth making considerable effort to reduce the >disk transfers. Transparent compression (such as btrfs and zfs support) >means more cpu work, but can make reads and writes significantly faster >due to smaller disk transfers. I expect the same will apply to this >dedup'ed server if there is a lot of similarity in the files. But it >will depend on the relative speeds of the components in the server. The venti paper is now 15 years old (presented at FAST in 2002; paper itself here: http://9p.io/sys/doc/venti/venti.pdf). CPUs were slower and RAM was smaller back then. At the time, the transition to the new filesystem and Venti was something of a radical departure: the Plan 9 file server had always been a dedicated machine, but previously it had run a specialized kernel that did not permit arbitrary user processes. Moving to venti meant that a "normal" CPU server kernel could be used for file service; that was pretty cool but concerns about increased latency were raised: in the previous file server, basically all of physical memory was allocated to a filesystem cache, all of mag disk was a cache, and the actual filesystem lived on a WORM device (at Bell Labs and a few other sites, this was an actual magneto-optical WORM robot; most places used a 'pseudo-cache' backed by magdisk). In the new scheme, there would be scheduler interference and potentially other processes, though by this time even for modest sites it was often cheap enough to dedicate a machine to file service: the network was the bottleneck and as long as the software could keep the network device saturated, little concern was given to optimizing IO to/from the disk devices. That said, balancing IO between the index and data "arenas" was recognized pretty early on as a bottleneck, and much attention and care at sites was placed into sizing the two and dividing up IO intelligently to maximize IO throughput. By comparison, Venti and the fossil filesystem built on top of it would rightly be considered rather primitive versus zfs et al. But the Plan 9 infrastructure is (in many ways) much older, and was oriented towards research anyway. - Dan C.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2017-11-22 08:00 -0800 |
| Message-ID | <680c3b5f-43de-43ad-9b9d-1df3b5aeb770@googlegroups.com> |
| In reply to | #123293 |
W dniu środa, 22 listopada 2017 15:13:12 UTC+1 użytkownik Jerry Stuckle napisał: > On 11/22/2017 5:07 AM, David Brown wrote: > > On 21/11/17 22:04, Pascal J. Bourguignon wrote: > >> fir <profesor.fir@gmail.com> writes: > >> > >>> note yet i made some test that was > >>> copyying file in total comender and the result is a bit discussable > >>> > >>> > >>> - when i copied file the old one file changed acces time to current > >>> (though i was not opening it only copying) > >> > >> Think about it! > >> > >> How would YOU copy the file if not by opening it and reading it? > >> > >> (There is an answer, and once you find it, you'll understand why it's > >> not provided, and why you have to open the file and read it to copy it). > >> > > > > I can think of ways to copy a file without reading it. In fact, I > > regularly make copies of my entire filesystems without reading them. > > > > > > I would love to see how you copy a file or filesystem without reading it. > in duch os areas you define os things as you like - and defining read as a more separate thing is possible imo (this is maybe becous copy is like atomik - theoretically can be used on whole file without without accesing the parts (sorta like memcopy eithout separate cpu's mov).. bat thats not much important probably imo.. the most usefull conclusion from this thread is imo, forget creation time stay with acces times and modify times and you will be ok (where by ok i mean not confused) ;c
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2017-11-22 17:11 +0100 |
| Message-ID | <m2bmjucmyw.fsf@informatimago.com> |
| In reply to | #123293 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 11/22/2017 5:07 AM, David Brown wrote: >> On 21/11/17 22:04, Pascal J. Bourguignon wrote: >>> fir <profesor.fir@gmail.com> writes: >>> >>>> note yet i made some test that was >>>> copyying file in total comender and the result is a bit discussable >>>> >>>> >>>> - when i copied file the old one file changed acces time to current >>>> (though i was not opening it only copying) >>> >>> Think about it! >>> >>> How would YOU copy the file if not by opening it and reading it? >>> >>> (There is an answer, and once you find it, you'll understand why it's >>> not provided, and why you have to open the file and read it to copy it). >>> >> >> I can think of ways to copy a file without reading it. In fact, I >> regularly make copies of my entire filesystems without reading them. >> >> > > I would love to see how you copy a file or filesystem without reading it. Well, the cheat was that I used "reading" as read(2). The kernel could implement a copy(2) syscall that would still read the blocks for the file, but not by open(2)ing the file and read(2)ing it, but instead by calling the kernel internals to read the blocks listed in the inode and duplicate them. For example, the naive user space implementation (using read(2)) would unsparse sparse files, while the naive kernel implementation (duplicating inode and blocks) would keep sparseness. -- __Pascal J. Bourguignon http://www.informatimago.com
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.lang.c
csiph-web