| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11 12 13
Comments:
<0> ****ing xfs_check seems to use more memory, the larger the filesystem is
<0> even with 2GB of RAM i can't xfs_check my filesystems :|
<1> yep
<1> just run xfs_repair
<1> that works too
<1> I can't run xfs_check on my 1.4TB filesystem
<1> with only 1GB :(
<1> but repairing goes fine
<0> i dont really want xfs_repair to be killed by an out-of-memory condition if it is in the middle of something :p
<0> yeah this is 1.6GB
<0> er TB
<0> hmm
<1> well ext3 is horrible with very large filesystems
<1> reiser4 just ****s at this point
<1> XFS is nice for me because you can grow/shrink the filesystem really 'ugly'
<0> how do you shrink an xfs filesystem?
<1> in case you need to replace a disk in a raid5 with a slightly smaller size
<1> you can shrink the xfs
<1> :P
<1> it's pretty neat
<1> and growing it works too
<1> in the same fashion
<0> i dont think thats possible.... ive used xfs_growfs, but never shrunk it
<0> its not documented, anyway
<1> friend of mine did it several times
<1> xfs is a flat file system so to speak
<1> or linear
<0> is there another tool to shrink or something?
<1> whatever you would call it
<1> if the last part isn't used, you can just cut it off
<1> without problems
<1> matja: resize the partition? :)
<0> what about the data already on it?
<0> data isnt allocated linearly
<1> it'll be fine
<1> yes it is
<1> it's written from front to back under xfs
<1> so the last part of the array/disk gets used last
<0> but that is terrible for fragmentation
<0> i cant believe it'd be that stupid
<1> not necessarily
<2> that's why lvm is better for that stuff
<1> lude: zfs is even better
<2> you can actually tell it to move data off a certain member of the volume
<1> anyways
<1> it works, but it's an ugly hack
<1> the primary reason I use xfs is speed
<1> deleting 4GB with ext3 takes forever
<1> because it has to follow all indirect inode tables etc.
<1> under xfs it's 'poof' and gone
<0> penguin: if i make a million 1k files, which occupy the first 1GB of a 2GB xfs filesystem, then delete every other file, so half remain with a 1k space between each, then make a single 1GB file, you mean to say, it'll split that 1GB file into a million 1k chunks instead of use the latter 1GB of free disk?
<0> thats simply terrible
<2> xfs is simply terrible
<2> so there's your answer
<1> matja: I don't know what xfs will do in such an extreme situation
<1> you'd have to consult it's terribly ugly code for that
<0> penguin: well it'd have to, if you ***ert that it writes from front to back like you say
<1> I'm sure it allocates more smartly than that
<0> thats the only way truncation of a filesystem would preserve the data already allocated on it
<1> and writing from front to back doesn't mean it will intentionally extremely fragment data
<1> no it's not
<1> and shrinking the fs from the back does not mean truncating
<0> well then, how do you know where you can truncate your filesystem?
<3> whats up all
<4> matja
<4> diggz got raped
<4> 1v1 in qw/dm
<4> on dm6.bsp
<4> 27 - -2
<0> if i have a 1Gb filesystem, write 950MB of files on it, then delete the first 949MB, i only have 1MB allocated, but i sure as hell cant truncate it after the 1MB mark on the disk
<1> matja: there are ways to find that out
<1> please stop creating extreme situations
<1> of course there are going to be situations where it will not work
<0> they're prefectly reasonable real-world situations
<1> just believe it and take it from me that it is possible, I have *seen* it in action
<1> it's just a very very ugly hack
<0> well, you only suggested a method which won't work :p
<1> because of the way xfs allocates space to data, it is possible without the xfs allocation going haywire
<0> i wont blindly believe without proof
<1> fine
<1> be that way
<0> especially when i have to account for every single of the 60 million files on our san
<0> ;)
<1> like I said
<1> I don't caer whether you believe it or not
<1> anymore
<0> well dont spread lies then
<1> I'm just telling you it does in my experience... and that xfs is much faster with large files
<1> if I've seen it work, it's not a lie
<1> you just think it is
<0> that was probably a very simple case
<0> and a one-of
<0> *one-off
<0> a fluke.
<1> that's a pretty arrogant thing to say
<1> because you clearly have no idea how a filesystem works by saying that
<1> and still you pretend to know what *I* saw even though you just said you didn't believe it
<0> im familiar with xfs's preallocation and memory buffering, which is the exact reason why i am rebuting your unfounded claim
<1> haha
<0> just because it worked once, it isn't proof that it'll work every time
<1> oohhhh
<1> so now you're admitting it *DID* work ?
<1> boy you just don't know *WHAT* to think and say to win an argument do you
<0> i'm 100% certain i can come up with two tests, one which works every time, and one which does not
<0> the test which prooves that it does not work would be the one i am interested it :p
<0> it=in
<1> that's about the most meaningless statement there is
<5> it might have been an anomaly
<5> ;)
<0> penguin: how so?
<1> "I'm 100% sure I can think of two tests, where one works and one doesn't."
<0> it'd proove that truncating an xfs filesystem is unreliable
<1> that's a completely useless statement, completely meaningless without describing the actual test
<0> which you claimed was not the case!
<1> argh
<0> ok then
<0> i'll do it now
<1> please define truncating for me
<0> <+penguin> if the last part isn't used, you can just cut it off
<1> and also, please explain why you think resizing xfs means you will truncate it
<0> <+penguin> without problems
<4> http://youtube.com/watch?v=xOV7bk96_Vg&search=anal
<0> oh, you're going back on what you say now
<0> so how exactly did your friend shrink his xfs filesystem?
<1> you must be Swedish
<1> http://oss.sgi.com/archives/xfs/2005-09/msg00039.html
<1> Detailed explanation: I've completed the first part of the shrink
<1> support:
<1> - first patch: permits shrink of the filesystem if all requested blocks
<1> are free;
<1> - second patch (not yet finished): add support for marking allocation
<1> groups offline with regard to space and inode allocation so that you
<1> can clear out the space;
<1> - third part, probably userspace, which will help clear the indented
<1> this is *EXACTLY* why it works
<1> you can shrink the filesystem as long as all of the blocks that would be removed are *FREE*
<1> it is *EXACTLY* because of the way xfs *ALLOCATES BLOCKS*
<1> get it through your thick-headed skull you dip****
<1> jesus
<0> you never answered me
<1> what the patch does is automate that for you
<0> how do i shrink an xfs filesystem?
<1> in a manual case you would need to check that for yourself
<0> i have a 100MB xfs filesystem here, on /dev/vg0/test, with one 10MB file on it
<0> how would i shrink it, say to 50MB
<1> see above
<1> look at what the patch does for you
<0> its not complete
Return to
#gentoo
or
Go to some related
logs:
#politics
chickan 2 donload
#computers
maht.net
1 and 1 Internet + nazi
cryonv mexico
datedif in mysql
#microsoft
#nhl
#unixhelp
|
|