Re: Is there a way to flag specific directories "nodatacow"?
On 06/02/2013 07:58 PM, Liu Bo wrote: On Sun, Jun 02, 2013 at 07:11:10PM -0700, George Mitchell wrote: On 06/02/2013 06:28 PM, Liu Bo wrote: On Sun, Jun 02, 2013 at 07:40:52AM -0700, George Mitchell wrote: I am seeing massive journal corruptions that seem to be unique to btrfs and I am suspecting that cow might be causing them. My bandaid fix for this will be to mark the /var filesystem "nodatacow" at boot. But I am wondering if their is any way to flag a particular directory as "nodatacow" outside of the mount process. I would like to be able to mark /var/log/journal as "nodatacow" for example, without having to declare it a subvolume and mount it separately. Hi George, We actually have per-file/directory nodatacow :) But please note if you set nodatacow on the particular directory, only new-created or zero-size files in the directory can follow the nocow rule. 'chattr' in the latest e2fsprogs can fit your requirements, # chattr +C /var/log/journal Also, what kind of massive journal corruptions? Does it look like a btrfs specific bug? thanks, liubo Thanks Liu, That helps a lot! I am very familiar with chattr/lsattr from my ext3 days, but didn't know where to look for btrfs options. From what you are telling me the nodatacow option is identical to nodatacow option for ext3. Do the other ext3 options work for btrfs also? Besides nodatacow, compression is also supported as per file/directory basis. As for as the corruption issue, I actually don't know whether the corruptions are real or whether they are being caused by the way the `journalctl --verify` command is interfacing with the filesystem. My suspicion is that metadata fragmentation *might* be somehow messing with the `journalctl --verify` since I can use simply `journalctl` and all the data flows out without error. I just cleaned out the /var/log/journal directory and started fresh and in no time I am seeing corruptions according to `journalctl --verify`. Here is what the output looks like: That's weird, AFAIK it shouldn't be. Does 'dmesg' also complain when these corruptions from 'journalctl --verify' occurs? (well, I'm expecting some csum errors, maybe...) == [root@localhost aide]# journalctl --verify Invalid object contents at 130624 0% File corruption detected at /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-0628-0004de2c1807989c.journal:130624 (of 131072, 99%). FAIL: /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-0628-0004de2c1807989c.journal (Bad message) PASS: /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/user-501@e1447322cf904d028439c2d3f17d032e-065a-0004de2c18d6d96d.journal Invalid object contents at 125264 0% File corruption detected at /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-069a-0004de2c5e323847.journal:125264 (of 131072, 95%). FAIL: /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-069a-0004de2c5e323847.journal (Bad message) PASS: /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/user-501@e1447322cf904d028439c2d3f17d032e-06a8-0004de2c73b5f19d.journal Invalid object contents at 128408 0% File corruption detected at /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-0709-0004de2cedab583c.journal:128408 (of 131072, 97%). FAIL: /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-0709-0004de2cedab583c.journal (Bad message) Invalid object contents at 126736 0% File corruption detected at /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-077f-0004de2d20abe261.journal:126736 (of 131072, 96%). FAIL: /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-077f-0004de2d20abe261.journal (Bad message) Invalid object contents at 129600 0% File corruption detected at /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-07ec-0004de2d7c50c186.journal:129600 (of 131072, 98%). FAIL: /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-07ec-0004de2d7c50c186.journal (Bad message) PASS: /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/user-501@e1447322cf904d028439c2d3f17d032e-07f1-0004de2d87392b08.journal Invalid object contents at 12
Re: Is there a way to flag specific directories "nodatacow"?
On Sun, Jun 2, 2013 at 11:11 PM, George Mitchell wrote: > > So I want to try forcing "nodatacow" on this directory and see what happens. > If that doesn't work, I suppose the next step will be to place this one > directory on an ext4 filesystem and mount it externally to the btrfs > /var/log. I have the same kind of errors in ext4 file system (ArchLinux 64-bit in a Macbook Air). To me they seem to be related to power loss events, caused by battery depletion when sleeping for long time. Any way besides long time intialization of journalctl displays, there is no error in dmesg or /var/log/files. The errors should be related to log metadata info. -- A. C. Censi accensi [em] gmail [ponto] com accensi [em] montreal [ponto] com [ponto] br -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is there a way to flag specific directories "nodatacow"?
On Sun, Jun 02, 2013 at 07:11:10PM -0700, George Mitchell wrote: > On 06/02/2013 06:28 PM, Liu Bo wrote: > >On Sun, Jun 02, 2013 at 07:40:52AM -0700, George Mitchell wrote: > >>I am seeing massive journal corruptions that seem to be unique to > >>btrfs and I am suspecting that cow might be causing them. My > >>bandaid fix for this will be to mark the /var filesystem "nodatacow" > >>at boot. But I am wondering if their is any way to flag a > >>particular directory as "nodatacow" outside of the mount process. I > >>would like to be able to mark /var/log/journal as "nodatacow" for > >>example, without having to declare it a subvolume and mount it > >>separately. > >Hi George, > > > >We actually have per-file/directory nodatacow :) > > > >But please note if you set nodatacow on the particular directory, only > >new-created or zero-size files in the directory can follow the nocow rule. > > > >'chattr' in the latest e2fsprogs can fit your requirements, > ># chattr +C /var/log/journal > > > >Also, what kind of massive journal corruptions? Does it look like a > >btrfs specific bug? > > > >thanks, > >liubo > > > > > Thanks Liu, > > That helps a lot! I am very familiar with chattr/lsattr from my ext3 > days, but didn't know where to look for btrfs options. From what you > are telling me the nodatacow option is identical to nodatacow option > for ext3. Do the other ext3 options work for btrfs also? Besides nodatacow, compression is also supported as per file/directory basis. > > As for as the corruption issue, I actually don't know whether the > corruptions are real or whether they are being caused by the way the > `journalctl --verify` command is interfacing with the filesystem. My > suspicion is that metadata fragmentation *might* be somehow messing > with the `journalctl --verify` since I can use simply `journalctl` > and all the data flows out without error. I just cleaned out the > /var/log/journal directory and started fresh and in no time I am > seeing corruptions according to `journalctl --verify`. Here is what > the output looks like: That's weird, AFAIK it shouldn't be. Does 'dmesg' also complain when these corruptions from 'journalctl --verify' occurs? (well, I'm expecting some csum errors, maybe...) > > == > > [root@localhost aide]# journalctl --verify > Invalid object contents at > 130624 > 0% > File corruption detected at > /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-0628-0004de2c1807989c.journal:130624 > (of 131072, 99%). > FAIL: > /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-0628-0004de2c1807989c.journal > (Bad message) > PASS: > /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/user-501@e1447322cf904d028439c2d3f17d032e-065a-0004de2c18d6d96d.journal > Invalid object contents at > 125264 > 0% > File corruption detected at > /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-069a-0004de2c5e323847.journal:125264 > (of 131072, 95%). > FAIL: > /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-069a-0004de2c5e323847.journal > (Bad message) > PASS: > /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/user-501@e1447322cf904d028439c2d3f17d032e-06a8-0004de2c73b5f19d.journal > Invalid object contents at > 128408 > 0% > File corruption detected at > /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-0709-0004de2cedab583c.journal:128408 > (of 131072, 97%). > FAIL: > /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-0709-0004de2cedab583c.journal > (Bad message) > Invalid object contents at > 126736 > 0% > File corruption detected at > /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-077f-0004de2d20abe261.journal:126736 > (of 131072, 96%). > FAIL: > /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-077f-0004de2d20abe261.journal > (Bad message) > Invalid object contents at > 129600 > 0% > File corruption detected at > /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-07ec-0004de2d7c50c186.journal:129600 > (of 131072, 98%). > FAIL: > /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-07ec-0004de2d7c50c186.journal > (Bad
Re: Is there a way to flag specific directories "nodatacow"?
On Sun, Jun 02, 2013 at 07:19:50PM -0700, George Mitchell wrote: > On 06/02/2013 06:28 PM, Liu Bo wrote: > >On Sun, Jun 02, 2013 at 07:40:52AM -0700, George Mitchell wrote: > >>I am seeing massive journal corruptions that seem to be unique to > >>btrfs and I am suspecting that cow might be causing them. My > >>bandaid fix for this will be to mark the /var filesystem "nodatacow" > >>at boot. But I am wondering if their is any way to flag a > >>particular directory as "nodatacow" outside of the mount process. I > >>would like to be able to mark /var/log/journal as "nodatacow" for > >>example, without having to declare it a subvolume and mount it > >>separately. > >Hi George, > > > >We actually have per-file/directory nodatacow :) > > > >But please note if you set nodatacow on the particular directory, only > >new-created or zero-size files in the directory can follow the nocow rule. > > > >'chattr' in the latest e2fsprogs can fit your requirements, > ># chattr +C /var/log/journal > > > >Also, what kind of massive journal corruptions? Does it look like a > >btrfs specific bug? > > > >thanks, > >liubo > > > > > I am also assuming that all directories later created under > /var/log/journal will inherit the nodatacow profile? Yes, indeed. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is there a way to flag specific directories "nodatacow"?
On 06/02/2013 06:28 PM, Liu Bo wrote: On Sun, Jun 02, 2013 at 07:40:52AM -0700, George Mitchell wrote: I am seeing massive journal corruptions that seem to be unique to btrfs and I am suspecting that cow might be causing them. My bandaid fix for this will be to mark the /var filesystem "nodatacow" at boot. But I am wondering if their is any way to flag a particular directory as "nodatacow" outside of the mount process. I would like to be able to mark /var/log/journal as "nodatacow" for example, without having to declare it a subvolume and mount it separately. Hi George, We actually have per-file/directory nodatacow :) But please note if you set nodatacow on the particular directory, only new-created or zero-size files in the directory can follow the nocow rule. 'chattr' in the latest e2fsprogs can fit your requirements, # chattr +C /var/log/journal Also, what kind of massive journal corruptions? Does it look like a btrfs specific bug? thanks, liubo I am also assuming that all directories later created under /var/log/journal will inherit the nodatacow profile? -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Is there a way to flag specific directories "nodatacow"?
On 06/02/2013 06:28 PM, Liu Bo wrote: On Sun, Jun 02, 2013 at 07:40:52AM -0700, George Mitchell wrote: I am seeing massive journal corruptions that seem to be unique to btrfs and I am suspecting that cow might be causing them. My bandaid fix for this will be to mark the /var filesystem "nodatacow" at boot. But I am wondering if their is any way to flag a particular directory as "nodatacow" outside of the mount process. I would like to be able to mark /var/log/journal as "nodatacow" for example, without having to declare it a subvolume and mount it separately. Hi George, We actually have per-file/directory nodatacow :) But please note if you set nodatacow on the particular directory, only new-created or zero-size files in the directory can follow the nocow rule. 'chattr' in the latest e2fsprogs can fit your requirements, # chattr +C /var/log/journal Also, what kind of massive journal corruptions? Does it look like a btrfs specific bug? thanks, liubo Thanks Liu, That helps a lot! I am very familiar with chattr/lsattr from my ext3 days, but didn't know where to look for btrfs options. From what you are telling me the nodatacow option is identical to nodatacow option for ext3. Do the other ext3 options work for btrfs also? As for as the corruption issue, I actually don't know whether the corruptions are real or whether they are being caused by the way the `journalctl --verify` command is interfacing with the filesystem. My suspicion is that metadata fragmentation *might* be somehow messing with the `journalctl --verify` since I can use simply `journalctl` and all the data flows out without error. I just cleaned out the /var/log/journal directory and started fresh and in no time I am seeing corruptions according to `journalctl --verify`. Here is what the output looks like: == [root@localhost aide]# journalctl --verify Invalid object contents at 130624 0% File corruption detected at /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-0628-0004de2c1807989c.journal:130624 (of 131072, 99%). FAIL: /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-0628-0004de2c1807989c.journal (Bad message) PASS: /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/user-501@e1447322cf904d028439c2d3f17d032e-065a-0004de2c18d6d96d.journal Invalid object contents at 125264 0% File corruption detected at /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-069a-0004de2c5e323847.journal:125264 (of 131072, 95%). FAIL: /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-069a-0004de2c5e323847.journal (Bad message) PASS: /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/user-501@e1447322cf904d028439c2d3f17d032e-06a8-0004de2c73b5f19d.journal Invalid object contents at 128408 0% File corruption detected at /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-0709-0004de2cedab583c.journal:128408 (of 131072, 97%). FAIL: /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-0709-0004de2cedab583c.journal (Bad message) Invalid object contents at 126736 0% File corruption detected at /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-077f-0004de2d20abe261.journal:126736 (of 131072, 96%). FAIL: /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-077f-0004de2d20abe261.journal (Bad message) Invalid object contents at 129600 0% File corruption detected at /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-07ec-0004de2d7c50c186.journal:129600 (of 131072, 98%). FAIL: /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-07ec-0004de2d7c50c186.journal (Bad message) PASS: /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/user-501@e1447322cf904d028439c2d3f17d032e-07f1-0004de2d87392b08.journal Invalid object contents at 129256 0% File corruption detected at /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@e1447322cf904d028439c2d3f17d032e-0862-0004de2e9a6decf4.journal:129256 (of 131072, 98%). FAIL: /var/log/journal/8846d97f611b49aa9f3d48eeac6a81f2/system@
Re: Is there a way to flag specific directories "nodatacow"?
On Sun, Jun 02, 2013 at 07:40:52AM -0700, George Mitchell wrote: > I am seeing massive journal corruptions that seem to be unique to > btrfs and I am suspecting that cow might be causing them. My > bandaid fix for this will be to mark the /var filesystem "nodatacow" > at boot. But I am wondering if their is any way to flag a > particular directory as "nodatacow" outside of the mount process. I > would like to be able to mark /var/log/journal as "nodatacow" for > example, without having to declare it a subvolume and mount it > separately. Hi George, We actually have per-file/directory nodatacow :) But please note if you set nodatacow on the particular directory, only new-created or zero-size files in the directory can follow the nocow rule. 'chattr' in the latest e2fsprogs can fit your requirements, # chattr +C /var/log/journal Also, what kind of massive journal corruptions? Does it look like a btrfs specific bug? thanks, liubo -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Is there a way to flag specific directories "nodatacow"?
I am seeing massive journal corruptions that seem to be unique to btrfs and I am suspecting that cow might be causing them. My bandaid fix for this will be to mark the /var filesystem "nodatacow" at boot. But I am wondering if their is any way to flag a particular directory as "nodatacow" outside of the mount process. I would like to be able to mark /var/log/journal as "nodatacow" for example, without having to declare it a subvolume and mount it separately. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
