2008-08-23 00:48 <bh> flips: you there >?
2008-08-23 00:48 <bh> I think you need to put compression "blobs" in tux3 from the get go
2008-08-23 00:48 <bh> so that you can dedup things
2008-08-23 00:48 <flips> hi bh
2008-08-23 00:48 <bh> I think it's rather important to do that kind of thing because of the various enterprise uses of that
2008-08-23 00:49 <bh> potentially by folks like facebook and stuff.
2008-08-23 00:49 <flips> can I translate that as just have everything blob-ready?
2008-08-23 00:49 <flips> because it already is, kind of
2008-08-23 00:49 <bh> having a kind type file specific metadata for large linearly seeked files is another thing that's minor, but valuable as well
2008-08-23 00:50 <flips> you mean, with a radix tree instead of a btree?
2008-08-23 00:50 <flips> extents make large linear files quite nice
2008-08-23 00:50 <bh> flips: you might like to consider and experiment with various sizes of compression blobs to see how efficient the compression and storage is, then store the sha1 hash to "union" common file segments
2008-08-23 00:50 <bh> I think that's really important IMO
2008-08-23 00:51 <bh> wait, I'm merging two things into one
2008-08-23 00:51 <bh> forget compression, replace that completely with deduping
2008-08-23 00:51 <bh> maybe you can then extend that to compresssion as well using the same blob infrastructure
2008-08-23 00:51 <flips> how about deduping at the lvm level?
2008-08-23 00:51 <bh> no, at the file level
2008-08-23 00:51 <flips> why does deduping ahve to involve the filesystem?
2008-08-23 00:52 <bh> file fragment level so that things like .jpgs and stuff can save on storage
2008-08-23 00:52 <bh> because I can't see how that can be done at the RAID level
2008-08-23 00:53 <bh> it's about how a file is represented as a piece of data in the fs
2008-08-23 00:53 <bh> that would be valuable for a lot of enterprise ready folks that use those kind of filers, you don't want to just add it on later and do a half as job at it
2008-08-23 00:53 <flips> use an extent-based interface to the lvm
2008-08-23 00:54 <flips> it is coming inevitably anyway
2008-08-23 00:54 <bh> how's that going to solve the problem ?
2008-08-23 00:54 <flips> it gives you variable length data
2008-08-23 00:54 <flips> well
2008-08-23 00:54 <flips> dedupping
2008-08-23 00:54 <bh> just not sure how that fits in, you mean extent per file segment or something like that ?
2008-08-23 00:54 <flips> I was thinking of the other
2008-08-23 00:54 <bh> 
ACTION is prepping for Burning Man tonight

2008-08-23 00:54 <flips> ok, so you want to have the filesystem reference data with finer granularity than blocks?
2008-08-23 00:55 <flips> so that you can do real micro-idenfication of similar data?
2008-08-23 00:55 <bh> no, large than blocks, with the magic size of a "blob"
2008-08-23 00:55 <flips> what is the difference between a blob and an extent/
2008-08-23 00:56 <bh> so that you can do an incremental back up or something like that for, say, a 32k commit/write and have that be backed already by another segment existing on the disk
2008-08-23 00:56 <bh> there's a tradeoff between the metadata size and the savings of space.
2008-08-23 00:56 <bh> I'm just making up the term "blob" for a compression cluster of blocks
2008-08-23 00:56 <bh> contiguous in a file
2008-08-23 00:57 <flips> replication is a decent argument
2008-08-23 00:57 <flips> because the filesystem should replicate at the filesystem level
2008-08-23 00:57 <bh> this is heavy enough that it might benefit from scoping out which parts of the file system do it, say, by volume or specific directory
2008-08-23 00:57 <flips> a filesystem like this one anyway
2008-08-23 00:58 <bh> flips: I'm trying to communicate this to you because I think it's critically important'
2008-08-23 00:58 <flips> you will succeed in getting me thinking about it
2008-08-23 00:58 <bh> the fact's a file segment or cluster shouldn't matter since they might be able to use the same generic framework
2008-08-23 00:58 <bh> encryption would also fall into this category
2008-08-23 00:58 <flips> having multiple pointers pointing at the same blob is currently an alien concept to tux3
2008-08-23 00:59 <flips> how do you know when the blob can be released?
2008-08-23 00:59 <bh> well, give some thought and maybe you'll think it's important enough to change it
2008-08-23 00:59 <bh> not sure, good question
2008-08-23 00:59 <bh> I'd imagine it would be similar to the hard link problem
2008-08-23 00:59 <flips> maybe there is a good answer
2008-08-23 00:59 <flips> ref counting is not nice
2008-08-23 01:00 <flips> you have to have all those counts persistent
2008-08-23 01:00 <bh> yeah, well, it's better to do stuff like this up front if you decided you need it
2008-08-23 01:01 <flips> well I suppose refcounts could be done like extents
2008-08-23 01:01 <flips> and you only incur the overhead if using deduping
2008-08-23 01:01 <flips> which you expect to go slower I would hope
2008-08-23 01:02 <flips> pluggable btree leaf formats as tux3 has now gives you all the blob referencing machinery you need
2008-08-23 01:04 <shapor> bh: so you're saying file-level checksumming for deduping?
2008-08-23 01:08 <shapor> or.. a blob would be larger than an extent and smaller than a whole file
2008-08-23 03:29 <flips> zfs has dnodes and znodes, I wonder what those are
2008-08-23 03:34 <shapor> the problem with "de-duping" with extents will be alignment
2008-08-23 03:34 <flips> yes, you have to include a header in the blob
2008-08-23 03:34 <flips> but alignment is not nearly as serious an issue with extent based filesystem as block based
2008-08-23 03:34 <shapor> well even if you store it in the metadata
2008-08-23 03:35 <shapor> if 2 files have a common chunk, it needs to be broken up in to extents the same way in both
2008-08-23 03:35 <shapor> even if the files are identical
2008-08-23 03:35 <flips> the approximate size would be in the metadata, exact size in the blob
2008-08-23 03:35 <shapor> they could be broken up in to extents different
2008-08-23 03:35 <shapor> differently*
2008-08-23 03:36 <flips> the object is just to identify common blocks?
2008-08-23 03:36 <flips> and not arbitrary regions? that can also be done
2008-08-23 03:36 <shapor> yeah, single instance storage, right?
2008-08-23 03:36 <flips> how do you decide where to draw the line?
2008-08-23 03:36 <shapor> i think that is what bh was suggesting
2008-08-23 03:37 <flips> there is a vanishingly small chance it will get into the prototype implementation
2008-08-23 03:38 <flips> therefore the object of the exercise must be to see how we could be blob friendly
2008-08-23 03:38 <shapor> i think the only reasonable way to do it is in the background
2008-08-23 03:38 <shapor> and sharing between files
2008-08-23 03:38 <flips> not take a lot of decisions that would make it hard to do bloby things
2008-08-23 03:38 <flips> ugly code
2008-08-23 03:38 <shapor> if sharing can be supported a background thing could be added on
2008-08-23 03:38 <flips> it will be very ugly
2008-08-23 03:39 <shapor> will it really?
2008-08-23 03:39 <shapor> another layer of indirection?
2008-08-23 03:39 <shapor> heh
2008-08-23 03:39 <flips> doing it in the lvm would be cleaner, provided an extent based interface is available
2008-08-23 03:39 <flips> to the lvm
2008-08-23 03:39 <shapor> that would be pretty neat
2008-08-23 03:39 <flips> we sort of have something like that already, namely bio
2008-08-23 03:40 <shapor> work with all filesystems
2008-08-23 03:41 <shapor> and you could only enable it on the "slow" data device
2008-08-23 03:41 <shapor> not the fast metadata one
2008-08-23 03:41 <flips> right
2008-08-23 03:41 <flips> I'd like to see a killer argument why it has to be done in the filesystem
2008-08-23 03:41 <shapor> can you change the bio size?
2008-08-23 03:42 <flips> yes
2008-08-23 03:42 <flips> especially with my stacking patch
2008-08-23 03:42 <shapor> so the device will only accept 4k bios
2008-08-23 03:42 <flips> bio size can even be changed on the fly
2008-08-23 03:42 <flips> while the bio is in flight
2008-08-23 03:42 <flips> bios are pretty loosely goosey
2008-08-23 03:54 <flips> shapor, a problem with your ownership inheritence suggestion: a file does not know what directory it is in.
2008-08-23 03:54 <flips> so can't inherit anything from the directory
2008-08-23 03:54 <flips> it can however inherit from its inode table block
2008-08-23 03:54 <flips> which gives the same effect
2008-08-23 03:54 <shapor> hrm
2008-08-23 03:56 <flips> "Shapor has suggested that there be per-directory default uid, gid and
2008-08-23 03:56 <flips> mode attributes, so any file with exactly those attrbutes does not have
2008-08-23 03:56 <flips> to represent ownership at all, but inherits it from the inode table
2008-08-23 03:56 <flips> block it lives in.  Allocation policy will be such that its neighbours
2008-08-23 03:56 <flips> are likely to have inentical ownership."
2008-08-23 03:57 <shapor> permissions also
2008-08-23 03:57 <shapor> ah "mode attributes"
2008-08-23 03:57 <shapor> glazed over that 
2008-08-23 03:57 <flips> right
2008-08-23 03:58 <flips> the idea could be extended to acls with some effort
2008-08-23 04:09 <flips> sleepy time
2008-08-23 04:19 <flips> had to play the new star wars ps3 demo, it's awesome
2008-08-23 04:19 <flips> advances the state of the art of that kind of game
2008-08-23 04:19 <flips> unlike the recent movies
2008-08-23 04:53 -!- pgquiles(~pgquiles@239.Red-83-41-113.dynamicIP.rima-tde.net) has joined #tux3
2008-08-23 12:19 -!- MaZe(~MaZe@c-24-6-86-168.hsd1.ca.comcast.net) has joined #tux3
2008-08-23 13:01 <shapor> so how big will the tux3 superblock be
2008-08-23 13:01 <shapor> traditional 4k?
2008-08-23 13:01 <flips> smaller I think
2008-08-23 13:02 <flips> maybe 1K or 512 bytes
2008-08-23 13:02 <flips> a tux3 filesystem will never be smaller than 4K, but not the entire 4K needs to be valid superblock data
2008-08-23 13:02 <flips> so it can be probed by reading 4K to find the superblock magic and block size
2008-08-23 13:02 <shapor> does variable size make sense?
2008-08-23 13:03 <flips> variable size superblock? would would you do with the extra space on large block size?
2008-08-23 13:03 <flips> I think, just let it be
2008-08-23 13:03 <shapor> text description of the filesystem? heh i dunno
2008-08-23 13:03 <flips> bitmaps of the devs
2008-08-23 13:04 <shapor> pi to as many digits that will fit?
2008-08-23 13:04 <flips> the bigger the block size the more detailed pix you have of the devs
2008-08-23 13:04 <shapor> hah, we dont want to scare people
2008-08-23 13:04 <flips> no, especially not topless rollerskating pictures of the devs
2008-08-23 13:04 <flips> at any resolution
2008-08-23 13:04 <shapor> yikes
2008-08-23 13:04 <flips> speaking of which...
2008-08-23 13:05 <flips> isn't there something happening in venice today?
2008-08-23 13:06 <flips> starts at noon
2008-08-23 13:06 <flips> time to get a coffee in me and get skates on
2008-08-23 13:28 <bh> hey flips 
2008-08-23 13:28 <bh> 
ACTION fell asleep last night fairly suddenly

2008-08-23 13:30 <bh> flips: shapor yeah, that's kind of what I meant, other than, maybe a mechanism that can dedup it at the userspace level
2008-08-23 13:30 <bh> maybe it's not the role of the FS to do that, just a suggestion
2008-08-23 13:30 <bh> but it shouldn't complicate the prototype imo because getting it out is more important
2008-08-23 13:33 -!- MaZe(~MaZe@c-24-6-86-168.hsd1.ca.comcast.net) has joined #tux3
2008-08-23 13:38 <flips> bh, see if you can find a killer argument why the fs has to do it
2008-08-23 13:38 <flips> as opposed to the lvm
2008-08-23 13:38 <flips> assuming an extent-aware lvm
2008-08-23 13:39 <flips> (note for lvm3 design)
2008-08-23 14:57 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3
2008-08-23 14:58 <flips> hey tim_dimm
2008-08-23 14:58 <tim_dimm> hey
2008-08-23 14:58 <tim_dimm> coding away I would assume
2008-08-23 14:58 <flips> yes
2008-08-23 14:58 <flips> I'll roll out for a skate sometime
2008-08-23 14:58 <tim_dimm> I'm doing house duty today
2008-08-23 15:17 <flips> btree.c:451: error: 'typeof' applied to a bit-field <- lame :p
2008-08-23 15:17 <flips> lazy gcc devs
2008-08-23 15:17 <flips> lazy & ugly
2008-08-23 15:46 <shapor> g99 is too advanced
2008-08-23 16:29 <flips> [11882] tuxread: read 0/c
2008-08-23 16:29 <flips> got 12 bytes
2008-08-23 16:29 <flips> 0xbf93990c:  68 65 6c 6c 6f 20 77 6f 72 6c 64 21               "hello world!"
2008-08-23 16:47 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3
2008-08-23 16:49 <shapor> flips: all tests compile (without warnings) and run on 64 bit
2008-08-23 16:51 <flips> :-)
2008-08-23 16:51 <flips> I tried to fill in the (L)s where needed
2008-08-23 16:53 <flips> sk8 oclock
2008-08-23 17:28 <flips> ah, getting close anyway
2008-08-23 17:28 <flips> now should I skate first or have another coffee first
2008-08-23 17:28 <flips> leaning towards the latter
2008-08-23 17:28 <flips> makes the skate more interesting
2008-08-23 17:30 <shapor> make it an irish coffee
2008-08-23 17:30 <shapor> and see how far you can make it before you fall
2008-08-23 17:30 <flips> not without moral support
2008-08-23 17:30 <flips> get joelle down for one ;-)
2008-08-23 17:31 <flips> you married folks are too boring
2008-08-23 17:32 <flips> oh, I misspoke in my latest tux3 post
2008-08-23 17:32 <shapor> hah, not quite
2008-08-23 17:32 <flips> I can make a 1EB file no problem, even if bitmaps can't map 1EB
2008-08-23 17:33 <flips> the block doesn't have to be high up at all
2008-08-23 17:33 <flips> but I will put it up high anyway
2008-08-23 17:33 <flips> 1EB/2 - 1
2008-08-23 17:33 <flips> just set the allocation goal at 1EB/2 - 100 or so
2008-08-23 17:34 <flips> the whole fs will be allocated way up there
2008-08-23 17:34 <flips> possibly turning up some unhandled boundary conditions ;-)
2008-08-23 17:36 <shapor> why?
2008-08-23 17:37 <flips> because it happens
2008-08-23 17:37 <flips> on occasion
2008-08-23 17:37 <shapor> wait
2008-08-23 17:37 <flips> most of the big changes I made over the last couple weeks turned up something unhandled
2008-08-23 17:37 <shapor> how are you going to allocate blocks at 1eb/2 ?
2008-08-23 17:37 <shapor> you have a device that big?
2008-08-23 17:37 <shapor> or going to use sparse file as your device?
2008-08-23 17:37 <flips> use a sparse file for the volume
2008-08-23 17:38 <flips> well
2008-08-23 17:38 <shapor> what fs supports that big a spare file?
2008-08-23 17:38 <flips> you're right
2008-08-23 17:38 <flips> can't be quite that high
2008-08-23 17:38 <flips> 16 TB
2008-08-23 17:38 <shapor> pretty far off ;)
2008-08-23 17:38 <flips> your 64 bit system should be able to do 1 EB / 2
2008-08-23 17:38 <shapor> on ext3?
2008-08-23 17:38 <flips> I'lll make it dependent on sizeof(int) so that gets tested
2008-08-23 17:38 <flips> yes
2008-08-23 17:39 <shapor> let me see
2008-08-23 17:39 <flips> or now
2008-08-23 17:39 <flips>  :)
2008-08-23 17:39 <flips> or no
2008-08-23 17:39 <shapor> yeah i'm checking
2008-08-23 17:39 <flips> ext4
2008-08-23 17:39 <shapor> ext4?
2008-08-23 17:39 <flips> good chance to eval ext4
2008-08-23 17:39 <flips> ext4 of course
2008-08-23 17:39 <flips> doubles the size of all pointers etc
2008-08-23 17:42 <flips> gah, I have written tuxopen in the wrong order
2008-08-23 17:42 <flips> need to create the inode before creating the dirent
2008-08-23 17:42 <flips> blush
2008-08-23 17:43 <shapor> dd: truncating at 1125899906842624 bytes in output file `t': File too large
2008-08-23 17:43 <shapor> on ext3
2008-08-23 17:43 <flips> want to try 16tb - 1 while you're at it?
2008-08-23 17:43 <flips> then 16TB even?
2008-08-23 17:44 <shapor> 1tb is ok
2008-08-23 17:44 <shapor> 2tb is not
2008-08-23 17:44 <flips> 1 tb + 1?
2008-08-23 17:45 <flips> ah, there is some other lame limitaion in ext3
2008-08-23 17:45 <flips> the horrors are slowly coming back to me
2008-08-23 17:45 <shapor> 2tb - 1 seems to be the limit
2008-08-23 17:45 <flips> something about signed offsets
2008-08-23 17:46 <flips> the highest signed offset
2008-08-23 17:46 <flips> which is lame
2008-08-23 17:46 <shapor> er maybe exactly 2t
2008-08-23 17:46 <flips> I would hope exactly
2008-08-23 17:46 <shapor> since i'm using seek
2008-08-23 17:47 <flips> using 64 bit seek I suppose
2008-08-23 17:47 <flips> because of 64 bit system
2008-08-23 17:47 <shapor> hrmwell i'm doing bs=1M
2008-08-23 17:47 <shapor> skip=2M
2008-08-23 17:47 <shapor> er seek=2M
2008-08-23 17:47 <flips> http://en.wikipedia.org/wiki/Ext3
2008-08-23 17:48 <shapor> maybe dd is mathing it out
2008-08-23 17:48 <flips> Max file size 	2 TiB
2008-08-23 17:48 <flips> now what is the boneheaded limit
2008-08-23 17:48 <flips> shoudl be 16 TB, the size that the page cache can handle
2008-08-23 17:48 <shapor> ftruncate(1, 2199023255552)             = -1 EFBIG (File too large)
2008-08-23 17:49 <flips> somebody lied?
2008-08-23 17:49 <flips> or do they not mean by limit what they think they mean?
2008-08-23 17:50 <shapor> Linux yzf.shapor.com 2.6.18-6-amd64 #1 SMP Mon Jun 16 22:30:01 UTC 2008 x86_64 GNU/Linux
2008-08-23 17:51 <shapor> from man ftruncate
2008-08-23 17:51 <shapor>        EFBIG  The argument length is larger than the maximum file size. (XSI)
2008-08-23 17:51 <flips> the 2 TB limit comes from the structure of the ufs-style index, maybe
2008-08-23 17:51 <shapor> oh might have to do with block size
2008-08-23 17:51 <flips> it does
2008-08-23 17:51 <flips> but ext3 is pretty much always 4K
2008-08-23 17:52 <flips> except if you make a fs on a floppy
2008-08-23 17:52 <shapor> so many it onyl supports 16tb if you make it larger than 4k
2008-08-23 17:52 <flips> anyway, Tux3 will exactly hit its limits, not be off by one
2008-08-23 17:53 <flips> branching factor is 2^10 for ext2/3 index block
2008-08-23 17:53 <shapor> Block size:               4096
2008-08-23 17:54 <flips> triple indirect is 10 + 10 + 10 + 12 bits
2008-08-23 17:54 <flips> 42 bits
2008-08-23 17:54 <flips> add in some braindamage for signedness, and maybe that is the limit
2008-08-23 17:54 <flips> maybe not
2008-08-23 17:55 <flips> albert cahahan has a post from a few years back
2008-08-23 17:55 <flips> treasts the question accurately
2008-08-23 17:55 <shapor> hrm ext3 limit wasn't alwaus 16t
2008-08-23 17:55 <flips> unlike me at the moment ;-)
2008-08-23 17:55 <shapor> i see some discussions of people trying to get it to work
2008-08-23 17:55 <shapor> back in '06
2008-08-23 17:55 <shapor> and my kernel is pretty old
2008-08-23 17:56 <shapor> hrm no that was fs size
2008-08-23 17:56 <shapor> not file size
2008-08-23 17:57 <shapor> flips:  you suck at reading comprehension
2008-08-23 17:57 <shapor> from wikipedia
2008-08-23 17:57 <shapor> Max file size 2 TiB
2008-08-23 17:57 <flips> http://lwn.net/Articles/91731/
2008-08-23 17:58 <flips> I pasted taht above
2008-08-23 17:58 <shapor> oh
2008-08-23 17:58 <shapor> i mean i suck at reading
2008-08-23 17:58 <shapor> heh
2008-08-23 17:58 <flips> comprehension
2008-08-23 17:59 <flips> oh right
2008-08-23 17:59 <flips> it is about measuring blocks in sectors
2008-08-23 17:59 <shapor> blah
2008-08-23 17:59 <flips> bleah
2008-08-23 17:59 <shapor> hrm maybe on tmpfs
2008-08-23 17:59 <flips> it's ok, I don't need the underlying volume that big
2008-08-23 17:59 <flips> well it would be nice to test
2008-08-23 18:00 <flips> the handling of the bitmaps
2008-08-23 18:00 <flips> maybe xfs?
2008-08-23 18:00 <flips> Max file size 	8 exabytes
2008-08-23 18:00 <shapor> hrm nope, tmpfs fail as well
2008-08-23 18:00 <flips> what is this - 1 byte bs?
2008-08-23 18:01 <shapor> cant be signed?
2008-08-23 18:01 <shapor> that would be ... retarded
2008-08-23 18:01 <flips> that's not it
2008-08-23 18:01 <flips> it's just less by one byte
2008-08-23 18:01 <flips> nonsensicle
2008-08-23 18:01 <flips> nonsensical
2008-08-23 18:03 <shapor> limit on tmpfs also seems to be 2 TB - 1
2008-08-23 18:05 <shapor> no
2008-08-23 18:05 <shapor> whoops i was in the wrong dir
2008-08-23 18:07 <shapor> tmpfs is actually a bit over 256G
2008-08-23 18:07 <flips> I wonder what the limit is there
2008-08-23 18:07 <flips> swapper most likely
2008-08-23 18:07 <flips> what about ramfs?
2008-08-23 18:09 <shapor> http://lkml.org/lkml/2004/1/30/101
2008-08-23 18:09 <shapor> something related to total memory size 
2008-08-23 18:10 <shapor> suggested workaround of echo 1 >/proc/sys/vm/overcommit_memory
2008-08-23 18:10 <shapor> didn't help
2008-08-23 18:12 <shapor> wow ramfs is the ticket
2008-08-23 18:13 <shapor> -rw-r--r-- 1 shapor shapor 8.0E 2008-08-23 18:13 t
2008-08-23 18:13 <shapor> ramfs isn't phased at 8EB even
2008-08-23 18:13 <shapor> dd runs out of offset first ;)
2008-08-23 18:14 <shapor> dd: offset too large: cannot truncate to a length of seek=8808038400000 (1048576-byte) blocks
2008-08-23 18:15 <flips> I put a shot of kahlua in my coffee just for you
2008-08-23 18:15 <flips> don't know where anna stashed the wiskey or would have done it properly
2008-08-23 18:15 <flips> she's always one step ahead of me ;-)
2008-08-23 18:16 <shapor> so we use ramfs for testing?
2008-08-23 18:16 <flips> yes
2008-08-23 18:16 <flips> good sleuthing
2008-08-23 18:17 <flips> ramfs on 64 bit
2008-08-23 18:18 <flips> because ramfs on 32 bit maxes out at 2^44
2008-08-23 18:18 <flips> 16 TB
2008-08-23 18:18 <flips> due to the page cache index
2008-08-23 18:19 <flips> both for volumes and files
2008-08-23 18:20 <shapor> did btrfs prototype in userspcae first too?
2008-08-23 18:20 <flips> anyway, I will work with the ext3 limit for the first big file test.  We can still create a 1EB file in tux3 whatever the physical volume size
2008-08-23 18:20 <flips> I doubt it
2008-08-23 18:21 <flips> cut & paste of something most likely
2008-08-23 18:21 <flips> well
2008-08-23 18:21 <flips> don't have any clue
2008-08-23 18:21 <flips> tux3 is a cut n paste of ddsnap in part
2008-08-23 18:31 <flips> ok, what do we do if during a file create the inode creation and allocation succeeds but the dirent creation fails?
2008-08-23 18:32 <flips> probably better consult good old ext2 for guidance
2008-08-23 18:44 <shapor> roll back?
2008-08-23 18:45 <flips> to most recent snapshot?
2008-08-23 18:45 <shapor> no jsut give back the inode
2008-08-23 18:45 <flips> seeing as the changes only happened in a buffer that hasn't been committed yet, that is practical
2008-08-23 18:45 <flips> and the right thing to do
2008-08-23 18:45 <flips> just invalidate the buffer, done
2008-08-23 18:45 <shapor> even if it has
2008-08-23 18:45 <shapor> why does it matter
2008-08-23 18:45 <flips> orphan inode
2008-08-23 18:46 <flips> invalidating the buffer is right, and really nice
2008-08-23 18:46 <flips> it's a true rollback
2008-08-23 18:46 <flips> thanks
2008-08-23 18:47 <shapor> why would dirent creation fail, io error or something?
2008-08-23 18:49 <flips> out of memory
2008-08-23 18:49 <flips> out of disk space
2008-08-23 18:49 <flips> udev fucked up?
2008-08-23 18:50 <flips> who knows
2008-08-23 18:50 <flips> yes and io error
2008-08-23 18:50 <flips> bad sector
2008-08-23 18:51 <flips> uncorrectable ecc error they call it these days
2008-08-23 18:51 <flips> or a cascading failure resulting from that, or bad cpu memory
2008-08-23 18:51 <shapor> the chance of not corrupting any data when that happens seems low
2008-08-23 18:52 <flips> in every case the right thing is to invalidate the buffer
2008-08-23 18:52 <shapor> yes
2008-08-23 18:52 <flips> ext2/3 is very good about no corrupting disk in cases like that
2008-08-23 18:53 <flips> that's partly why it's still our standard fs even with much sexier things about
2008-08-23 18:53 <shapor> yeah
2008-08-23 18:53 <shapor> true
2008-08-23 18:53 <flips> something tells me ZFS is 5 years away from that
2008-08-23 18:53 <shapor> at least
2008-08-23 18:54 <flips> even with the hyped checksumming
2008-08-23 18:54 <shapor> doesn't save you from a fs bug
2008-08-23 18:54 <flips> or memory errors
2008-08-23 18:54 <flips> the two most common causes of corruption
2008-08-23 18:54 <shapor> which seems infinitely more likely than a non detected io corruption
2008-08-23 18:54 <flips> right
2008-08-23 18:55 <shapor> even when the data center i ran hit 115 degrees ambient with crappy old ide drives
2008-08-23 18:55 <shapor> we didnt see any of that
2008-08-23 18:55 <shapor> some drives did die
2008-08-23 18:56 <shapor> but it is obvious
2008-08-23 18:56 <shapor> io errors up the ass
2008-08-23 18:56 <flips> ecc failures is mostly a rather successfull marketing ploy from vendors
2008-08-23 18:56 <flips> or ecc uncaught failures I meant
2008-08-23 18:57 <flips> 
ACTION gone skating

2008-08-23 18:57 <shapor> reminds me of kmfdm lyrics about their music
2008-08-23 18:57 <shapor> "its made my machines cause they dont make mistakes"
2008-08-23 18:57 <shapor> heh
2008-08-23 18:58 <shapor> however maybe all this hyped checksumming will convince hardware vendors to remove error checking, so we should still support it eventually
2008-08-23 19:00 <flips> it's already supported at replication time
2008-08-23 19:00 <flips> more support you mean
2008-08-23 19:25 <shapor> yeah, what if you're not replicating
2008-08-23 19:45 -!- tim_dimm(~timothyhu@cpe-76-90-98-247.socal.res.rr.com) has joined #tux3
2008-08-23 21:41 <flips> shapor, then replicate ;-)
2008-08-23 21:41 <flips> another question is, what if you're not willing to put aside the space to keep a snapshot to checksum against
2008-08-23 21:42 <flips> answer to that may be: only keep the checksums.  But for a snapshot, see?
2008-08-23 21:43 <flips> imho, checksuming every read is braindamage unless you have hardware sitting idle
2008-08-23 21:43 <flips> in which case you spent too much money on your box, probably
2008-08-23 21:43 <flips> now...
2008-08-23 22:31 -!- konrad(~konrad@c-24-16-74-109.hsd1.wa.comcast.net) has joined #tux3
2008-08-23 22:31 -!- flips(~phillips@phunq.net) has joined #tux3
2008-08-23 22:31 -!- bh(~billh@ip68-107-26-122.sd.sd.cox.net) has joined #tux3